From randy at psg.com Sat Dec 1 00:25:23 2012 From: randy at psg.com (Randy Bush) Date: Sat, 01 Dec 2012 09:25:23 +0900 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: Message-ID: as this thread has moved firmly to legal opinions, i now scan it for postings by folk i know are actual lawyers and whack the rest. if you are a lawyer, but not well known as such, please say so right up front in your message. randy From bgw990 at gmail.com Sat Dec 1 01:09:19 2012 From: bgw990 at gmail.com (b.g. white) Date: Fri, 30 Nov 2012 19:09:19 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: Message-ID: PROCEDURE FOR SEIZURE OF COMPUTERS AND RELATED DEVICES This search warrant covers and controls the procedure for searching: (1) electronic or computer devices, related equipment or media which has been authorized to be seized pursuant to this warrant on the basis that it is contraband or a direct instrumentality used to commit the crime, and (2) electronic or computer devices, related equipment or media for which seizure has not been specifically authorized. Agents are authorized to seize and remove from the premises such electronic or computer device, including computer system input/output (I/O) peripheral devices, software and media so that a qualified computer expert can accurately search for and retrieve the data in a laboratory or other controlled environment when this is necessary in order to search and retrieve the data or information authorized to be searched for and seized pursuant to this warrant. "Agents and computer experts working with agents are authorized to seize the relevant system software (operating systems, interfaces and hardware drivers), any applications software which may have been used to create the data (whether stored on hard drives or on external media), as well as all related instruction manuals or other documentation and data security devices (including but not limited to passwords, keycards and dongles) in order to facilitate the authorized search. In addition, if necessary for data retrieval, they are authorized to reconfigure the system in order to accurately search for and retrieve the evidence stored therein. If, after inspecting the I/O devices, software, documentation and data security devices, the analyst determines that these items are no longer necessary to search for, retrieve and preserve the data, and if the software, documentation and devices have not been seized pursuant to the warrant as contraband or instrumentalities of the crime, the items shall be returned within a reasonable time." https://webcache.googleusercontent.com/search?q=cache:HJ9PtsbdL3kJ:www.fjc.gov/public/pdf.nsf/lookup/ElecDi31.rtf/%24file/ElecDi31.rtf+&cd=1&hl=en&ct=clnk&gl=us Example of an actual warrant: https://www.eff.org/sites/default/files/filenode/inresearchBC/EXHIBIT-A.pdf Not a lawyer. On Fri, Nov 30, 2012 at 6:25 PM, Randy Bush wrote: > as this thread has moved firmly to legal opinions, i now scan it for > postings by folk i know are actual lawyers and whack the rest. if you > are a lawyer, but not well known as such, please say so right up front > in your message. > > randy > > From rdobbins at arbor.net Sat Dec 1 01:12:43 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 1 Dec 2012 01:12:43 +0000 Subject: Remaining IPv6 hurdles (Was: Programmers...) In-Reply-To: <50B93CA7.3020006@unfix.org> References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <91C6CF48-4A85-47FC-8FF7-3CEEBF013603@arbor.net> <01ee01cdcda3$86e4b030$94ae1090$@tndh.net> <47486090-B3D3-421A-AD54-49EE16A3C1D1@arbor.net> <7EAA26F2-7EED-41DB-BC98-0AA53E05D930@arbor.net> <50B93CA7.3020006@unfix.org> Message-ID: On Dec 1, 2012, at 6:09 AM, Jeroen Massar wrote: > Japan and South Korea are doing quite well indeed I guess that depends upon how one defines 'quite well', heh. They're certainly ahead of other countries in the region with regards to IPv6, but it's questionable how deeply/broadly it is both available and utilized by their user bases. And AFAICT, the emphasis is on clients, not servers. > and China has CERNET of course which is doing mostly IPv6. But which does not serve China's user base. > Can you divulge some of these hurdles? Would be interesting to know what they are running into. Architectural issues, operational issues, educational issues, organizational issues, resiliency issues, scalability issues, security issues, economic issues, layer-8, etc. If one encounters significant challenges in designing, building, and operating an IPv4 network, one is unlikely to expend a significant amount of time and resources on IPv6. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From goemon at anime.net Sat Dec 1 01:23:03 2012 From: goemon at anime.net (goemon at anime.net) Date: Fri, 30 Nov 2012 17:23:03 -0800 (PST) Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D7122B2@MUNEXBE1.medline.com> References: <2A76E400AC84B845AAC35AA19F8E7A5D0D71223B@MUNEXBE1.medline.com> <201211302249.qAUMn1iI033496@aurora.sol.net> <2A76E400AC84B845AAC35AA19F8E7A5D0D7122B2@MUNEXBE1.medline.com> Message-ID: On Fri, 30 Nov 2012, Naslund, Steve wrote: > My message to the cops and my lawyer would be charge me or lets clear > this up. There are laws to protect you from the government from taking > your stuff in an unfair manner if you want to go that route. If there > is a misunderstanding I will talk to the cops all they want. If I feel > I need representation, I will get some. If I am really innocent, I > doubt they could ask me too much that would upset me. My guess is they > would rather move on in their case instead of spinning their wheels with > me. http://www.sjgames.com/SS/ -Dan From randy at psg.com Sat Dec 1 01:25:52 2012 From: randy at psg.com (Randy Bush) Date: Sat, 01 Dec 2012 10:25:52 +0900 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: Message-ID: > Not a lawyer. than stfu with the legal crap From owen at delong.com Sat Dec 1 01:52:23 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Nov 2012 17:52:23 -0800 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> <50B93138.3020003@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D71223B@MUNEXBE1.medline.com> Message-ID: <12E9116C-E412-4DCB-8D28-C6955198B1C2@delong.com> > > Not only that, but the list of people who proclaimed their innocence only > to be proven guilty is very long. I can't vouch for countries outside of > the USA, but here at least we don't get subpoenas on a whim. They are > usually part of a very long drawn-out investigation, and they usually are > for a very good reason. Usually, but not always. I've seen a number of subpoenas and a few search warrants that were: Ridiculously broad Overreaching Really stretched the concept of probable cause As in all else, not all LEOs are good actors. Owen From bill at herrin.us Sat Dec 1 02:46:42 2012 From: bill at herrin.us (William Herrin) Date: Fri, 30 Nov 2012 21:46:42 -0500 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <20121130231200.F15172C70366@drugs.dv.isc.org> References: <50AB49EA.3030101@cis.vutbr.cz> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <87zk222gwv.fsf@nemi.mork.no> <87lidl1w9q.fsf@nemi.mork.no> <871ufc21wp.fsf@nemi.mork.no> <24118AE9-197A-40D4-B12C-0FDB50AC86AD@arbor.net> <87sj7szl4g.fsf@nemi.mork.no> <4ADD0AC1-FCA9-4391-8711-963266CD80F3@arbor.net> <50B76008.9030603@unfix.org> <1354289940815-019-01077594.sclark.netwolves.com@sclark66.netwolves.com> <20121130231200.F15172C70366@drugs.dv.isc.org> Message-ID: On Fri, Nov 30, 2012 at 6:12 PM, Mark Andrews wrote: > In message , > William Herrin writes: >> On Fri, Nov 30, 2012 at 5:18 PM, Randy wrote: >> > It wasn't difficult to update to ipv6, only some reading was needed, don't >> > know what the fuss is =D >> >> Go test it against a dual stack remote host with the Tunnel's >> addresses still configured on your hosts but packet filtering set to >> silently drop packets on the IPv6 tunnel. Then work through the >> implications of what you observe. > > Go test your IPv4 code against a half broken multi-homed server. > There is no difference. Which is why the common and successful strategy in engineering a reliable IPv4 system is to use a single IP address for each service and let BGP handle multihoming. Using a single IP address is no longer possible for dual-stacked hosts, so your dual stacked client code has to handle it instead. > With dual stack [...] no more ignoring the issue. Exactly. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From william.allen.simpson at gmail.com Sat Dec 1 03:20:20 2012 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 30 Nov 2012 22:20:20 -0500 Subject: [tor-talk] William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D712204@MUNEXBE1.medline.com> References: <2A76E400AC84B845AAC35AA19F8E7A5D0D712152@MUNEXBE1.medline.com> <8200F04ED2C5EF40B246388AD4B822A512D5C5F7@BL2PRD0512MB662.namprd05.prod.outlook.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D712204@MUNEXBE1.medline.com> Message-ID: <50B97774.4030401@gmail.com> On 11/30/12 5:15 PM, Naslund, Steve wrote: > Well, in that case.... I am really worried that the cops might charge > me with a crime. They took my computers and are looking at them. I did > not do anything wrong but just in case they decide to charge me with a > crime, please send me some money. > As well you could be, because you appear to have the same name as a registered sex offender: http://www.sexoffenderin.com/reg110698/steven_w_naslundmugshot.htm On 11/29/12 6:39 PM, Naslund, Steve wrote: # As a long time service provider ... # # my many years of experience in engineering ARPANET, MILNET, and the # Internet I would have to guess that most Tor servers are used for no # good much more than they are protecting anyone's privacy. I'm surprised that medline.com is offering network access as an ISP? Admittedly, you began posting to NANOG in 2002 as: Network Engineering Manager Hosting.com - Chicago While I was involved in engineering NSFnet and the Internet and was an "original" member of NANOG, but I don't remember you. Of course, I'm notoriously bad with names. OTOH, I have met, remember, and greatly respect the Tor engineers. From randy at psg.com Sat Dec 1 03:32:13 2012 From: randy at psg.com (Randy Bush) Date: Sat, 01 Dec 2012 12:32:13 +0900 Subject: Remaining IPv6 hurdles (Was: Programmers...) In-Reply-To: References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <91C6CF48-4A85-47FC-8FF7-3CEEBF013603@arbor.net> <01ee01cdcda3$86e4b030$94ae1090$@tndh.net> <47486090-B3D3-421A-AD54-49EE16A3C1D1@arbor.net> <7EAA26F2-7EED-41DB-BC98-0AA53E05D930@arbor.net> <50B93CA7.3020006@unfix.org> Message-ID: >> Japan and South Korea are doing quite well indeed > I guess that depends upon how one defines 'quite well', heh. They're > certainly ahead of other countries in the region with regards to IPv6 i can only speak about japan, and it's embarrassing big-time. europe is in better shape. see, for example, erik kline's talk at apnic busan [0]. >> and China has CERNET of course which is doing mostly IPv6. > But which does not serve China's user base. i am pretty sure cernet-2 serves a few times as many people than the entire population of the united states of jingoism. randy -- [0] - if you have trouble finding it, write to apnic marketing. they seem to run the web site as it is all gloss and hard as hell to find content you want. From randy at psg.com Sat Dec 1 03:35:10 2012 From: randy at psg.com (Randy Bush) Date: Sat, 01 Dec 2012 12:35:10 +0900 Subject: [tor-talk] William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50B97774.4030401@gmail.com> References: <2A76E400AC84B845AAC35AA19F8E7A5D0D712152@MUNEXBE1.medline.com> <8200F04ED2C5EF40B246388AD4B822A512D5C5F7@BL2PRD0512MB662.namprd05.prod.outlook.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D712204@MUNEXBE1.medline.com> <50B97774.4030401@gmail.com> Message-ID: > As well you could be, because you appear to have the same name as a > registered sex offender: ok children. can we pull ourselves up out of the mud, please? randy From rdobbins at arbor.net Sat Dec 1 03:47:03 2012 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 1 Dec 2012 03:47:03 +0000 Subject: Remaining IPv6 hurdles (Was: Programmers...) In-Reply-To: References: <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <20121127214113.E113E2C35F6D@drugs.dv.isc.org> <20121128041816.GF1304@dyn.com> <91C6CF48-4A85-47FC-8FF7-3CEEBF013603@arbor.net> <01ee01cdcda3$86e4b030$94ae1090$@tndh.net> <47486090-B3D3-421A-AD54-49EE16A3C1D1@arbor.net> <7EAA26F2-7EED-41DB-BC98-0AA53E05D930@arbor.net> <50B93CA7.3020006@unfix.org> Message-ID: <29818822-51C6-4741-9003-D6C3A7E2015E@arbor.net> On Dec 1, 2012, at 10:32 AM, Randy Bush wrote: > i am pretty sure cernet-2 serves a few times as many people than the entire population of the united states I'm certain that it does not. China did a fantastic job of showcasing IPv6 with the Beijing Olympics, but it's not widely deployed for ordinary users. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From egon at egon.cc Sat Dec 1 04:11:48 2012 From: egon at egon.cc (James Downs) Date: Fri, 30 Nov 2012 20:11:48 -0800 Subject: [tor-talk] William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50B97774.4030401@gmail.com> References: <2A76E400AC84B845AAC35AA19F8E7A5D0D712152@MUNEXBE1.medline.com> <8200F04ED2C5EF40B246388AD4B822A512D5C5F7@BL2PRD0512MB662.namprd05.prod.outlook.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D712204@MUNEXBE1.medline.com> <50B97774.4030401@gmail.com> Message-ID: On Nov 30, 2012, at 7:20 PM, William Allen Simpson wrote: > As well you could be, because you appear to have the same name as a > registered sex offender: Hey, that's a fun game: http://www.sexoffenderin.com/reg77161/william_a_simpsonmugshot.htm From george.herbert at gmail.com Sat Dec 1 05:59:32 2012 From: george.herbert at gmail.com (George Herbert) Date: Fri, 30 Nov 2012 21:59:32 -0800 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: References: <2A76E400AC84B845AAC35AA19F8E7A5D0D71223B@MUNEXBE1.medline.com> <201211302249.qAUMn1iI033496@aurora.sol.net> <2A76E400AC84B845AAC35AA19F8E7A5D0D7122B2@MUNEXBE1.medline.com> Message-ID: Those who do not remember history... On Fri, Nov 30, 2012 at 5:23 PM, wrote: > On Fri, 30 Nov 2012, Naslund, Steve wrote: >> >> My message to the cops and my lawyer would be charge me or lets clear >> this up. There are laws to protect you from the government from taking >> your stuff in an unfair manner if you want to go that route. If there >> is a misunderstanding I will talk to the cops all they want. If I feel >> I need representation, I will get some. If I am really innocent, I >> doubt they could ask me too much that would upset me. My guess is they >> would rather move on in their case instead of spinning their wheels with >> me. > > > http://www.sjgames.com/SS/ > > -Dan > -- -george william herbert george.herbert at gmail.com From ju at netzwerklabor.at Sat Dec 1 06:01:08 2012 From: ju at netzwerklabor.at (Jutta Zalud) Date: Sat, 1 Dec 2012 07:01:08 +0100 Subject: [tor-talk] William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D712152@MUNEXBE1.medline.com> References: <20121130072505.GD9750@leitl.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D712152@MUNEXBE1.medline.com> Message-ID: <1712376494.20121201070108@netzwerklabor.at> am Freitag, 30. November 2012 um 22:30 schrieb NANOG list: > WAIT A SECOND HERE!?!? > I just read below that this guy runs a large ISP in Austria. The info from tor-talk was somewhat misleading. William Weber is not the owner of the ISP. He works there as an administrator. So he runs it (maybe) technically, not economically. See eg: http://www.lowendtalk.com/discussion/2641/we-colo-your-rpi-for-free where his boss "ExPl0ReR" weighs in. And "large" is quite relative. This info http://edis.businesscard.at/ says they have 13 employees. It may be outdated though. Regards, Jutta From patrick at ianai.net Sat Dec 1 10:21:31 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 1 Dec 2012 05:21:31 -0500 Subject: Legal Crap [was: William was raided for running a Tor exit node. Please help if you can.] In-Reply-To: References: Message-ID: <5B4B1A77-3292-4B8A-86B7-B5DBABD9A10C@ianai.net> On Nov 30, 2012, at 20:25 , Randy Bush wrote: >> Not a lawyer. > > than stfu with the legal crap It amazes me how people feel free to opine on things like networking without a certification, but if you don't have a law degree, suddenly they believe you are incapable of understanding anything regarding the law. As for "the legal crap", most of what is posted is not on-topic here. There are laws & legal implications which are operational, though. And even though I am not a lawyer, I need to understand them or I cannot do my job. My lawyer is not going to pick which datacenter to lease, even if he knows a metric-ass-ton more about indemnification than I ever will (at least I hope than I ever will - that shit is BOOOOOOOOOORING). I appreciate people who have researched and understand the topic giving their insights - just like I do regarding BGP, MPLS, IPv6... okay, no jokes about IPv6. :) And, just like with networking topics, I do not appreciate people taking up 10K+ of their not-so-closest-friends' time with half-baked ideas from people who have not taken the time to understand the subject matter. However, I do not believe the only way to go from the latter group into the former is to pass the bar. (And if so, in what state/country? what specialty? etc., etc.) I guess this is a long-winded way of saying: If all you have to say is "STFU", maybe you should take your own advice? -- TTFN, patrick From eugen at leitl.org Sat Dec 1 15:50:32 2012 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 1 Dec 2012 16:50:32 +0100 Subject: [liberationtech] Internet back in Syria Message-ID: <20121201155032.GQ9750@leitl.org> ----- Forwarded message from Rafal Rohozinski ----- From: Rafal Rohozinski Date: Sat, 1 Dec 2012 10:39:24 -0500 To: liberationtech Technologies Subject: [liberationtech] Internet back in Syria Reply-To: liberationtech Secdev detected BGP announcements from Syria as of 7:30 AM Eastern standard time. For our initial monitoring we look at the updates that are broadcast, because dumps of those are available every 15 minutes. However a more complete status is available every two hours, which will provide better insight into when the return of the address space was stabilized. How resources across the country are now reporting connectivity in a number of cities. Rafal Sent by SecDev secure mobile. Please excuse typos or other oddities. -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From bzs at world.std.com Sat Dec 1 16:05:30 2012 From: bzs at world.std.com (Barry Shein) Date: Sat, 1 Dec 2012 11:05:30 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> Message-ID: <20666.10954.936044.8440@world.std.com> On November 30, 2012 at 17:02 raysonlogin at gmail.com (Rayson Ho) wrote: > > And what if the TOR exit node was in the cloud? Are they going to > confiscate millions of servers just because a few of them were hosting > child pornography?? Based on the recent experiences of Megaupload I think the answer to that is an unqualified yes. http://www.telepresenceoptions.com/2012/11/megaupload_and_the_governments/ or http://tinyurl.com/cj7wjzz -- -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 jfmezei_nanog at vaxination.ca Sat Dec 1 16:10:21 2012 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 01 Dec 2012 11:10:21 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20664.61792.77457.146095@world.std.com> References: <20663.35479.561328.722417@world.std.com> <20663.41534.80038.454363@world.std.com> <20121130071804.GA28545@nike.aronius.se> <20664.61792.77457.146095@world.std.com> Message-ID: <50BA2BED.7020207@vaxination.ca> The BBC has an article about a similar issue on a Tor exit node in Austria: Austrian police raid privacy network over child porn http://www.bbc.co.uk/news/technology-20554788 ## Austrian police have seized servers that were part of a global anonymous browsing system, after images showing child sex abuse were found passing through them. Many people use the Tor network to conceal their browsing activity. Police raided the home of William Weber, who ran the servers, and charged him with distributing illegal images. ## It is unfortunate that systems in place to allow free speech end up being abused for the wrong purposes. The same applies to anonymous remailers which have been used to stalk and harass/bully people often using forged email addresses (since those remailers allow one to forge the sender's email address instead of forcing an "Anonymous" sender email. If Tor servers are just glorified routers then they could be considered more as transit providers and not responsible for content transiting through them. However, if a transit service goes out of its way to hide the identity of the sender of a packet to make it untraceable, then it becomes more than a simpler "carrier". From jgreco at ns.sol.net Sat Dec 1 16:36:56 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 1 Dec 2012 10:36:56 -0600 (CST) Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: Message-ID: <201212011636.qB1GauOF048830@aurora.sol.net> > Those who do not remember history... > > On Fri, Nov 30, 2012 at 5:23 PM, wrote: > > http://www.sjgames.com/SS/ Those who do not remember history... what, exactly? We're doomed to repeat this over and over even if we remember it. Even if we were to assume that there are no "bad actors" in law enforcement, what happens when someone is simply faced with something so complex that they don't really understand it? The conventional wisdom is to seize it and let experts work it out. But there is the possibility of there being so much data, and such complexity in modern systems. What happens when you've got a Mac and you're running VMware Fusion and you've got VM images sitting on a NAS device? Ten or twenty years ago, "nab all the media" was pretty straightforward in the average case, but these days, it's pretty easy even for Joe Sixpack to have some sophistication and to be storing stuff on a NAS device. If you have an iomega ix2-dl with two 4TB hard drives in it, and the thing only reads out at ~60MB/sec, how do you effectively deal with that? You can either seize it or not. You can't realistically analyze the whole thing on site. You can't realistically copy it in place (two days to read it all!). So you seize it. And what happens when it is reliant on other stuff on the local network? And what happens when the police can't quite figure out the way everything worked together? Heaven help us when we start talking about tech-sophisticated users who employ things like encryption and run multiple levels of abstractions. And that brings us to Tor... The flip side to the coin is that there is such little disincentive to be aggressive in seizures. There are any number of examples of overreach, and since there is virtually no personal risk to the authorities responsible, even if the company is successful in filing suit (see SJ Games). The authorities have one hell of a problem going forward. I hope that part is obvious. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From rsk at gsp.org Sat Dec 1 16:50:26 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 1 Dec 2012 11:50:26 -0500 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <201212011636.qB1GauOF048830@aurora.sol.net> References: <201212011636.qB1GauOF048830@aurora.sol.net> Message-ID: <20121201165026.GA14245@gsp.org> On Sat, Dec 01, 2012 at 10:36:56AM -0600, Joe Greco wrote: > Even if we were to assume that there are no "bad actors" in law > enforcement, what happens when someone is simply faced with something > so complex that they don't really understand it? The conventional > wisdom is to seize it and let experts work it out. There is another problem with that approach. Actually, two, one that affects us, one that bears on the root cause. We all know, or should know, that there are a couple hundred million zombies (aka bots) out there. Nobody knows exactly how many, of course, because it's impossible to know. But any estimate under 100M should be discarded immediately, and I think numbers in the 200M to 300M are at least plausible, if not probable. Those systems are pretty much EVERYWHERE. The thing is, we don't know specifically where until either (a) they do something that's externally observable that indicates they're zombies AND someone in a position to observe it makes the observation or (b) someone does a forensic-grade examination of them -- which is often what it takes to find some of the more devious malware. There is nothing at all that stops child porn types from leasing zombies or creating their own. There is also nothing stopping them from setting those systems up to transmit/receive child porn via HTTP/S or SMTP or FTP or any other protocol. Or through a VPN or whatever. No Tor required. So -- five minutes from now -- you (generic you) could suddenly be in a position where what happened to this guy is happening to you, because 7 zombies on your network just went active and started shovelling child porn. And you probably won't know it because the traffic will be noise buried in all the other noise. That is, until the authorities, whoever they are wherever you are, show up and confiscate everything, including desktops, laptops, servers, tablets, phones, printers, everything with a CPU. And why shouldn't they? Do you think you're immune to this? Why should you be? Because you're an ISP? A Fortune 500 company? A major university? Joe's Donut Shop? Why should *you* get a pass from this treatment? My point, which I suppose I should get to, is this: This tactic (confiscating everything) is simply not a sensible response by any law enforcement agency. It's bad police work. It's lazy. It's stupid. And worse than any of THAT, it *helps* the child porn types do their thing. (Why? Because it clearly signals the nature and location and time of a security breach. This helps them avoid capture and provides useful intelligence that can be used to design the next operation.) The right tactic is to keep all that gear exactly where it is and doing exactly what it's doing. The children who have already been horribly, tragically exploited will not be any more so if those systems keep running: that damage is done and unplugging computers won't fix it. But keeping that stuff in place and figuring how to start tracing the purveyors and producers, THAT will attack the root cause of the problem, so that maybe other children will be spared, and the people responsible brought to justice. I know it's unfashionable for police to, you know, actually engage in police work any more. It's tedious, boring, and doesn't make headlines. It's much easier to hold self-congratulory press conferences, torture helpless people with tasers, and try to out-do Stasi by setting up a surveillance state. But it would be nice if someone with a clue got them to stop supporting child porn by virtue of being so damn lazy, ignorant and incompetent. TL;DR: try a rapier rather than a bludgeon. ---rsk From jeff at ocjtech.us Sat Dec 1 18:37:37 2012 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Sat, 1 Dec 2012 12:37:37 -0600 Subject: Legal Crap [was: William was raided for running a Tor exit node. Please help if you can.] In-Reply-To: <5B4B1A77-3292-4B8A-86B7-B5DBABD9A10C@ianai.net> References: <5B4B1A77-3292-4B8A-86B7-B5DBABD9A10C@ianai.net> Message-ID: On Sat, Dec 1, 2012 at 4:21 AM, Patrick W. Gilmore wrote: > > It amazes me how people feel free to opine on things... Actually, what really bugs/amazes me about that thread is that the person whom this thread was originally about IS NOT EVEN FROM THE UNITED STATES OF AMERICA. CALEA, DMCA, yadda, yadda, yadda have nothing at all to do with the original problem. -- Jeff Ollie From george.herbert at gmail.com Sat Dec 1 18:46:12 2012 From: george.herbert at gmail.com (George Herbert) Date: Sat, 1 Dec 2012 10:46:12 -0800 Subject: Legal Crap [was: William was raided for running a Tor exit node. Please help if you can.] In-Reply-To: References: <5B4B1A77-3292-4B8A-86B7-B5DBABD9A10C@ianai.net> Message-ID: On Dec 1, 2012, at 10:37 AM, Jeffrey Ollie wrote: > On Sat, Dec 1, 2012 at 4:21 AM, Patrick W. Gilmore wrote: >> >> It amazes me how people feel free to opine on things... > > Actually, what really bugs/amazes me about that thread is that the > person whom this thread was originally about IS NOT EVEN FROM THE > UNITED STATES OF AMERICA. > > CALEA, DMCA, yadda, yadda, yadda have nothing at all to do with the > original problem. True, but false. The original incident in Austria was being used as an argument against anonymous networks in the US or elsewhere. For US persons the relevant laws here are relevant to that followup discussion. George William Herbert Sent from my iPhone From mysidia at gmail.com Sat Dec 1 19:01:36 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 1 Dec 2012 13:01:36 -0600 Subject: Legal Crap [was: William was raided for running a Tor exit node. Please help if you can.] In-Reply-To: <5B4B1A77-3292-4B8A-86B7-B5DBABD9A10C@ianai.net> References: <5B4B1A77-3292-4B8A-86B7-B5DBABD9A10C@ianai.net> Message-ID: On 12/1/12, Patrick W. Gilmore wrote: > On Nov 30, 2012, at 20:25 , Randy Bush wrote: > As for "the legal crap", most of what is posted is not on-topic here. There > are laws & legal implications which are operational, though. And even > though I am not a lawyer, I need to understand them or I cannot do my job. > My lawyer is not going to pick which datacenter to lease, even if he knows a Laws and legal ramifications are a driving force impacting design and policy for network operations, because they have financial implications, and finance matters. For example, if you or your orgs' staff are denied access to your equipment or data and critical servers are seized or offlined, while a police investigation is ongoing, due to a breach of PII confidentiality (eg Stolen social security numbers of staff members used by an ID thief), for example, there is possible hardship for the org, even if you or your org fully exercised due care and went well beyond the minimum: with a responsible well-thought security program, and the offender is an outsider, you might soon not have a network, due to bankruptcy. In this case you might not have any "liability" or guilt for the breach, but you have major costs, regardless. Anyone, including people off the street, can have opinions about the Law, and opinions about networks. Would you be willing to rely some stranger off the street, with no qualifications, or positive background whatsoever, to start recommending a new network design, or give them a CLI with directions that they can start making whatever changes they like to your core router? Would you ask how to configure an AP to be secure, on a network law discussion list? Opinions are one thing; but a large amount of legal mumbo jumbo, and attempting to suggest you have exactly what a court would find, or what the exact and only issues are, that list members can't responsibly rely on anyways (DUE to its importance not its non-importance), is a waste of bits, and there might be a more appropriate place to discuss law itself. :) -- -JH From dhc2 at dcrocker.net Sat Dec 1 19:18:20 2012 From: dhc2 at dcrocker.net (Dave Crocker) Date: Sat, 01 Dec 2012 11:18:20 -0800 Subject: Legal Crap [was: William was raided for running a Tor exit node. Please help if you can.] In-Reply-To: References: <5B4B1A77-3292-4B8A-86B7-B5DBABD9A10C@ianai.net> Message-ID: <50BA57FC.5070008@dcrocker.net> On 12/1/2012 11:01 AM, Jimmy Hess wrote: > Anyone, including people off the street, can have opinions about the > Law, and opinions about networks. Would you be willing to rely > some stranger off the street, with no qualifications, or positive > background whatsoever, to start recommending a new network design, quite possibly. strangers off the street sometimes demonstrate superior insight than credentialed 'experts'. not typically, of course, but sometimes. an essential point is how much work i want to do to assess the credibility of the comments from either source. folks who rely on their credentials for credibility tend to lose it with me. anyone who makes a point by clearly providing a solid basis for it tends to gain it. but i agree that clarity about the purpose of this thread would be helpful... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From amitchell at isipp.com Sat Dec 1 19:28:41 2012 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Sat, 1 Dec 2012 12:28:41 -0700 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: Message-ID: > Example of an actual warrant: > > > https://www.eff.org/sites/default/files/filenode/inresearchBC/EXHIBIT-A.pdf Please also keep in mind, if it's relevant, that *no warrant* is required for data that is stored by a third-party. Data on a server, TOR or otherwise, would by definition be data that is stored by a third party. Which means that if there is a person of interest (POI), it would not be terribly hard to get at personal information about the POI that is not on their own private machines. (Here is an article we wrote about that: http://www.theinternetpatrol.com/no-warrant-necessary-for-law-enforcement-to-access-data-stored-in-the-cloud/ ) > Not a lawyer. Is a lawyer, but hasn't been following this thread. That said, if there are specific questions, I'd be happy to answer them if I can. Anne Anne P. Mitchell, Esq CEO/President Institute for Social Internet Public Policy http://www.ISIPP.com Member, Cal. Bar Cyberspace Law Committee From ju at netzwerklabor.at Sat Dec 1 19:33:05 2012 From: ju at netzwerklabor.at (Jutta Zalud) Date: Sat, 1 Dec 2012 20:33:05 +0100 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50BA2BED.7020207@vaxination.ca> References: <20663.35479.561328.722417@world.std.com> <20663.41534.80038.454363@world.std.com> <20121130071804.GA28545@nike.aronius.se> <20664.61792.77457.146095@world.std.com> <50BA2BED.7020207@vaxination.ca> Message-ID: <777086370.20121201203305@netzwerklabor.at> > The BBC has an article about a similar issue on a Tor exit node in Austria: > Austrian police raid privacy network over child porn > http://www.bbc.co.uk/news/technology-20554788 actually it is not a "similar case" but the case of William W. that BBC reported. Though with some mistakes: the servers were not seized, the hardware (drives etc) at his home was seized, William was not charged (he says), police is just investigating. http://www.lowendtalk.com/discussion/6283/raided-for-running-a-tor-exit-accepting-donations-for-legal-expenses/p5 And so far only the police know if "images showing child sex abuse" were actually "found passing through them" as BBC writes. The warrent posted at arstechnica.net http://cdn.arstechnica.net/wp-content/uploads/2012/11/Beschluss.png mentions section 207a, para 2, 2nd case, and para 4 no 2, lit b of Austrian Criminal Code, which would be possession of a a pornographic depiction of a minor person over 14, showing their genitals in an obscene manner. (the text of the relevant section in German: http://www.ris.bka.gv.at/Dokumente/Bundesnormen/NOR40105143/NOR40105143.html) The warrent does not mention anything that refers to distribution or transport of pornographic images. So, either police and judge were not aware that it was a TOR server or they have/had a suspicion that's not related to running a TOR server. Or the made a mistake and quoted the wrong section. We simply don't know at present. regards, jutta am Samstag, 01. Dezember 2012 um 17:10 schrieb nanog at nanog.org: > The BBC has an article about a similar issue on a Tor exit node in Austria: > Austrian police raid privacy network over child porn > http://www.bbc.co.uk/news/technology-20554788 > ## > Austrian police have seized servers that were part of a global anonymous > browsing system, after images showing child sex abuse were found passing > through them. <...> From matthew at matthew.at Sat Dec 1 16:43:52 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 01 Dec 2012 16:43:52 +0000 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> Message-ID: <50BA33C8.4060709@matthew.at> On 11/27/2012 11:48 PM, Owen DeLong wrote: >>> I agree that some of it comes down to knowledge; most programmers >>> learn from experience and lets face it unless you go looking your >>> unlikely to run into IPv6 even as of yet. I believe as the ISP >>> implements IPv6 and companies get more demand on the customer facing >>> side of things it will pick up quickly. >> Sure, using gethostbyname() is certainly easier to find code examples, but not impossible to find other examples. >> > http://owend.corp.he.net/ipv6 > > Pretty much everything you need to know about taking your applications from mono-stack to dual-stack. "Everything you need to know" except for how to actually accomplish this task in the real world. In order to accomplish this in the real world using present-day software development methodologies you would need to do a few more things: - Generate some user stories that explain why the IPv6-supporting code needs to be written - Break these user stories down into backlog items and convince the product manager to place these items into the backlogs of the dozens or more interacting teams that need to write the code - Add all of the backlog items for all of the interworking pieces so that, for instance, automated monitoring tools that are watching the IPv4 services will now be watching the IPv6 services as well... capacity planning will be able to account for IPv6 growth... etc. - Convince the product manager (along with other departments like marketing and executive management) that adding support for IPv6 to an existing working product is *more important* than meeting internal and external requests for features and fixing known bugs - Develop a test plan so that the various interworking parts of your system may be tested internally once IPv6 support is added to ensure that not only does IPv6 now work but that the existing IPv4 functionality is not broken as a result - Write the code when the work makes its way to the top of the backlog - Wait for the infrastructure environment to be upgraded to support running IPv6 in production - Test the new IPv6 functionality and verify that none of the IPv4 functionality is broken - Deploy to customers - Receive bug reports - Prioritize bugs that have been created that affect IPv4 customers and IPv6 customers appropriately such that the IPv6 bugs ever get fixed - Iterate I'm sure I've missed a few steps. > > Includes an example application implemented in IPv4 only and ported to dual stack in C, PERL, and Python. Unfortunately the "example application" is less than 1M lines of code and fewer than a a few hundred different servers plus client applications. > >>> In our datacenters all our software is built with IPv6 addressing >>> supported but we have yet to build the logic stack as we are waiting >>> for the demand. It makes no sense to build all the support just >>> because when there are other important things to do. +1 on this for sure. >> There is something else. Many people "cheated" and stuck a 2^32 number in an integer datatype for their SQL or other servers. They don't work as well with 2^128 sized IPs. They have to undertake the actual effort of storing their data in a proper datatype instead of cheating. I've seen this over-and-over and likely is a significant impediment just as the gethostbyname vs getaddrinfo() system call translations may be. >> One of many issues that will come up. Along with the lack of support for IPv6 in the infrastructure, or the monitoring tools, or the automated test systems, or whatever. > It's actually pretty easy to change the datatype in an SQL database, so that shouldn't be that much of an impediment. > If only A) it were that simple and B) going in and changing data types for columns didn't have audit implications, data replication implications, data warehousing and analysis system implications, etc. Matthew Kaufman ps. I work for a division of my employer that does not yet have IPv6 support in its rather popular consumer software product. Demand for IPv6 from our rather large customer base is, at present, essentially nonexistent, and other things would be way above it in the stack-ranked backlog(s) anyway. One could argue that until we add IPv6 support throughout our systems, consumers will continue to demand IPv4 connectivity from operators in order to run software like ours, rather than us being cut off from any meaningful proportion of customers. pps. And until we were last acquired, we *didn't* have IPv6 at our developer's desktops. Now we do, but it doesn't connect to the global IPv6 Internet (yet). From ml at kenweb.org Sun Dec 2 01:20:51 2012 From: ml at kenweb.org (ML) Date: Sat, 01 Dec 2012 20:20:51 -0500 Subject: When an ISP should run their own IRR for customers Message-ID: <50BAACF3.4040204@kenweb.org> I'm querying the community on the feasibility of running my own IRR on behalf of customers whom probably aren't/won't register their own objects. I'm going down this path since I don't believe RADB or ARIN would let me register objects on behalf of my customers. I know I'm going to need this in the near future once my AS starts to peer. Conservatively I would be proxy registering about 100 customers. Would a potential upstream/peer NOT want to query my IRR because I'm not RADB, ARIN, etc (Essentially not a well known registry)? If not, is it likely my IRR could get mirrored by RADB so other networks can retrieve good info via RADB. If I was to run my own IRR is Merit's IRRd they way to go or is there something better? Thanks From mysidia at gmail.com Sun Dec 2 04:55:04 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 1 Dec 2012 22:55:04 -0600 Subject: When an ISP should run their own IRR for customers In-Reply-To: <50BAACF3.4040204@kenweb.org> References: <50BAACF3.4040204@kenweb.org> Message-ID: On 12/1/12, ML wrote: > I'm querying the community on the feasibility of running my own IRR on > behalf of customers whom probably aren't/won't register their own > objects. I'm going down this path since I don't believe RADB or ARIN > would let me register objects on behalf of my customers. It doesn't seem like a terribly good reason to want to start a new IRR. I wouldn't expect RADB to mirror. What brought you to the actual conclusion you won't be able to register the customer route objects, after receiving authorization from the customer? Last I checked, on RADB it's technically possible for any paying maintainer to register a route object, as long as it's not already registered under another mnt-by; LEVEL3 and some others have in the past commonly created proxy-registered routes for customers' non-existent routes to facilitate the creation of automatic route filtering policy definitions. And there are some AS objects that also say they are proxy registered in the remarks or description sections... $ whois -h whois.radb.net as32114 aut-num: AS32114 as-name: WalkerMachine descr: This is a Proxy registered AS for Walker Machine by Lumos Networks. .... mnt-by: MAINT-AS7795 ... -- -JH From owen at delong.com Sun Dec 2 07:55:57 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 1 Dec 2012 23:55:57 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50BA33C8.4060709@matthew.at> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> <50BA33C8.4060709@matthew.at> Message-ID: > > ps. I work for a division of my employer that does not yet have IPv6 support in its rather popular consumer software product. Demand for IPv6 from our rather large customer base is, at present, essentially nonexistent, and other things would be way above it in the stack-ranked backlog(s) anyway. One could argue that until we add IPv6 support throughout our systems, consumers will continue to demand IPv4 connectivity from operators in order to run software like ours, rather than us being cut off from any meaningful proportion of customers. > Yes, but unlike Skype, most popular applications have competitors and whichever competitor provides the better user experience will cut the others off from a meaningful proportion of their customers. Owen From james.braunegg at micron21.com Sun Dec 2 10:17:47 2012 From: james.braunegg at micron21.com (James Braunegg) Date: Sun, 2 Dec 2012 10:17:47 +0000 Subject: DDOS hardware appliances for network security - Arbor Pravail APS vs nsFocus ADS 6020 - Reviews - Feedback Message-ID: Dear Nanog I would like to start a discussion on network security DDOS hardware appliances, mainly compairing the Arbor Pravail APS device vs the nsFocus ADS6020 device as I am looking at investing in such a product and would love to hear some industry feedback, reviews, information and from vendors etc. To provide some background information we are looking at a device for inline filtering to clean / filter out unwanted traffc inbound towards our network automaticaly. That being said I'm also happy to hear from other suppliers of appliances (not sure who else there is) or recomendations. For those who don't know much about either device the Arbor Pravail fact sheet can be found here http://www.arbornetworks.com/component/docman/doc_download/498-pravail-aps-data-sheet-english?Itemid=442 Like wise the fact sheet for the nsFocus ADS product can be found here http://www.nsfocus.com/en/uploadfile/Product/ADS/Datasheet/NSFOCUS%20ADS%20Data%20Sheet.pdf Until recently I was only aware of the Arbor device, although after doing some research I quicky came up with another options, I'm sure many other people have asked / looked into the same questions before so let the debate begin... Kindest Regards James Braunegg W: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 E: james.braunegg at micron21.com | ABN: 12 109 977 666 [Description: Description: Description: Description: M21.jpg] 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2683 bytes Desc: image001.jpg URL: From dennis at justipit.com Sun Dec 2 13:12:15 2012 From: dennis at justipit.com (Dennis Usle) Date: Sun, 02 Dec 2012 08:12:15 -0500 Subject: DDOS hardware appliances for network security - Arbor Pravail APS vs nsFocus ADS 6020 - Reviews - Feedback Message-ID: Checkout Radware Defense Pro. It offers some very innovative approaches to network and application attack mitigation. I particularly like the NBA and real time signatures. James Braunegg wrote: >Dear Nanog > > > >I would like to start a discussion on network security DDOS hardware appliances, mainly compairing the Arbor Pravail APS device vs the nsFocus ADS6020 device as I am looking at investing in such a product and would love to hear some industry feedback, reviews, information and from vendors etc. > > > >To provide some background information we are looking at a device for inline filtering to clean / filter out unwanted traffc inbound towards our network automaticaly. > > > >That being said I'm also happy to hear from other suppliers of appliances (not sure who else there is) or recomendations. > > > >For those who don't know much about either device the Arbor Pravail fact sheet can be found here > > > >http://www.arbornetworks.com/component/docman/doc_download/498-pravail-aps-data-sheet-english?Itemid=442 > > > >Like wise the fact sheet for the nsFocus ADS product can be found here > > > >http://www.nsfocus.com/en/uploadfile/Product/ADS/Datasheet/NSFOCUS%20ADS%20Data%20Sheet.pdf > > > >Until recently I was only aware of the Arbor device, although after doing some research I quicky came up with another options, I'm sure many other people have asked / looked into the same questions before so let the debate begin... > > > >Kindest Regards > >James Braunegg >W: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 >E: james.braunegg at micron21.com | ABN: 12 109 977 666 > >[Description: Description: Description: Description: M21.jpg] > >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. > > > From bzs at world.std.com Sun Dec 2 17:54:35 2012 From: bzs at world.std.com (Barry Shein) Date: Sun, 2 Dec 2012 12:54:35 -0500 Subject: Legal Crap [was: William was raided for running a Tor exit node. Please help if you can.] In-Reply-To: <50BA57FC.5070008@dcrocker.net> References: <5B4B1A77-3292-4B8A-86B7-B5DBABD9A10C@ianai.net> <50BA57FC.5070008@dcrocker.net> Message-ID: <20667.38363.328873.726375@world.std.com> I think one error being made here is discussing the culpability of law enforcement per se. That's like blaming the UPS delivery person because something you bought from Amazon was misleading. Or praising him/her because it was great. One way of asserting authority over any property is making very visible arrests and similar (shutdowns, etc.) If you follow the Internet Governance sphere a lot of what is going on is a frantic power grab by various players, particularly govts but also NGOs, for control of the internet. This is being heightened by the competitiveness involved, if one player grabs it before you do then you LOST THE GAME! Even when they haven't a clue (or only barely) what they're fighting over surely they can understand that it is bad to LOSE THE GAME! Particularly to players you don't much like or trust. As the great VP Dan Quayle was once quoted as saying: If we don't succeed then we run the risk of failure!* And that these players are finally figuring out just how powerful the internet is, at least potentially. Yeah you can say this has been going on for (insert your own professional life time in years which is what people do.) Heck, the whole thing was basically started by the US Dept of Defense, end of argument, talk about a power player! But that's sort of like saying that people were trying to capitalize on the internet for years before the dot com bubble of the late 90s. It misses the point. Yes you can find examples, no you can't find the kind of activity and earnestness we're seeing of late. * If you try to debate, confirm, etc that quote you're a loutish bore, it stand on its own :-) -- -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 l-nanog at iodi.se Sun Dec 2 19:25:32 2012 From: l-nanog at iodi.se (Joseph Chin) Date: Sun, 2 Dec 2012 19:25:32 -0000 Subject: DDOS hardware appliances for network security - Arbor Pravail APS vs nsFocus ADS 6020 - Reviews - Feedback In-Reply-To: References: Message-ID: <063101cdd0c2$cd179500$6746bf00$@iodi.se> If all you need is initial mitigation against fairly basic flood type attack vectors, then the Radware and a host of other similar appliances, should do the job. I know Radware is in the stack of a few very successful DDoS mitigation services. But if you intend to offer a premium DDoS mitigation service, then you should invest in the likes of Arbor. The Arbor Fingerprint Sharing Alliance is a big time value-add and their support organization (including ArborSERT) is top-notch. In addition to good marketing, there are sound technical reasons why Arbor is found in the mitigation stacks of most top-tier service providers. Whatever on-premise mitigation solution you implement, I also strongly recommend forming a commercial alliance with a dedicated mitigation service provider (e.g. Prolexic, Verisign, DOSarrest) so that you have a contingency plan for when the attacks get too big/sophisticated to effectively mitigate without affecting your infrastructure and your ability to meet SLAs to other customers. When sh*t hits the fan, it is good to be able to get the targeted /24 off your transit/peering links. Lastly, successful mitigation requires that you have excellent relationship along with well-rehearsed playbook (e.g. for ACL and null-routing) in place with all your transit/peering links. -----Original Message----- From: Dennis Usle [mailto:dennis at justipit.com] Sent: Sunday, December 02, 2012 1:12 PM To: James Braunegg Cc: nanog at nanog.org Subject: Re: DDOS hardware appliances for network security - Arbor Pravail APS vs nsFocus ADS 6020 - Reviews - Feedback Checkout Radware Defense Pro. It offers some very innovative approaches to network and application attack mitigation. I particularly like the NBA and real time signatures. James Braunegg wrote: >Dear Nanog > > > >I would like to start a discussion on network security DDOS hardware appliances, mainly compairing the Arbor Pravail APS device vs the nsFocus ADS6020 device as I am looking at investing in such a product and would love to hear some industry feedback, reviews, information and from vendors etc. > > > >To provide some background information we are looking at a device for inline filtering to clean / filter out unwanted traffc inbound towards our network automaticaly. > > > >That being said I'm also happy to hear from other suppliers of appliances (not sure who else there is) or recomendations. > > > >For those who don't know much about either device the Arbor Pravail fact sheet can be found here > > > >http://www.arbornetworks.com/component/docman/doc_download/498-pravail-aps-data-sheet-english?Itemid=442 > > > >Like wise the fact sheet for the nsFocus ADS product can be found here > > > >http://www.nsfocus.com/en/uploadfile/Product/ADS/Datasheet/NSFOCUS%20ADS%20Data%20Sheet.pdf > > > >Until recently I was only aware of the Arbor device, although after doing some research I quicky came up with another options, I'm sure many other people have asked / looked into the same questions before so let the debate begin... > > > >Kindest Regards > >James Braunegg >W: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616 >E: james.braunegg at micron21.com | ABN: 12 109 977 666 > >[Description: Description: Description: Description: M21.jpg] > >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. > > > From matthew at matthew.at Sun Dec 2 19:27:53 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 02 Dec 2012 11:27:53 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> <50BA33C8.4060709@matthew.at> Message-ID: <50BBABB9.5060801@matthew.at> On 12/1/2012 11:55 PM, Owen DeLong wrote: > Yes, but unlike Skype, most popular applications have competitors and > whichever competitor provides the better user experience will cut the > others off from a meaningful proportion of their customers. Owen I think you're assuming some magic that lets one of the competitors bypass all the steps I outlined in order to support IPv6 while the other takes "forever" to get to it. Matthew Kaufman From mike at mtcc.com Sun Dec 2 19:44:31 2012 From: mike at mtcc.com (Michael Thomas) Date: Sun, 02 Dec 2012 11:44:31 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> <50BA33C8.4060709@matthew.at> Message-ID: <50BBAF9F.409@mtcc.com> On 12/01/2012 11:55 PM, Owen DeLong wrote: >> ps. I work for a division of my employer that does not yet have IPv6 support in its rather popular consumer software product. Demand for IPv6 from our rather large customer base is, at present, essentially nonexistent, and other things would be way above it in the stack-ranked backlog(s) anyway. One could argue that until we add IPv6 support throughout our systems, consumers will continue to demand IPv4 connectivity from operators in order to run software like ours, rather than us being cut off from any meaningful proportion of customers. >> > Yes, but unlike Skype, most popular applications have competitors and whichever competitor provides the better user experience will cut the others off from a meaningful proportion of their customers. > You have a really strange metric of what constitutes a "better user experience". I look at things like enrollment/take rates, friending, reviews, etc to determine whether people are having a better user experience. I can with all sincerity say that ipv6 is not something that provides a "better user experience". I enabled it for my site just because I was curious and linode makes getting v6 dead simple and I didn't think I had anything that would puke on v6 (I didn't). If it took any more effort than that, I'd have gone and found something else to be curious about because it wouldn't have been worth my time given things that really do impact user experience. Mike From cb.list6 at gmail.com Sun Dec 2 20:36:05 2012 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 2 Dec 2012 12:36:05 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: <50BA33C8.4060709@matthew.at> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> <50BA33C8.4060709@matthew.at> Message-ID: > "Everything you need to know" except for how to actually accomplish this > task in the real world. > > In order to accomplish this in the real world using present-day software > development methodologies you would need to do a few more things: > - Generate some user stories that explain why the IPv6-supporting code needs > to be written > - Break these user stories down into backlog items and convince the product > manager to place these items into the backlogs of the dozens or more > interacting teams that need to write the code > - Add all of the backlog items for all of the interworking pieces so that, > for instance, automated monitoring tools that are watching the IPv4 services > will now be watching the IPv6 services as well... capacity planning will be > able to account for IPv6 growth... etc. > - Convince the product manager (along with other departments like marketing > and executive management) that adding support for IPv6 to an existing > working product is *more important* than meeting internal and external > requests for features and fixing known bugs > - Develop a test plan so that the various interworking parts of your system > may be tested internally once IPv6 support is added to ensure that not only > does IPv6 now work but that the existing IPv4 functionality is not broken as > a result > - Write the code when the work makes its way to the top of the backlog > - Wait for the infrastructure environment to be upgraded to support running > IPv6 in production > - Test the new IPv6 functionality and verify that none of the IPv4 > functionality is broken > - Deploy to customers > - Receive bug reports > - Prioritize bugs that have been created that affect IPv4 customers and IPv6 > customers appropriately such that the IPv6 bugs ever get fixed > - Iterate > > I'm sure I've missed a few steps. > There is another case where the customer does not ask for it. I don't think Google or Facebook's or Bing's customers meaningfully asked for v6, yet they did it. Same thing with Verizon LTE. Maybe the Bing folks can help you with internal strategies for getting support. > > > > Matthew Kaufman > > ps. I work for a division of my employer that does not yet have IPv6 support > in its rather popular consumer software product. Demand for IPv6 from our > rather large customer base is, at present, essentially nonexistent, and Nonexistent demand? Let's bing it and decide http://www.bing.com/search?q=skype+ipv6 Interesting hits my query are http://community.skype.com/t5/Android/Skype-not-working-on-T-Mobile-USA-IPv6-with-UMTS-unlocked-Galaxy/td-p/380685 http://www.zdnet.com/voip-and-instant-messaging-problem-looming-skype-doesnt-support-ipv6-7000007058/ http://www.gossamer-threads.com/lists/nsp/ipv6/33334 http://www.change.org/petitions/skype-add-ipv6-support-to-skype http://www.gossamer-threads.com/lists/nsp/ipv6/41499 But, this is just the same old carping. Skype / Microsoft should add IPv6 support because it is the right thing to do for the Internet. Microsoft, like Google and Facebook, was part of world v6 launch and knows ipv6 is about making the internet better and bigger. The Skype issue is so serious, that it is specifically blocking IPv6-only architectures since it is THE most major app that breaks in IPv6-only. Skype is the killer app for 464XLAT ... which means that since Skype refuses to evolve their product, the OS now has to have hacks to fix it. CB > other things would be way above it in the stack-ranked backlog(s) anyway. > One could argue that until we add IPv6 support throughout our systems, > consumers will continue to demand IPv4 connectivity from operators in order > to run software like ours, rather than us being cut off from any meaningful > proportion of customers. > > pps. And until we were last acquired, we *didn't* have IPv6 at our > developer's desktops. Now we do, but it doesn't connect to the global IPv6 > Internet (yet). > From marka at isc.org Sun Dec 2 22:06:00 2012 From: marka at isc.org (Mark Andrews) Date: Mon, 03 Dec 2012 09:06:00 +1100 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: Your message of "Sun, 02 Dec 2012 11:44:31 -0800." <50BBAF9F.409@mtcc.com> References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> <84F8DEBC-C754-4D06-99B0-405CC8A358BD@josephholsten.com> <2EB931D4-6AB0-488A-B4F6-05EDB7DDA1E9@puck.nether.net> <290980E6-647F-4426-BADA-3347BC936DD8@delong.com> <50BA33C8.4060709@matthew.at> <50BBAF9F.409@mtcc.com> Message-ID: <20121202220600.A94612C7C7B9@drugs.dv.isc.org> Adding IPv6 support isn't like adding most new features. It doesn't give most people something extra. It doesn't "enhance the experience". It is insurance for when the CGN is deployed by the ISP or when the ISP goes IPv6 only and like most insurance you don't know when you will needed and you will be happy you have it when it is needed. It will stop you loosing customers because when either of those events happen and they impact on the functionality of the product your customers won't be in a position to wait for your next release. Cost wise adding IPv6 support is cheaper than adding most other features. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From adrian at olddog.co.uk Sun Dec 2 22:28:56 2012 From: adrian at olddog.co.uk (Adrian Farrel) Date: Sun, 2 Dec 2012 22:28:56 -0000 Subject: carping about CARP In-Reply-To: <04A3A2DE-708C-4F52-B4C3-86BE2A628278@delong.com> References: <86pq2vbptg.fsf@seastrom.com> <86ip8n6z11.fsf@seastrom.com> <04A3A2DE-708C-4F52-B4C3-86BE2A628278@delong.com> Message-ID: <004501cdd0dc$6b41f680$41c5e380$@olddog.co.uk> Far be it from me to get involved in a private pissing match, but... Owen wrote: > Perhaps we should ask IETF/IANA to allocate a group of protocol numbers > to "the wild west". A protocol-number equivalent of RFC-1918 or private ASNs. > You can use these for whatever you want, but so can anyone else and if you > do, you do so at your own risk. > > This won't entirely solve the problem, but at least it would provide some > level of shield for protocol numbers that are registered to particular > purposes through the IETF/IANA process. Would that be 253 and 254 "Use for experimentation and testing" per RFC 3692? Of course, no-one like to see their pet protocol designated as an experiment (unless they really believe it is something that should be carefully researched and tried out in a controlled environment), but the garden-walling that you describe seems to fit exactly within the 3692 definitions. Adrian From courtneysmith at comcast.net Sun Dec 2 23:24:39 2012 From: courtneysmith at comcast.net (Courtney Smith) Date: Sun, 2 Dec 2012 18:24:39 -0500 Subject: When an ISP should run their own IRR for customers In-Reply-To: References: Message-ID: On Dec 2, 2012, at 5:18 AM, nanog-request at nanog.org wrote: > > Message: 4 > Date: Sat, 01 Dec 2012 20:20:51 -0500 > From: ML > To: nanog at nanog.org > Subject: When an ISP should run their own IRR for customers > Message-ID: <50BAACF3.4040204 at kenweb.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I'm querying the community on the feasibility of running my own IRR on > behalf of customers whom probably aren't/won't register their own > objects. I'm going down this path since I don't believe RADB or ARIN > would let me register objects on behalf of my customers. > > I know I'm going to need this in the near future once my AS starts to > peer. Conservatively I would be proxy registering about 100 customers. > > Would a potential upstream/peer NOT want to query my IRR because I'm not > RADB, ARIN, etc (Essentially not a well known registry)? If not, is it > likely my IRR could get mirrored by RADB so other networks can retrieve > good info via RADB. > > If I was to run my own IRR is Merit's IRRd they way to go or is there > something better? > > > Thanks > > > > I do not think running your own IRR is worth it for 100 customers. Unless it's something you want to do for your own experience and knowledge. Maintain the objects under your maintainer for customers who, for whatever reason, are unable to maintain their own objects. Just make sure your internal processes address deleting objects when customers leave. Deleting seems to be something folks forget about. Courtney Smith courtneysmith at comcast.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From tech-lists at packet-labs.net Mon Dec 3 02:48:00 2012 From: tech-lists at packet-labs.net (Jay) Date: Sun, 02 Dec 2012 21:48:00 -0500 Subject: carping about CARP In-Reply-To: <004501cdd0dc$6b41f680$41c5e380$@olddog.co.uk> References: <86pq2vbptg.fsf@seastrom.com> <86ip8n6z11.fsf@seastrom.com> <04A3A2DE-708C-4F52-B4C3-86BE2A628278@delong.com> <004501cdd0dc$6b41f680$41c5e380$@olddog.co.uk> Message-ID: <50BC12E0.90505@packet-labs.net> On 12/2/2012 5:28 PM, Adrian Farrel wrote: > Far be it from me to get involved in a private pissing match, but... > > Owen wrote: > >> Perhaps we should ask IETF/IANA to allocate a group of protocol numbers >> to "the wild west". A protocol-number equivalent of RFC-1918 or private ASNs. >> You can use these for whatever you want, but so can anyone else and if you >> do, you do so at your own risk. >> >> This won't entirely solve the problem, but at least it would provide some >> level of shield for protocol numbers that are registered to particular >> purposes through the IETF/IANA process. > > Would that be 253 and 254 "Use for experimentation and testing" per RFC 3692? > > Of course, no-one like to see their pet protocol designated as an experiment > (unless they really believe it is something that should be carefully researched > and tried out in a controlled environment), but the garden-walling that you > describe seems to fit exactly within the 3692 definitions. > > Adrian > > RFC 3692, section 1.1: "Values reserved for experimental use are never to be made permanent; permanent assignments should be obtained through standard processes. As described above, experimental numbers are intended for experimentation and testing and are not intended for wide or general deployments. When protocols that use experimental numbers are included in products, the shipping versions of the products must disable recognition of protocol experimental numbers by default -- that is, the end user of the product must explicitly "turn on" the experimental protocol functionality. In most cases, a product implementation must require the end user to configure the value explicitly prior to enabling its usage. Should a product not have a user interface for such end user configuration, the product must require explicit re-programming (e.g., a special firmware download, or installation of a feature card) to configure the experimental number(s) of the protocol(s) implicitly." Of course the use of 'must' or 'must not' in an RFC never stopped anyone from doing the exact opposite. Jay From joelja at bogus.com Mon Dec 3 05:11:38 2012 From: joelja at bogus.com (Joel jaeggli) Date: Sun, 02 Dec 2012 21:11:38 -0800 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20121130071804.GA28545@nike.aronius.se> References: <20663.35479.561328.722417@world.std.com> <20663.41534.80038.454363@world.std.com> <20121130071804.GA28545@nike.aronius.se> Message-ID: <50BC348A.90500@bogus.com> On 11/29/12 23:18 , Joakim Aronius wrote: > I am all for being anonymous on the net but I seriously believe that > we still need to enforce the law when it comes to serious felonies > like child pr0n, organized crime etc, we can't give them a free pass > just by using Tor. I dont think it should be illegal to operate a Tor > exit node but what just happened could be a consequence of doing it. The seriousness of crimes that can be committed using anonymization services should not be diminished. That said the motive I had for running a tor exit when I did was that speech, and in particular political organization (dare we call it sedition) are in fact very serious crimes in many places. R.g. they can result in indefinite imprisonment, torture, judicial or extra-legal execution and so forth, I don't consider that unserious.. The internet is potentially quite a useful tool for getting your message out so long as using it isn't holding a gun to your own head. While we site here with the convenient idea of some legal arbitrage which allows me to do something which isn't illegal in my own domain to facilitate something that is quite illegal elsewhere, the fact of the matter is if you run a service like this you don't get to pick and choose. From tvhawaii at shaka.com Mon Dec 3 05:44:11 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Sun, 2 Dec 2012 19:44:11 -1000 Subject: William was raided for running a Tor exit node. Please help if you can. References: <20663.35479.561328.722417@world.std.com> <20663.41534.80038.454363@world.std.com> <20121130071804.GA28545@nike.aronius.se> <50BC348A.90500@bogus.com> Message-ID: <2078E1BD482143A38F1B4E0B92597212@owner59e1f1502> Joel jaeggli wrote: > > The internet is potentially quite a useful tool for getting your message > out so long as using it isn't holding a gun to your own head. While we > site here with the convenient idea of some legal arbitrage which allows > me to do something which isn't illegal in my own domain to facilitate > something that is quite illegal elsewhere, the fact of the matter is if > you run a service like this you don't get to pick and choose. In your opinion, would it make *any* kind of semse to engage in child pron AND run an exit node? Thanks, --Michael From nanog at jima.tk Mon Dec 3 06:07:37 2012 From: nanog at jima.tk (Jima) Date: Sun, 02 Dec 2012 23:07:37 -0700 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2078E1BD482143A38F1B4E0B92597212@owner59e1f1502> References: <20663.35479.561328.722417@world.std.com> <20663.41534.80038.454363@world.std.com> <20121130071804.GA28545@nike.aronius.se> <50BC348A.90500@bogus.com> <2078E1BD482143A38F1B4E0B92597212@owner59e1f1502> Message-ID: <50BC41A9.8030901@jima.tk> On 2012-12-02 22:44, Michael Painter wrote: > Joel jaeggli wrote: >> >> The internet is potentially quite a useful tool for getting your message >> out so long as using it isn't holding a gun to your own head. While we >> site here with the convenient idea of some legal arbitrage which allows >> me to do something which isn't illegal in my own domain to facilitate >> something that is quite illegal elsewhere, the fact of the matter is if >> you run a service like this you don't get to pick and choose. > > In your opinion, would it make *any* kind of semse to engage in child > pron AND run an exit node? It makes a little. Last I checked (granted: years ago), a user can steer their traffic to a given exit node; by doing so, they could pick one that they know to have no internal scrutiny (i.e., by the person managing the exit node), while maintaining plausible deniability as to whether the traffic originating from that exit node was theirs, in the event of external scrutiny (as was the case here). I suspect running a middle node (not an exit, not an entrance) would provide a similar or greater degree of plausible deniability, albeit without the assurance of no internal scrutiny of the exit node. Jima From joakim at aronius.se Mon Dec 3 07:19:11 2012 From: joakim at aronius.se (Joakim Aronius) Date: Mon, 3 Dec 2012 08:19:11 +0100 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50BC348A.90500@bogus.com> References: <20663.35479.561328.722417@world.std.com> <20663.41534.80038.454363@world.std.com> <20121130071804.GA28545@nike.aronius.se> <50BC348A.90500@bogus.com> Message-ID: <20121203071911.GA2160@nike.aronius.se> * Joel jaeggli (joelja at bogus.com) wrote: > On 11/29/12 23:18 , Joakim Aronius wrote: > > > I am all for being anonymous on the net but I seriously believe that > > we still need to enforce the law when it comes to serious felonies > > like child pr0n, organized crime etc, we can't give them a free pass > > just by using Tor. I dont think it should be illegal to operate a Tor > > exit node but what just happened could be a consequence of doing it. > > The seriousness of crimes that can be committed using anonymization > services should not be diminished. That said the motive I had for > running a tor exit when I did was that speech, and in particular > political organization (dare we call it sedition) are in fact very > serious crimes in many places. R.g. they can result in indefinite > imprisonment, torture, judicial or extra-legal execution and so forth, I > don't consider that unserious.. > > The internet is potentially quite a useful tool for getting your message > out so long as using it isn't holding a gun to your own head. While we > site here with the convenient idea of some legal arbitrage which allows > me to do something which isn't illegal in my own domain to facilitate > something that is quite illegal elsewhere, the fact of the matter is if > you run a service like this you don't get to pick and choose. I agree. I was about to set up a tor node a few years ago but never got around to it. I send cash to orgs working for human rights in countries with oppressive regimes. I am all for providing anonymized access to help free speech. Perhaps its better with anon access to specific applications like twitter, fb etc and not general internet access. I suspect that the 'free speech' part of the total tor traffic volume is pretty small(?). Cheers, /Joakim From jgreco at ns.sol.net Mon Dec 3 08:22:50 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 3 Dec 2012 02:22:50 -0600 (CST) Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <20121203071911.GA2160@nike.aronius.se> Message-ID: <201212030822.qB38MsPx072907@aurora.sol.net> > I suspect that the 'free speech' part of the total tor traffic volume is pretty small(?). Something like tor doesn't work if it is all traffic that's "free speech" regarding the regime of whatever country the user lives in. If it were, it'd be just as sensible to set a DETAIN_AND_TORTURE_ME bit on your IP traffic instead. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From wbailey at satelliteintelligencegroup.com Mon Dec 3 08:49:24 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 3 Dec 2012 08:49:24 +0000 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <201212030822.qB38MsPx072907@aurora.sol.net> References: <20121203071911.GA2160@nike.aronius.se>, <201212030822.qB38MsPx072907@aurora.sol.net> Message-ID: Speaking of torture.. Can you imagine an email thread that lasted longer than an entire weekend? This email needs to be murdered, because it is completely out of control. In other words, the shit has been mercilessly beat out of this horse. >From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Joe Greco Date: 12/03/2012 12:24 AM (GMT-08:00) To: Joakim Aronius Cc: NANOG list Subject: Re: William was raided for running a Tor exit node. Please help if > I suspect that the 'free speech' part of the total tor traffic volume is pretty small(?). Something like tor doesn't work if it is all traffic that's "free speech" regarding the regime of whatever country the user lives in. If it were, it'd be just as sensible to set a DETAIN_AND_TORTURE_ME bit on your IP traffic instead. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From aledm at qix.co.uk Mon Dec 3 10:36:38 2012 From: aledm at qix.co.uk (Aled Morris) Date: Mon, 3 Dec 2012 10:36:38 +0000 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20121203071911.GA2160@nike.aronius.se> References: <20663.35479.561328.722417@world.std.com> <20663.41534.80038.454363@world.std.com> <20121130071804.GA28545@nike.aronius.se> <50BC348A.90500@bogus.com> <20121203071911.GA2160@nike.aronius.se> Message-ID: On 3 December 2012 07:19, Joakim Aronius wrote: > I am all for providing anonymized access to help free speech. Perhaps its > better with anon access to specific applications like twitter, fb etc and > not general internet access. I suspect that the 'free speech' part of the > total tor traffic volume is pretty small(?). > > > I agree. I can understand that people need to be anonymous when they are going to publicly stand against an oppressive regime, or expose corporate corruption etc. What I'm not sure I believe as strongly is the justification for anonymity in private, closed communication - this is the use case for paedophiles and terrorists organising their crimes. So in my view, anonymous + public = OK, anonymous + private = doubtful. This isn't a solution to the troll or hate crimes problem (anonymous people making statements that are distasteful on public forums) but at least we can all see this going on and develop other solutions. Aled From rsk at gsp.org Mon Dec 3 11:31:02 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 3 Dec 2012 06:31:02 -0500 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> Message-ID: <20121203113102.GA24383@gsp.org> On Mon, Dec 03, 2012 at 08:49:24AM +0000, Warren Bailey wrote: > Can you imagine an email thread that lasted longer than an entire weekend? Yes, I can. I've participated in some that went on for months. It's simply a matter of effectiveness and attention span. > This email needs to be murdered, because it is completely out of control. I disagree, strongly, as this is an issue of unfortunate timely relevance to the community. However, if you, personally, grow tired of the discussion then of course you can use your email client to ignore all messages in the thread -- all superior mail clients make that a trivial exercise. (I recommend mutt, possibly supplemented by procmail. Both tools are suitable for professionals: stable, mature, portable, and extremely efficient.) ---rsk From oscar.vives at gmail.com Mon Dec 3 14:06:56 2012 From: oscar.vives at gmail.com ( .) Date: Mon, 3 Dec 2012 15:06:56 +0100 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <20121203113102.GA24383@gsp.org> References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> Message-ID: The crime of routing somebody else traffic in the wrong iso layer. -- -- ?in del ?ensaje. From mmitar at gmail.com Sun Dec 2 06:33:50 2012 From: mmitar at gmail.com (Mitar) Date: Sat, 1 Dec 2012 22:33:50 -0800 Subject: Fwd: [tor-talk] William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20663.35479.561328.722417@world.std.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121E6@MUNEXBE1.medline.com> Message-ID: Hi! Forwarding my answer to tor-talk list. Mitar ---------- Forwarded message ---------- From: Mitar Date: Sat, Dec 1, 2012 at 12:29 AM Subject: Re: [tor-talk] William was raided for running a Tor exit node. Please help if you can. To: tor-talk at lists.torproject.org Cc: nanog at nanog.org Hi! On Fri, Nov 30, 2012 at 2:09 PM, Naslund, Steve wrote: > Remember, they did not raid the Tor exit node. They raided the home of > the guy running the Tor exit node. Way different. I can probably explain that. We were running a Tor exit node in Slovenia (neighboring country of Austria, EU too). We had Tor exit node on collocation at local ISP and the collocation was on friend's name (not on some legal entity). Twice they came to his home in early hours with warrant for all computer equipment he has at home. Once because somebody was using Tor for blackmailing, the second time for child pornography. Why they came to his home? I believe the reason is simple: they have IP, they write to ISP something like "Who is your client who had that and that IP at that and that time?" ISP responds: "This is X Y, living there and there and + some other personal information they have on who this person is." Criminal investigators go to the judge and say "We need a warrant for this and this person at this and this location." They get one and they come to visit you in early morning hours. In both cases he just had to explain that: 1) this IP is at collocation and not at that location and 2) that it is a Tor exit node and we do not keep any logs of activity through it. 1) tells makes their warrant invalid and you move from being a suspect (they had in mind that you are using your own home connection to do something illegal, this is the highest probability based on their information) to a witness (you are server admin and it is higher probability that some your user did something illegal). 2) tells them that even if you are a witness, you are worthless witness: you do not have typical users and services, and you are not even logging anything. For most services you are not really required to log anything. Running Tor is not illegal. Having logs for it also not required. They left without taking anything and he hasn't heard from them afterwards (this was few years ago). It might be because both cases were international (Interpol) so for local investigators it was the easiest to just write: it was Tor exit nodes, no logs possible to obtain, case closed. And move on with their lives. If it would be some local thing with a very motivated investigator they might not believe him and would still confiscate equipment. But from a point when they discover that their warrant is probably wrong they are on thin ice as obviously IP was physically somewhere else. It might be that in this case of a guy from Austria he didn't know that it raid is for Tor node but he thought that it might be for something else and just later on discovered that. Or that they simply didn't listen to or believe him. Probably it depends on how you communicate with investigators and your language skills. Mitar From jeroen at unfix.org Tue Dec 4 15:16:56 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 04 Dec 2012 10:16:56 -0500 Subject: securelogin.arubanetworks.com AAAA ::1 <--- someone from Aruba who can fix that? Message-ID: <50BE13E8.7000906@unfix.org> Hi folks, For quite a few folks here on the list travel is a common thing, going into foreign wireless networks is too. Likely your laptop/tablet comes with IPv6 enabled per default, it is 2012 after all almost going 2013. And then you get to a silly hotspot and it does not work as the connection fails (or you get the website you host on your laptop and go 'huh?' ;). Thus you check and you see: 8<------------------------------------------------------------------------ $ dig securelogin.arubanetworks.com aaaa ; <<>> DiG 9.8.3-P1 <<>> securelogin.arubanetworks.com aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25608 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;securelogin.arubanetworks.com. IN AAAA ;; ANSWER SECTION: securelogin.arubanetworks.com. 5 IN AAAA ::1 ;; Query time: 19 msec ;; SERVER: 66.28.0.45#53(66.28.0.45) ;; WHEN: Tue Dec 4 10:12:33 2012 ;; MSG SIZE rcvd: 75 ------------------------------------------------------------------------>8 I am fairly sure somebody technical and high enough up at Aruba knows how to get this resolved, sooner or later... thus please do, it will start hurting more and more people every day. Oh, and btw, it has an A record too, but even though Happy Eyeballs exists in a magical form inside OSX, ::1 is a very close route thus will always win over the IPv4 address. Of course, temp disabling IPv6 on the link is a way to circumvent it, but heck, why is that DNS server publishing ::1 at all!? Greets, Jeroen From jordan at viviotech.net Mon Dec 3 19:44:51 2012 From: jordan at viviotech.net (Jordan Michaels) Date: Mon, 03 Dec 2012 11:44:51 -0800 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <20121203113102.GA24383@gsp.org> References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> Message-ID: <50BD0133.6090509@viviotech.net> On 12/03/2012 03:31 AM, Rich Kulawiec wrote: > On Mon, Dec 03, 2012 at 08:49:24AM +0000, Warren Bailey wrote: >> Can you imagine an email thread that lasted longer than an entire weekend? > > Yes, I can. I've participated in some that went on for months. It's simply > a matter of effectiveness and attention span. > >> This email needs to be murdered, because it is completely out of control. > > I disagree, strongly, as this is an issue of unfortunate timely > relevance to the community. +1 I strongly disagree as well. I am very interested to see how this case evolves in and out of court. Are Tor exit-node operators going to be given the same rights as ISP's who's networks are used for illegal purposes? I would hope so, but it doesn't seem like that has happened in this case, so I am very interested to hear how the situation pans out. It is extremely relevant to the Internet community and to free speech in general. Kind regards, Jordan Michaels Vivio Technologies From Eric.Sabo at calu.edu Tue Dec 4 16:11:55 2012 From: Eric.Sabo at calu.edu (Sabo, Eric) Date: Tue, 4 Dec 2012 16:11:55 +0000 Subject: GMAIL Contact Message-ID: <66D9E8F23BC4F04699A6156D3C9255687C0813@MLEXMBX2.CALU.LCL> To all: Does anyone know of a email or phone contact to get Gmail to get my domain off their RBL list? Thanks, Eric Sabo From nick at pelagiris.org Tue Dec 4 16:51:40 2012 From: nick at pelagiris.org (Nick B) Date: Tue, 4 Dec 2012 11:51:40 -0500 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <50BD0133.6090509@viviotech.net> References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> Message-ID: I seriously doubt many TOR exit nodes have the political clout to be considered a common carrier. In a related note, I wonder if the six-strike rule would violate the ISP's safe harbor, as it's clearly content inspection. Nick On Mon, Dec 3, 2012 at 2:44 PM, Jordan Michaels wrote: > On 12/03/2012 03:31 AM, Rich Kulawiec wrote: > >> On Mon, Dec 03, 2012 at 08:49:24AM +0000, Warren Bailey wrote: >> >>> Can you imagine an email thread that lasted longer than an entire >>> weekend? >>> >> >> Yes, I can. I've participated in some that went on for months. It's >> simply >> a matter of effectiveness and attention span. >> >> This email needs to be murdered, because it is completely out of control. >>> >> >> I disagree, strongly, as this is an issue of unfortunate timely >> relevance to the community. >> > > +1 I strongly disagree as well. I am very interested to see how this case > evolves in and out of court. Are Tor exit-node operators going to be given > the same rights as ISP's who's networks are used for illegal purposes? I > would hope so, but it doesn't seem like that has happened in this case, so > I am very interested to hear how the situation pans out. > > It is extremely relevant to the Internet community and to free speech in > general. > > Kind regards, > Jordan Michaels > Vivio Technologies > > From pelzi at pelzi.net Tue Dec 4 17:00:11 2012 From: pelzi at pelzi.net (Jussi Peltola) Date: Tue, 4 Dec 2012 19:00:11 +0200 Subject: securelogin.arubanetworks.com AAAA ::1 <--- someone from Aruba who can fix that? In-Reply-To: <50BE13E8.7000906@unfix.org> References: <50BE13E8.7000906@unfix.org> Message-ID: <20121204170011.GM23446@pokute.pelzi.net> This whole DNS hack is broken, browsers will cache the record and you end up with breakage when using different captive portals in succession. The hostname used should at least be different for each setup. Other aruba dns hacks, like rapconsole.arubanetworks.com, are even more painful; it is rather annoying when you know the address of a device, try to access it and it keeps redirecting you to a faked DNS name that does not work. From jeroen at unfix.org Tue Dec 4 17:04:01 2012 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 04 Dec 2012 12:04:01 -0500 Subject: Six Strike Rule (Was: William was raided...) In-Reply-To: References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> Message-ID: <50BE2D01.5030100@unfix.org> On 2012-12-04 11:51, Nick B wrote: > In a related note, I wonder if the six-strike rule would violate the ISP's > safe harbor, as it's clearly content inspection. As performed in France, what happens is that some copyright owner contacts the ISP that IP address a.b.c.d had accessed/served copyright infringing data at date/time dd-mm-yyyy HH:mm providing some kind of detail on how they figured that out. That report is a 'strike' and gets forwarded to the user. If that then happens 6 times they are blocked. The ISP as such does not do any content inspection. It is though assumed that some ISPs simply count bytes and that they do some investigation themselves when you reach a certain bandwidth threshold (it seems to correlate that copyright infringers are downloading a lot more than normal webbrowsing users...) Greets, Jeroen From jason at thebaughers.com Tue Dec 4 17:10:40 2012 From: jason at thebaughers.com (Jason Baugher) Date: Tue, 4 Dec 2012 11:10:40 -0600 Subject: Six Strike Rule (Was: William was raided...) In-Reply-To: <50BE2D01.5030100@unfix.org> References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <50BE2D01.5030100@unfix.org> Message-ID: We don't do content inspection. We don't really want to know what our customers are doing, and even if we did, there's not enough time in the day to spend paying attention. When we get complaints from the various copyright agencies, we warn the customer to stop. When we hit a certain number of complaints, its bye-bye customer. On Tue, Dec 4, 2012 at 11:04 AM, Jeroen Massar wrote: > On 2012-12-04 11:51, Nick B wrote: > > In a related note, I wonder if the six-strike rule would violate the > ISP's > > safe harbor, as it's clearly content inspection. > > As performed in France, what happens is that some copyright owner > contacts the ISP that IP address a.b.c.d had accessed/served copyright > infringing data at date/time dd-mm-yyyy HH:mm providing some kind of > detail on how they figured that out. > > That report is a 'strike' and gets forwarded to the user. > > If that then happens 6 times they are blocked. > > The ISP as such does not do any content inspection. > > It is though assumed that some ISPs simply count bytes and that they do > some investigation themselves when you reach a certain bandwidth > threshold (it seems to correlate that copyright infringers are > downloading a lot more than normal webbrowsing users...) > > Greets, > Jeroen > > > From SNaslund at medline.com Tue Dec 4 17:11:37 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 4 Dec 2012 11:11:37 -0600 Subject: [tor-talk] William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50B97774.4030401@gmail.com> References: <2A76E400AC84B845AAC35AA19F8E7A5D0D712152@MUNEXBE1.medline.com> <8200F04ED2C5EF40B246388AD4B822A512D5C5F7@BL2PRD0512MB662.namprd05.prod.outlook.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D712204@MUNEXBE1.medline.com> <50B97774.4030401@gmail.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D798472@MUNEXBE1.medline.com> Already dealt with that at an airport once. One look at my picture and his cleared that right up and they put a note in the entry system that says I am not this guy. High tech huh. Sometimes the system works. By the way we have different middle initials and different SSNs. I have an original DDN TAC Access card, installed BBN nodes for the US Air Force, and worked for quite a few ISPs, and now work for large global corporation. Sorry I did not meet you at NSF net, I worked more on the DoD side of things. Steven Naslund -----Original Message----- From: William Allen Simpson [mailto:william.allen.simpson at gmail.com] Sent: Friday, November 30, 2012 9:20 PM To: nanog at nanog.org Subject: Re: [tor-talk] William was raided for running a Tor exit node. Please help if you can. On 11/30/12 5:15 PM, Naslund, Steve wrote: > Well, in that case.... I am really worried that the cops might charge > me with a crime. They took my computers and are looking at them. I > did not do anything wrong but just in case they decide to charge me > with a crime, please send me some money. > As well you could be, because you appear to have the same name as a registered sex offender: http://www.sexoffenderin.com/reg110698/steven_w_naslundmugshot.htm On 11/29/12 6:39 PM, Naslund, Steve wrote: # As a long time service provider ... # # my many years of experience in engineering ARPANET, MILNET, and the # Internet I would have to guess that most Tor servers are used for no # good much more than they are protecting anyone's privacy. I'm surprised that medline.com is offering network access as an ISP? Admittedly, you began posting to NANOG in 2002 as: Network Engineering Manager Hosting.com - Chicago While I was involved in engineering NSFnet and the Internet and was an "original" member of NANOG, but I don't remember you. Of course, I'm notoriously bad with names. OTOH, I have met, remember, and greatly respect the Tor engineers. From jfmezei_nanog at vaxination.ca Tue Dec 4 17:31:53 2012 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 04 Dec 2012 12:31:53 -0500 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <50BD0133.6090509@viviotech.net> References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> Message-ID: <50BE3389.1040406@vaxination.ca> On 12-12-03 14:44, Jordan Michaels wrote: > case evolves in and out of court. Are Tor exit-node operators going to > be given the same rights as ISP's who's networks are used for illegal > purposes? Perhaps if "Tor exit node" were called "Tor exit Router", politicians/policemen would have a better understanding that this service provides no indexing of data, no storage of data and is just a networking service that is agnostic to whatever data flows through it. If they declare illegal any part of the internet which makes police investigations hard due to lack of traceability/logs then they can go after any NAT router, Tor exit nodes, VPN servers etc. From bjohnson at drtel.com Tue Dec 4 17:32:01 2012 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 4 Dec 2012 17:32:01 +0000 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <50BD0133.6090509@viviotech.net> References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> Message-ID: I know I'm going to get flamed and excoriated, but here goes.... > case evolves in and out of court. Are Tor exit-node operators going to > be given the same rights as ISP's who's networks are used for illegal > purposes? I would hope so, but it doesn't seem like that has happened in > this case, so I am very interested to hear how the situation pans out. This is a misleading statement. ISP's (Common carriers) do not provide a knowingly illegal offering, AND they do provide the PHYSICAL infrastructure for packets to be passed and interconnected to other PHYSICAL networks. TOR exit/entrance nodes provide only the former. The lack of providing a physical infrastructure is crucial. Also, most ISP's (US specifically) are required by Law (under subpoena) to provide details to law enforcement. I really hate this idea of privacy on the Internet. If you really think you have the "right" to use the public infrastructure (to whatever extent you want to label the Internet as such) and be completely anonymous, I have a bridge to sell you. Network operators may treat your packets to whatever level of scrutiny that they may find necessary to determine if they want to pass your packets, keeping in mind that good operators want the Internet to work. I'm waiting for the next hot "application" to use a widely known "bad" port and see what happens. :) > > It is extremely relevant to the Internet community and to free speech in > general. I'm actually in agreement that law enforcement may have overstepped here if the only reason was the TOR exit point, but having a TOR exit point to me, seems to be condoning the actions/statements/packets used through the exit point. You are knowingly hiding information that your local government may require you to disclose. Short answer... don't use TOR. It's not a bad thing, but it's not a good thing either. - Brian From joly at punkcast.com Tue Dec 4 19:13:23 2012 From: joly at punkcast.com (Joly MacFie) Date: Tue, 4 Dec 2012 14:13:23 -0500 Subject: Six Strike Rule (Was: William was raided...) In-Reply-To: References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <50BE2D01.5030100@unfix.org> Message-ID: ISOC-NY ran a half day conflab on 6 strikes (which incidentally - and for reasons that escape me - is a name the Copyright Alert System perpetrators wish would not be used) last November 15. A full archive is available at http://isoc-ny.org/p2/4527 On Tue, Dec 4, 2012 at 12:10 PM, Jason Baugher wrote: > We don't do content inspection. We don't really want to know what our > customers are doing, and even if we did, there's not enough time in the day > to spend paying attention. When we get complaints from the various > copyright agencies, we warn the customer to stop. When we hit a certain > number of complaints, its bye-bye customer. > > > On Tue, Dec 4, 2012 at 11:04 AM, Jeroen Massar wrote: > > > On 2012-12-04 11:51, Nick B wrote: > > > In a related note, I wonder if the six-strike rule would violate the > > ISP's > > > safe harbor, as it's clearly content inspection. > > > > As performed in France, what happens is that some copyright owner > > contacts the ISP that IP address a.b.c.d had accessed/served copyright > > infringing data at date/time dd-mm-yyyy HH:mm providing some kind of > > detail on how they figured that out. > > > > That report is a 'strike' and gets forwarded to the user. > > > > If that then happens 6 times they are blocked. > > > > The ISP as such does not do any content inspection. > > > > It is though assumed that some ISPs simply count bytes and that they do > > some investigation themselves when you reach a certain bandwidth > > threshold (it seems to correlate that copyright infringers are > > downloading a lot more than normal webbrowsing users...) > > > > Greets, > > Jeroen > > > > > > > -- --------------------------------------------------------------- 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 Valdis.Kletnieks at vt.edu Tue Dec 4 19:35:48 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 04 Dec 2012 14:35:48 -0500 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: Your message of "Tue, 04 Dec 2012 17:32:01 +0000." References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> Message-ID: <19238.1354649748@turing-police.cc.vt.edu> On Tue, 04 Dec 2012 17:32:01 +0000, Brian Johnson said: > This is a misleading statement. ISP's (Common carriers) do not provide a knowingly > illegal offering, ... TOR exit/entrance nodes provide only the former. This is also a misleading statement. Explain the difference between a consumer ISP selling you a cable Internet plan knowing that NN% of the traffic will be data with questionable copyright status, and 1 of of 5 or so will be a botted box doing other illegal stuff, and a TOR node providing transit knowing that NN% will be similarly questionable etc etc etc. In other words, if TOR exit nodes provide a "knowingly illegal offering", then Comcast is doing exactly the same thing... (Also, feel free to cite actual statute or case law that says TOR is by *definition* or finding of fact, a "knowingly illegal offering" in and of itself - distinct from what uses the user thereof may do with it. Absent that, it's not a "knowingly illegal offering" the same way that some sites have ended up in court for contributory copyright infringement.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jgreco at ns.sol.net Tue Dec 4 19:57:38 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 4 Dec 2012 13:57:38 -0600 (CST) Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <19238.1354649748@turing-police.cc.vt.edu> Message-ID: <201212041957.qB4JvcYi099017@aurora.sol.net> > > This is a misleading statement. ISP's (Common carriers) do not provide a knowingly I'm trying to remember when ISP's became common carriers... > > illegal offering, ... TOR exit/entrance nodes provide only the former. > > This is also a misleading statement. Explain the difference between > a consumer ISP selling you a cable Internet plan knowing that NN% of > the traffic will be data with questionable copyright status, and > 1 of of 5 or so will be a botted box doing other illegal stuff, > and a TOR node providing transit knowing that NN% will be similarly > questionable etc etc etc. Great point. The question might also revolve around this issue, restored from the previous msg: > > AND they do provide the PHYSICAL infrastructure for > > packets to be passed and interconnected to other PHYSICAL networks. Well, an ISP does do that, but so does an end user's network. So if I put a Tor node on an ethernet ("PHYSICAL infrastructure") and then connect that to an ISP ("other PHYSICAL networks"), that doesn't make for a real good way to differentiate between an ISP, a commercial ISP customer who gets routed IP networks via BGP, or an end user who has an ethernet behind a NAT gateway. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From owen at delong.com Tue Dec 4 20:22:57 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 4 Dec 2012 12:22:57 -0800 Subject: Six Strike Rule (Was: William was raided...) In-Reply-To: References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <50BE2D01.5030100@unfix.org> Message-ID: Marketing... They don't want to risk it getting caught in the current backlash against 3-strikes laws. Owen On Dec 4, 2012, at 11:13 , Joly MacFie wrote: > ISOC-NY ran a half day conflab on 6 strikes (which incidentally - and for > reasons that escape me - is a name the Copyright Alert System perpetrators > wish would not be used) last November 15. > > A full archive is available at http://isoc-ny.org/p2/4527 > > > On Tue, Dec 4, 2012 at 12:10 PM, Jason Baugher wrote: > >> We don't do content inspection. We don't really want to know what our >> customers are doing, and even if we did, there's not enough time in the day >> to spend paying attention. When we get complaints from the various >> copyright agencies, we warn the customer to stop. When we hit a certain >> number of complaints, its bye-bye customer. >> >> >> On Tue, Dec 4, 2012 at 11:04 AM, Jeroen Massar wrote: >> >>> On 2012-12-04 11:51, Nick B wrote: >>>> In a related note, I wonder if the six-strike rule would violate the >>> ISP's >>>> safe harbor, as it's clearly content inspection. >>> >>> As performed in France, what happens is that some copyright owner >>> contacts the ISP that IP address a.b.c.d had accessed/served copyright >>> infringing data at date/time dd-mm-yyyy HH:mm providing some kind of >>> detail on how they figured that out. >>> >>> That report is a 'strike' and gets forwarded to the user. >>> >>> If that then happens 6 times they are blocked. >>> >>> The ISP as such does not do any content inspection. >>> >>> It is though assumed that some ISPs simply count bytes and that they do >>> some investigation themselves when you reach a certain bandwidth >>> threshold (it seems to correlate that copyright infringers are >>> downloading a lot more than normal webbrowsing users...) >>> >>> Greets, >>> Jeroen >>> >>> >>> >> > > > > -- > --------------------------------------------------------------- > 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 owen at delong.com Tue Dec 4 20:22:15 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 4 Dec 2012 12:22:15 -0800 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> Message-ID: On Dec 4, 2012, at 09:32 , Brian Johnson wrote: > I know I'm going to get flamed and excoriated, but here goes.... > > >> case evolves in and out of court. Are Tor exit-node operators going to >> be given the same rights as ISP's who's networks are used for illegal >> purposes? I would hope so, but it doesn't seem like that has happened in >> this case, so I am very interested to hear how the situation pans out. > > This is a misleading statement. ISP's (Common carriers) do not provide a knowingly illegal offering, AND they do provide the PHYSICAL infrastructure for packets to be passed and interconnected to other PHYSICAL networks. TOR exit/entrance nodes provide only the former. The lack of providing a physical infrastructure is crucial. Also, most ISP's (US specifically) are required by Law (under subpoena) to provide details to law enforcement. > I strongly disagree with you. TOR exit nodes provide a vital physical infrastructure to free speech advocates who live in jurisdictions where strong forces are aligned against free speech. I'm sure most TOR exit node operators would happily provide all the details they have if presented with an appropriate subpoena. > I really hate this idea of privacy on the Internet. If you really think you have the "right" to use the public infrastructure (to whatever extent you want to label the Internet as such) and be completely anonymous, I have a bridge to sell you. Network operators may treat your packets to whatever level of scrutiny that they may find necessary to determine if they want to pass your packets, keeping in mind that good operators want the Internet to work. > I really cherish this idea of privacy on the internet. It's a strong tool for enabling democracy and freedom of speech. First, the internet hasn't been "public infrastructure" for a very long time. It's a loose collection of privately owned networks with very few pieces still owned by government institutions. I don't think anyone has asserted a "right" to use that infrastructure, but, I certainly value that there are people who choose to provide it. I think society benefits from having such infrastructure available. I like free speech. I like that there are people making free speech possible in places where it is strongly discouraged. While I think it is a shame that child pornographers and other nefarious users are able to abuse this infrastructure to the detriment of society, the reality is that it is like any other tool. It has beneficial uses and harmful uses. Going after the tool is counterproductive and harmful. > I'm waiting for the next hot "application" to use a widely known "bad" port and see what happens. :) What's a "bad" port? 80? 443? 25? 587? Most of the malware these days uses one or more of those. > >> >> It is extremely relevant to the Internet community and to free speech in >> general. > > I'm actually in agreement that law enforcement may have overstepped here if the only reason was the TOR exit point, but having a TOR exit point to me, seems to be condoning the actions/statements/packets used through the exit point. You are knowingly hiding information that your local government may require you to disclose. Having a TOR exit point is making an effort to provide a service. It doesn't condone the nefarious uses of the service any more than running an ISP condones running a warez site that happens to get transit services from said ISP. Running a TOR exit node isn't hiding any information. It's simply not collecting the information in the first place. You can't hide information you never had. > > Short answer... don't use TOR. It's not a bad thing, but it's not a good thing either. I strongly disagree. TOR is a tool. It's a very good thing in its ability to enable democratization of communications and freedom of speech. It also has some nefarious uses. Guess what... So do hammers. I don't see anyone calling for a ban on the sale of hammers or encouraging carpenters to stop using them. Owen From talmi at marvell.com Tue Dec 4 21:05:51 2012 From: talmi at marvell.com (Tal Mizrahi) Date: Tue, 4 Dec 2012 23:05:51 +0200 Subject: Network Latency Measurements Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F9031B9C@IL-MB01.marvell.com> Hi, We are looking for publicly available statistics of network latency measurements taken in large networks. For example, there is FCC's measurements (http://www.fcc.gov/measuring-broadband-america/2012/july). However, we are looking for something more detailed that can show a large number of latency measurements taken periodically (preferably with as small a period as possible). Any help will be appreciated. Thanks, Tal Mizrahi. From bjohnson at drtel.com Tue Dec 4 21:25:59 2012 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 4 Dec 2012 21:25:59 +0000 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <19238.1354649748@turing-police.cc.vt.edu> References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <19238.1354649748@turing-police.cc.vt.edu> Message-ID: > > > This is a misleading statement. ISP's (Common carriers) do not provide a > knowingly > > illegal offering, ... TOR exit/entrance nodes provide only the former. > > This is also a misleading statement. Explain the difference between > a consumer ISP selling you a cable Internet plan knowing that NN% of > the traffic will be data with questionable copyright status, and > 1 of of 5 or so will be a botted box doing other illegal stuff, > and a TOR node providing transit knowing that NN% will be similarly > questionable etc etc etc. You actually are saying what I said, just you misunderstand your own point. You clipped my entire statement to make it appear to say something else. A TOR node, in and of itself, is not infrastructure for passing packets. It's a service on the infrastructure. I never implied that the traffic through/from the ISP or the TOR was more or less legal than the other. > > In other words, if TOR exit nodes provide a "knowingly illegal offering", > then Comcast is doing exactly the same thing... No they are not. See previous. - Brian From bjohnson at drtel.com Tue Dec 4 21:36:19 2012 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 4 Dec 2012 21:36:19 +0000 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> Message-ID: > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, December 04, 2012 2:22 PM > To: Brian Johnson > Cc: Jordan Michaels; nanog at nanog.org > Subject: Re: William was raided for running a Tor exit node. Please help if > > > On Dec 4, 2012, at 09:32 , Brian Johnson wrote: > > > I know I'm going to get flamed and excoriated, but here goes.... > > > > > >> case evolves in and out of court. Are Tor exit-node operators going to > >> be given the same rights as ISP's who's networks are used for illegal > >> purposes? I would hope so, but it doesn't seem like that has happened in > >> this case, so I am very interested to hear how the situation pans out. > > > > This is a misleading statement. ISP's (Common carriers) do not provide a > knowingly illegal offering, AND they do provide the PHYSICAL infrastructure > for packets to be passed and interconnected to other PHYSICAL networks. > TOR exit/entrance nodes provide only the former. The lack of providing a > physical infrastructure is crucial. Also, most ISP's (US specifically) are required > by Law (under subpoena) to provide details to law enforcement. > > > > I strongly disagree with you. > > TOR exit nodes provide a vital physical infrastructure to free speech > advocates who live in jurisdictions where strong forces are aligned against > free speech. I'm sure most TOR exit node operators would happily provide all > the details they have if presented with an appropriate subpoena. > TOR is not vital. It is political. I view this not as an issue of morals or political action. It is an issue of a technical nature. A TOR is a way to hide who you are. If I am hiding who you are from someone else and there is a law broken, who do you go after? > > I really hate this idea of privacy on the Internet. If you really think you have > the "right" to use the public infrastructure (to whatever extent you want to > label the Internet as such) and be completely anonymous, I have a bridge to > sell you. Network operators may treat your packets to whatever level of > scrutiny that they may find necessary to determine if they want to pass your > packets, keeping in mind that good operators want the Internet to work. > > > > I really cherish this idea of privacy on the internet. It's a strong tool for > enabling democracy and freedom of speech. > > First, the internet hasn't been "public infrastructure" for a very long time. It's > a loose collection of privately owned networks with very few pieces still > owned by government institutions. I don't think anyone has asserted a > "right" to use that infrastructure, but, I certainly value that there are people > who choose to provide it. I think society benefits from having such > infrastructure available. > > I like free speech. I like that there are people making free speech possible in > places where it is strongly discouraged. While I think it is a shame that child > pornographers and other nefarious users are able to abuse this > infrastructure to the detriment of society, the reality is that it is like any other > tool. It has beneficial uses and harmful uses. Going after the tool is > counterproductive and harmful. This is ridiculous. Owen you damn well know that if you send packets from a source, that source can be tracked back. Add a subpoena, privacy hereby destroyed. Other countries are generally less protective of the citizen than the US and as such... what was your argument again. Oh yeah. I'll be hiding behind my packets. ;P > > > I'm waiting for the next hot "application" to use a widely known "bad" port > and see what happens. :) > > What's a "bad" port? 80? 443? 25? 587? Most of the malware these days uses > one or more of those. > Point given. I got off topic here. > > > >> > >> It is extremely relevant to the Internet community and to free speech in > >> general. > > > > I'm actually in agreement that law enforcement may have overstepped > here if the only reason was the TOR exit point, but having a TOR exit point to > me, seems to be condoning the actions/statements/packets used through > the exit point. You are knowingly hiding information that your local > government may require you to disclose. > > Having a TOR exit point is making an effort to provide a service. It doesn't > condone the nefarious uses of the service any more than running an ISP > condones running a warez site that happens to get transit services from said > ISP. > > Running a TOR exit node isn't hiding any information. It's simply not collecting > the information in the first place. You can't hide information you never had. > And supplying the Sudafed to the kiddies to use for runny noses is not condoning use for crystal meth. > > > > Short answer... don't use TOR. It's not a bad thing, but it's not a good thing > either. > > I strongly disagree. TOR is a tool. It's a very good thing in its ability to enable > democratization of communications and freedom of speech. It also has some > nefarious uses. Guess what... So do hammers. I don't see anyone calling for a > ban on the sale of hammers or encouraging carpenters to stop using them. > Once again, this is a political reason not a technical reason. I'm sorry for your political situation. - Brian From bjohnson at drtel.com Tue Dec 4 21:41:01 2012 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 4 Dec 2012 21:41:01 +0000 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <201212041957.qB4JvcYi099017@aurora.sol.net> References: <19238.1354649748@turing-police.cc.vt.edu> <201212041957.qB4JvcYi099017@aurora.sol.net> Message-ID: - Brian J. > -----Original Message----- > From: Joe Greco [mailto:jgreco at ns.sol.net] > Sent: Tuesday, December 04, 2012 1:58 PM > To: Valdis.Kletnieks at vt.edu > Cc: Brian Johnson; nanog at nanog.org > Subject: Re: William was raided for running a Tor exit node. Please help if > > > > This is a misleading statement. ISP's (Common carriers) do not provide a > knowingly > > I'm trying to remember when ISP's became common carriers... Not all ISPs are. I was referring to those of us who are both Common Carriers and ISPs. The Common Carrier status will override. > > > > illegal offering, ... TOR exit/entrance nodes provide only the former. > > > > This is also a misleading statement. Explain the difference between > > a consumer ISP selling you a cable Internet plan knowing that NN% of > > the traffic will be data with questionable copyright status, and > > 1 of of 5 or so will be a botted box doing other illegal stuff, > > and a TOR node providing transit knowing that NN% will be similarly > > questionable etc etc etc. > > Great point. > > The question might also revolve around this issue, restored from the > previous msg: > > > > AND they do provide the PHYSICAL infrastructure for > > > packets to be passed and interconnected to other PHYSICAL networks. > > Well, an ISP does do that, but so does an end user's network. So if > I put a Tor node on an ethernet ("PHYSICAL infrastructure") and then > connect that to an ISP ("other PHYSICAL networks"), that doesn't make > for a real good way to differentiate between an ISP, a commercial ISP > customer who gets routed IP networks via BGP, or an end user who has > an ethernet behind a NAT gateway. > I was speaking of TOR as a service. The service is not provided inherent of the infrastructure to pass packets. It's more similar to a tunneling protocol service. The person hosting the endpoint on their infrastructure would be the service point and they are the ones acting as protector and as such should take on the responsibility as such. I can feel lawyers rubbing their hands together as I type. - Brian From SNaslund at medline.com Tue Dec 4 21:44:11 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 4 Dec 2012 15:44:11 -0600 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <19238.1354649748@turing-police.cc.vt.edu> References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <19238.1354649748@turing-police.cc.vt.edu> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D7F799A@MUNEXBE1.medline.com> Here is something else to consider : Why will just about any ISP shut down a customer with an open mail relay? It allows anonymous access to anyone trying to send an email, right. So why would this not be considered just as "free speech" as the Tor server. The reason I believe is because we as an industry decided that spam was a "bad thing" before it even became illegal. In the case of Tor, it largely enables anonymous transfer of data (like copyrighted bit torrent traffic) including some content that is blatently illegal to even possess. As a community we have been a lot less decisive about that subject. Before we chastise the legal process being used by the government just consider everything we do as service providers under the guise of "acceptable use" which has just about no basis in the law. Most "acceptable use" violations are basically doing stuff we don't like. As far as the Internet just being a tool, I agree but there are and always have been laws to govern the use of tools whether we are talking about telephones, guns, postal system, or any other tool. Conducting the alleged business over the telephone would be a crime just as sending it through the postal system. If you were encrypting voice calls for the sole purpose of avoiding a legal wiretap I think the law might have a problem with that. If you were to provide that service to someone like a kidnapper or the mafia, I bet you are going to have some tough questions thrown at you. As I see it, here are the possible reasons this individual set up this Tor network : 1. This man is truly the saint of the Internet privacy community and he spent his own hard earned money to set up a bunch of off shore Tor servers for the benefit of mankind. Why he needs exit nodes in the United States and Poland I am not sure about. Is the German government cracking down a lot on dissident traffic coming out of servers in his own country? He must not be able to pay his own legal expenses because he is too busy building servers for the good of humanity. 2. This guy was using Tor for whatever personal reasons. Could be that there were not enough exit nodes to get the kind of performance he wanted. Maybe he was downloading / uploading various content, legal or illegal and was serious enough about it that he set up exit nodes in multiple countries. That might explain the ton of storage he had at his residence. Maybe he has a big recipe collection, pirated movie collection, or unspeakable content the police are looking at now. The content will say if he is innocent or guilty. Maybe he was using it for one thing and others were using it for something else. In that case, my thoughts are if you swim with sharks you might get bit. 3. Maybe this guy was running a Tor network as a paid service for others not wanting to get caught doing whatever they were doing. Could be a lucrative business for an enterprising system admin I suppose. You would not want to set up these servers at your own workplace right, and maybe you have customers in multiple countries. Who might want a covert communications network? Drug cartels, media pirates, intelligence agencies, terrorists, illegal child porn producers, whoever does not want to get caught communicating. Maybe even downtrodden dissidents but they likely don't have a lot of money. He is going to need your money to defend himself because the government will gets suspicious if he shows up with another safe deposit box of cash and his customer certainly can't be contacted to help. I see these possible outcomes : 1. The guy has nothing on his home computers or the Tor server that point to a crime and he gets his stuff back. Inconvenient no doubt but he won't need that legal defense fund. 2. Maybe this guy is as serious about his home gear as his network privacy. Maybe everything at home is deep encrypted. Unlikely it will be secure enough but maybe the government has its suspicions but cannot make the case and they drop it. 2. The guy has tons of illegal content on his home storage stuff and gets nailed for it. That legal defense fund is going to be paying the SPA, RIAA, or whoever else is going to sue him. If it what the police allege then he is going away for quite awhile. 3. The guy is innocent but gets found guilty because "the man" just does not like Tor. Your legal defense fund probably won't help much because if "the man" wants him locked up with no evidence then your defense probably won't help a lot. You will be better off selling "Free Mother Tor-esa" T-shirt to try to get him sprung. I might be a cynic but I am just not thinking it is #1 on these lists. Steven Naslund -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Tuesday, December 04, 2012 1:36 PM To: Brian Johnson Cc: nanog at nanog.org Subject: Re: William was raided for running a Tor exit node. Please help if On Tue, 04 Dec 2012 17:32:01 +0000, Brian Johnson said: > This is a misleading statement. ISP's (Common carriers) do not provide > a knowingly illegal offering, ... TOR exit/entrance nodes provide only the former. This is also a misleading statement. Explain the difference between a consumer ISP selling you a cable Internet plan knowing that NN% of the traffic will be data with questionable copyright status, and 1 of of 5 or so will be a botted box doing other illegal stuff, and a TOR node providing transit knowing that NN% will be similarly questionable etc etc etc. In other words, if TOR exit nodes provide a "knowingly illegal offering", then Comcast is doing exactly the same thing... (Also, feel free to cite actual statute or case law that says TOR is by *definition* or finding of fact, a "knowingly illegal offering" in and of itself - distinct from what uses the user thereof may do with it. Absent that, it's not a "knowingly illegal offering" the same way that some sites have ended up in court for contributory copyright infringement.) From bjohnson at drtel.com Tue Dec 4 21:48:17 2012 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 4 Dec 2012 21:48:17 +0000 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D7F799A@MUNEXBE1.medline.com> References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <19238.1354649748@turing-police.cc.vt.edu> <2A76E400AC84B845AAC35AA19F8E7A5D0D7F799A@MUNEXBE1.medline.com> Message-ID: +1 - Brian J. > -----Original Message----- > From: Naslund, Steve [mailto:SNaslund at medline.com] > Sent: Tuesday, December 04, 2012 3:44 PM > To: nanog at nanog.org > Subject: RE: William was raided for running a Tor exit node. Please help if > > Here is something else to consider : > > Why will just about any ISP shut down a customer with an open mail > relay? It allows anonymous access to anyone trying to send an email, > right. So why would this not be considered just as "free speech" as the > Tor server. The reason I believe is because we as an industry decided > that spam was a "bad thing" before it even became illegal. In the case > of Tor, it largely enables anonymous transfer of data (like copyrighted > bit torrent traffic) including some content that is blatently illegal to > even possess. As a community we have been a lot less decisive about > that subject. > > Before we chastise the legal process being used by the government just > consider everything we do as service providers under the guise of > "acceptable use" which has just about no basis in the law. Most > "acceptable use" violations are basically doing stuff we don't like. > > As far as the Internet just being a tool, I agree but there are and > always have been laws to govern the use of tools whether we are talking > about telephones, guns, postal system, or any other tool. Conducting > the alleged business over the telephone would be a crime just as sending > it through the postal system. If you were encrypting voice calls for > the sole purpose of avoiding a legal wiretap I think the law might have > a problem with that. If you were to provide that service to someone > like a kidnapper or the mafia, I bet you are going to have some tough > questions thrown at you. > > As I see it, here are the possible reasons this individual set up this > Tor network : > > 1. This man is truly the saint of the Internet privacy community and he > spent his own hard earned money to set up a bunch of off shore Tor > servers for the benefit of mankind. Why he needs exit nodes in the > United States and Poland I am not sure about. Is the German government > cracking down a lot on dissident traffic coming out of servers in his > own country? He must not be able to pay his own legal expenses because > he is too busy building servers for the good of humanity. > > 2. This guy was using Tor for whatever personal reasons. Could be that > there were not enough exit nodes to get the kind of performance he > wanted. Maybe he was downloading / uploading various content, legal or > illegal and was serious enough about it that he set up exit nodes in > multiple countries. That might explain the ton of storage he had at his > residence. Maybe he has a big recipe collection, pirated movie > collection, or unspeakable content the police are looking at now. The > content will say if he is innocent or guilty. Maybe he was using it for > one thing and others were using it for something else. In that case, my > thoughts are if you swim with sharks you might get bit. > > 3. Maybe this guy was running a Tor network as a paid service for > others not wanting to get caught doing whatever they were doing. Could > be a lucrative business for an enterprising system admin I suppose. You > would not want to set up these servers at your own workplace right, and > maybe you have customers in multiple countries. Who might want a covert > communications network? Drug cartels, media pirates, intelligence > agencies, terrorists, illegal child porn producers, whoever does not > want to get caught communicating. Maybe even downtrodden dissidents > but > they likely don't have a lot of money. He is going to need your money > to defend himself because the government will gets suspicious if he > shows up with another safe deposit box of cash and his customer > certainly can't be contacted to help. > > > I see these possible outcomes : > > 1. The guy has nothing on his home computers or the Tor server that > point to a crime and he gets his stuff back. Inconvenient no doubt but > he won't need that legal defense fund. > > 2. Maybe this guy is as serious about his home gear as his network > privacy. Maybe everything at home is deep encrypted. Unlikely it will > be secure enough but maybe the government has its suspicions but cannot > make the case and they drop it. > > 2. The guy has tons of illegal content on his home storage stuff and > gets nailed for it. That legal defense fund is going to be paying the > SPA, RIAA, or whoever else is going to sue him. If it what the police > allege then he is going away for quite awhile. > > 3. The guy is innocent but gets found guilty because "the man" just does > not like Tor. Your legal defense fund probably won't help much because > if "the man" wants him locked up with no evidence then your defense > probably won't help a lot. You will be better off selling "Free Mother > Tor-esa" T-shirt to try to get him sprung. > > > I might be a cynic but I am just not thinking it is #1 on these lists. > > Steven Naslund > > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Tuesday, December 04, 2012 1:36 PM > To: Brian Johnson > Cc: nanog at nanog.org > Subject: Re: William was raided for running a Tor exit node. Please help > if > > On Tue, 04 Dec 2012 17:32:01 +0000, Brian Johnson said: > > > This is a misleading statement. ISP's (Common carriers) do not provide > > > a knowingly illegal offering, ... TOR exit/entrance nodes provide > only the former. > > This is also a misleading statement. Explain the difference between a > consumer ISP selling you a cable Internet plan knowing that NN% of the > traffic will be data with questionable copyright status, and > 1 of of 5 or so will be a botted box doing other illegal stuff, and a > TOR node providing transit knowing that NN% will be similarly > questionable etc etc etc. > > In other words, if TOR exit nodes provide a "knowingly illegal > offering", then Comcast is doing exactly the same thing... > > (Also, feel free to cite actual statute or case law that says TOR is by > *definition* or finding of fact, a "knowingly illegal offering" in and > of itself - distinct from what uses the user thereof may do with it. > Absent that, it's not a "knowingly illegal offering" the same way that > some sites have ended up in court for contributory copyright > infringement.) From jfmezei_nanog at vaxination.ca Tue Dec 4 21:57:14 2012 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 04 Dec 2012 16:57:14 -0500 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D7F799A@MUNEXBE1.medline.com> References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <19238.1354649748@turing-police.cc.vt.edu> <2A76E400AC84B845AAC35AA19F8E7A5D0D7F799A@MUNEXBE1.medline.com> Message-ID: <50BE71BA.7060509@vaxination.ca> In countries where the law does not dictate that all carriers maintain extensive logs, this is fairly simple. Whether you are a Tor node or a normal ISP, you do nothig until you get a court ordered warrant, at which point you collect information passing through your network and hand it over to authorities. So the "Tor" service remain anonymous until the police suspect illegal data passing through it, at which point they snoop what passes through and work they way up to find the true origin of the data. In countries where log files must be created and retained by law, this is less simple. Is a Tor node covered by the law ? If so, then it is non compliant of it fails to colect the law mandated logs. If the Tor node is not covered by the law, then law enforcment cannot complain if there are no logs to analyse. From mail at danrl.de Tue Dec 4 22:00:43 2012 From: mail at danrl.de (Dan Luedtke) Date: Tue, 4 Dec 2012 23:00:43 +0100 Subject: Network Latency Measurements In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F9031B9C@IL-MB01.marvell.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9031B9C@IL-MB01.marvell.com> Message-ID: <20121204230043.406c342b@tunafish> Hi Tal, > However, > we are looking for something more detailed that can show a large > number of latency measurements taken periodically (preferably with as > small a period as possible). Have you asked RIPE Atlas for data? I think this is pretty much what you might find useful. Greetings Dan From SNaslund at medline.com Tue Dec 4 22:01:46 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 4 Dec 2012 16:01:46 -0600 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D7F79E5@MUNEXBE1.medline.com> If I am a network guy and I sent up a heavily encrypted VPN for use by worldwide drug cartels, I am pretty sure I am committing a crime. If I have knowledge that what I am doing is going to further the commission of a crime, I am probably committing a crime. The service provider that sold me the connection is not at fault here because they have no way of knowing what I am up to in the normal course of their business. I don't know where anyone got the idea that communications is private from law enforcement with the proper authorizations. Your phone can be traced or tapped under the laws of most countries, the only difference is the level of control. Even though we may all view some groups in China, Syria, Sudan, or wherever as dissidents, their own governments may view them as terrorists and you will probably get in trouble for helping them. I would guess (but don't know) that it is illegal to communicate covertly inside of China. It is probably also some sort of crime to circumvent their firewall protections. I am not making the right vs wrong case here but be advised that what might be philanthropic in one country could very well be a crime in another. A lot of the law (and moral decision making in general ) is about intent. If the guy was trying to help people protect themselves from totalitarian regimes and such then he is probably morally and legally innocent of a crime. If the guy was building a covert network for what the police allege, he is guilty. If he was pirating movies and someone else was using it for child crimes then he is partial responsible in my moral opinion. I am not familiar enough with German law to tell you if he is legally guilty or not. Steven Naslund -----Original Message----- From: Brian Johnson [mailto:bjohnson at drtel.com] Sent: Tuesday, December 04, 2012 11:32 AM To: Jordan Michaels; nanog at nanog.org Subject: RE: William was raided for running a Tor exit node. Please help if I know I'm going to get flamed and excoriated, but here goes.... > case evolves in and out of court. Are Tor exit-node operators going to > be given the same rights as ISP's who's networks are used for illegal > purposes? I would hope so, but it doesn't seem like that has happened > in this case, so I am very interested to hear how the situation pans out. This is a misleading statement. ISP's (Common carriers) do not provide a knowingly illegal offering, AND they do provide the PHYSICAL infrastructure for packets to be passed and interconnected to other PHYSICAL networks. TOR exit/entrance nodes provide only the former. The lack of providing a physical infrastructure is crucial. Also, most ISP's (US specifically) are required by Law (under subpoena) to provide details to law enforcement. I really hate this idea of privacy on the Internet. If you really think you have the "right" to use the public infrastructure (to whatever extent you want to label the Internet as such) and be completely anonymous, I have a bridge to sell you. Network operators may treat your packets to whatever level of scrutiny that they may find necessary to determine if they want to pass your packets, keeping in mind that good operators want the Internet to work. I'm waiting for the next hot "application" to use a widely known "bad" port and see what happens. :) > > It is extremely relevant to the Internet community and to free speech > in general. I'm actually in agreement that law enforcement may have overstepped here if the only reason was the TOR exit point, but having a TOR exit point to me, seems to be condoning the actions/statements/packets used through the exit point. You are knowingly hiding information that your local government may require you to disclose. Short answer... don't use TOR. It's not a bad thing, but it's not a good thing either. - Brian From job at instituut.net Tue Dec 4 22:02:20 2012 From: job at instituut.net (Job Snijders) Date: Tue, 4 Dec 2012 23:02:20 +0100 Subject: Network Latency Measurements In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F9031B9C@IL-MB01.marvell.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9031B9C@IL-MB01.marvell.com> Message-ID: Hi Tal, On Dec 4, 2012, at 10:05 PM, Tal Mizrahi wrote: > We are looking for publicly available statistics of network latency measurements taken in large networks. Maybe http://amp.ring.nlnog.net/ has nice data for you. Contact ring-admins at ring.nlnog.net with your proposal. Kind regards, Job From SNaslund at medline.com Tue Dec 4 22:19:38 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 4 Dec 2012 16:19:38 -0600 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <19238.1354649748@turing-police.cc.vt.edu> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D7F7A1F@MUNEXBE1.medline.com> I think it is a fallacious debate to discuss whether Tor servers or services are illegal or legal. Like any other tool, it is all about intent. I know that as engineering types we tend to not like relativism but the law is very much about that. Intent is ultimately very critical to obtaining a criminal conviction. Every day someone does something that might otherwise be considered a crime but because of intent is innocent. For example, ****I shoot a bear out of season, this is a crime right? What if I told you the bear was attacking a four year old little girl, does that change your mind? ****It is not a crime to send an encoded letter. It is a crime to send an encoded letter that communicates an impending attack on someone. ****It is not a crime to make a phone call. It is a crime to make a telephonic bomb threat. ****A gun is not a crime. Shooting someone is a crime (mostly). ****An ISP selling internet service that most people use for legal purposes is not doing anything illegal when someone uses it to illegally share music because they did not intend to commit a crime. ****If you build a server solely for hosting copyrighted software for illegal distribution, you are a criminal. If someone hacks your FTP server and hides a piece of copyrighted software there for illegal distribution you are probably not a criminal as long as you take some action to prevent the crime once you are aware of it. Steven Naslund -----Original Message----- From: Brian Johnson [mailto:bjohnson at drtel.com] Sent: Tuesday, December 04, 2012 3:26 PM To: Valdis.Kletnieks at vt.edu; nanog at nanog.org Cc: nanog at nanog.org Subject: RE: William was raided for running a Tor exit node. Please help if > > > This is a misleading statement. ISP's (Common carriers) do not > > provide a > knowingly > > illegal offering, ... TOR exit/entrance nodes provide only the former. > > This is also a misleading statement. Explain the difference between a > consumer ISP selling you a cable Internet plan knowing that NN% of the > traffic will be data with questionable copyright status, and > 1 of of 5 or so will be a botted box doing other illegal stuff, and a > TOR node providing transit knowing that NN% will be similarly > questionable etc etc etc. You actually are saying what I said, just you misunderstand your own point. You clipped my entire statement to make it appear to say something else. A TOR node, in and of itself, is not infrastructure for passing packets. It's a service on the infrastructure. I never implied that the traffic through/from the ISP or the TOR was more or less legal than the other. > > In other words, if TOR exit nodes provide a "knowingly illegal > offering", then Comcast is doing exactly the same thing... No they are not. See previous. - Brian From weaselkeeper at gmail.com Tue Dec 4 22:22:25 2012 From: weaselkeeper at gmail.com (Jim Richardson) Date: Tue, 4 Dec 2012 14:22:25 -0800 Subject: Network Latency Measurements In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F9031B9C@IL-MB01.marvell.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9031B9C@IL-MB01.marvell.com> Message-ID: On Tue, Dec 4, 2012 at 1:05 PM, Tal Mizrahi wrote: > Hi, > > We are looking for publicly available statistics of network latency measurements taken in large networks. > For example, there is FCC's measurements (http://www.fcc.gov/measuring-broadband-america/2012/july). > However, we are looking for something more detailed that can show a large number of latency measurements taken periodically (preferably with as small a period as possible). > > Any help will be appreciated. > > Thanks, > Tal Mizrahi. > Would the bufferbloat people be a good place to ask? http://www.bufferbloat.net/ -- http://neon-buddha.net From jgreco at ns.sol.net Tue Dec 4 22:31:33 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 4 Dec 2012 16:31:33 -0600 (CST) Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: Message-ID: <201212042231.qB4MVZZa000820@aurora.sol.net> > > Well, an ISP does do that, but so does an end user's network. So if > > I put a Tor node on an ethernet ("PHYSICAL infrastructure") and then > > connect that to an ISP ("other PHYSICAL networks"), that doesn't make > > for a real good way to differentiate between an ISP, a commercial ISP > > customer who gets routed IP networks via BGP, or an end user who has > > an ethernet behind a NAT gateway. > > I was speaking of TOR as a service. The service is not provided inherent of= > the infrastructure to pass packets. It's more similar to a tunneling proto= > col service. So if we can choose convenient definitions for the sake of discussing the issue, this is a pointless discussion, because you'll use your preferred definitions and I'll use mine, and we'll both be right by that logic. Tunnels and VPN's are a fact of life on the modern internet, though. Those could be considered services. Or they could be considered part of the infrastructure. >From my point of view, they're just a way to attach to the Internet in order to gain specific characteristics (a secure pathway, or IPv6, or whatever). When you look at it like that, Tor looks suspiciously similar to that, in that it's just a way to attach to the Internet in order to gain anonymity - a characteristic. The traffic flows through a Tor node in much the same way as traffic flows through a NAT gateway, being modified a bit in the process. > The person hosting the endpoint on their infrastructure would be the servic= > e point and they are the ones acting as protector and as such should take o= > n the responsibility as such. I can feel lawyers rubbing their hands togeth= > er as I type. You could say the same thing about Internet Service Providers. But ISP's have cried foul at that for years, and even got significant protections embodied in law. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From tvhawaii at shaka.com Tue Dec 4 22:37:13 2012 From: tvhawaii at shaka.com (Michael Painter) Date: Tue, 4 Dec 2012 12:37:13 -1000 Subject: William was raided for running a Tor exit node. Please help if References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> Message-ID: Owen DeLong wrote: > I strongly disagree with you. > > TOR exit nodes provide a vital physical infrastructure to free speech advocates who live in jurisdictions where strong > forces are > aligned against free speech. I'm sure most TOR exit node operators would happily provide all the details they have if > presented > with an appropriate subpoena. > I really cherish this idea of privacy on the internet. It's a strong tool for enabling democracy and freedom of speech. [snip] Isn't William's problem because he used an IP address that was registered to him on the Polish server? If not, what am I missing? SANS has chimed in via their latest Newsbites: --TOR Operator Charged For Content Sent Through His Servers (November 29 & 30, 2012) An Austrian man who operated TOR servers has been charged with distributing child pornography. Authorities detected the images passing through the servers maintained by the man. Police seized 20 computers and other equipment from William Weber's home. TOR is an acronym for The Onion Router, a project developed by the US Naval Research Laboratory that allows people surf the web anonymously. It is often used by political dissidents, journalists, and law enforcement officers, and has also been used by criminals. The offending images were being distributed by a server in Poland and sent through Weber's servers. Weber operated exit servers; traffic from these nodes can be traced back to the servers' IP addresses. While the authorities became "friendlier" after understanding where the images came from, there is a precedent for holding TOR operators liable for content that passes through servers they operate. The Electronic Frontier Foundations acknowledges the risk that accompanies operating exit nodes and advises that "it's best not to run your exit relay in your home or using your home Internet connection." http://arstechnica.com/tech-policy/2012/11/tor-operator-charged-for-child-porn-transmitted-over-his-servers/ http://www.bbc.co.uk/news/technology-20554788 http://www.zdnet.com/austrian-man-raided-for-operating-tor-exit-node-7000008133/ [Editor's Note (Ullrich): IMHO, the TOR operator acted like a transit ISP/NSP in this case. (Hoan): In many countries it is not illegal to run a Tor exit node. However, for anyone considering, or are already, running a Tor exit node you should familiarise yourself with the Electronic Frontier Foundation's Legal FAQ on the topic at https://www.eff.org/torchallenge/legal-faq/] From mark at viviotech.net Tue Dec 4 22:40:30 2012 From: mark at viviotech.net (Mark Keymer) Date: Tue, 04 Dec 2012 14:40:30 -0800 Subject: Amazon Abuse contact Message-ID: <50BE7BDE.9020901@viviotech.net> Hi, If there is a Amazon Abuse person our there or if someone has a good contact to someone at Amazon can you message me off-list. We have put in some Abuse request a couple of days ago and have not heard back. It would be great to talk with someone about an issue effecting one of our clients and the use of Amazon. (Cloud instances I believe) Thank you in advance. Sincerely, -- Mark Keymer CFO/COO Vivio Technologies 509-593-4207 x1002 From SNaslund at medline.com Tue Dec 4 22:44:47 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 4 Dec 2012 16:44:47 -0600 Subject: [tor-talk] William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D798472@MUNEXBE1.medline.com> References: <2A76E400AC84B845AAC35AA19F8E7A5D0D712152@MUNEXBE1.medline.com> <8200F04ED2C5EF40B246388AD4B822A512D5C5F7@BL2PRD0512MB662.namprd05.prod.outlook.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D712204@MUNEXBE1.medline.com> <50B97774.4030401@gmail.com> <2A76E400AC84B845AAC35AA19F8E7A5D0D798472@MUNEXBE1.medline.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D7F7A8B@MUNEXBE1.medline.com> A lot of guys have the same names, I did not assume that you are related to Jessica Simpson or Bart Simpson for that matter. Maybe I did not see you at NSFnet because I was working with DDN which was established a full two years before NSFnet. So what? Does the fact that I worked on the precursor to the Internet and NSFnet make me more credible than you? I was not aware that in order to be credible on NANOG, we had to meet you at some point. They did not tell me that at the Pentagon or when I got my engineering degrees. I also have great respect for the Tor engineers, it was great work. I just don't have respect for the idiots that sometimes use Tor. I also have great respect for the guys who wrote sendmail and don't blame them every time I get spam. What I don't have any respect for is the "I was here first (you weren't)", name dropping (I know the Tor guys), know it all (that does not know that a lot of what people do does not show up in google). For those of you who care about credentials. I have been working on the Internet and its predecessors since 1985. Of course that has absolutely nothing to do with the credibility of what I say because time does not always equal knowledge. As soon as you assume you are smarter than everyone else in the room you can be assured that you are not. Steven Naslund -----Original Message----- From: William Allen Simpson [mailto:william.allen.simpson at gmail.com] Sent: Friday, November 30, 2012 9:20 PM To: nanog at nanog.org Subject: Re: [tor-talk] William was raided for running a Tor exit node. Please help if you can. On 11/30/12 5:15 PM, Naslund, Steve wrote: > Well, in that case.... I am really worried that the cops might charge > me with a crime. They took my computers and are looking at them. I > did not do anything wrong but just in case they decide to charge me > with a crime, please send me some money. > As well you could be, because you appear to have the same name as a registered sex offender: http://www.sexoffenderin.com/reg110698/steven_w_naslundmugshot.htm On 11/29/12 6:39 PM, Naslund, Steve wrote: # As a long time service provider ... # # my many years of experience in engineering ARPANET, MILNET, and the # Internet I would have to guess that most Tor servers are used for no # good much more than they are protecting anyone's privacy. I'm surprised that medline.com is offering network access as an ISP? Admittedly, you began posting to NANOG in 2002 as: Network Engineering Manager Hosting.com - Chicago While I was involved in engineering NSFnet and the Internet and was an "original" member of NANOG, but I don't remember you. Of course, I'm notoriously bad with names. OTOH, I have met, remember, and greatly respect the Tor engineers. From SNaslund at medline.com Tue Dec 4 22:47:08 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 4 Dec 2012 16:47:08 -0600 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D7F7A90@MUNEXBE1.medline.com> As usual one or more of the stories out there is wrong. It also says the man was charged which he apparently was not. Steven Naslund -----Original Message----- From: Michael Painter [mailto:tvhawaii at shaka.com] Sent: Tuesday, December 04, 2012 4:37 PM To: nanog at nanog.org Subject: Re: William was raided for running a Tor exit node. Please help if Owen DeLong wrote: > I strongly disagree with you. > > TOR exit nodes provide a vital physical infrastructure to free speech > advocates who live in jurisdictions where strong forces are aligned > against free speech. I'm sure most TOR exit node operators would > happily provide all the details they have if presented with an > appropriate subpoena. > I really cherish this idea of privacy on the internet. It's a strong tool for enabling democracy and freedom of speech. [snip] Isn't William's problem because he used an IP address that was registered to him on the Polish server? If not, what am I missing? SANS has chimed in via their latest Newsbites: --TOR Operator Charged For Content Sent Through His Servers (November 29 & 30, 2012) An Austrian man who operated TOR servers has been charged with distributing child pornography. Authorities detected the images passing through the servers maintained by the man. Police seized 20 computers and other equipment from William Weber's home. TOR is an acronym for The Onion Router, a project developed by the US Naval Research Laboratory that allows people surf the web anonymously. It is often used by political dissidents, journalists, and law enforcement officers, and has also been used by criminals. The offending images were being distributed by a server in Poland and sent through Weber's servers. Weber operated exit servers; traffic from these nodes can be traced back to the servers' IP addresses. While the authorities became "friendlier" after understanding where the images came from, there is a precedent for holding TOR operators liable for content that passes through servers they operate. The Electronic Frontier Foundations acknowledges the risk that accompanies operating exit nodes and advises that "it's best not to run your exit relay in your home or using your home Internet connection." http://arstechnica.com/tech-policy/2012/11/tor-operator-charged-for-chil d-porn-transmitted-over-his-servers/ http://www.bbc.co.uk/news/technology-20554788 http://www.zdnet.com/austrian-man-raided-for-operating-tor-exit-node-700 0008133/ [Editor's Note (Ullrich): IMHO, the TOR operator acted like a transit ISP/NSP in this case. (Hoan): In many countries it is not illegal to run a Tor exit node. However, for anyone considering, or are already, running a Tor exit node you should familiarise yourself with the Electronic Frontier Foundation's Legal FAQ on the topic at https://www.eff.org/torchallenge/legal-faq/] From djahandarie at gmail.com Tue Dec 4 22:49:37 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Tue, 4 Dec 2012 17:49:37 -0500 Subject: Amazon Abuse contact In-Reply-To: <50BE7BDE.9020901@viviotech.net> References: <50BE7BDE.9020901@viviotech.net> Message-ID: On Tue, Dec 4, 2012 at 5:40 PM, Mark Keymer wrote: > If there is a Amazon Abuse person our there or if someone has a good contact > to someone at Amazon can you message me off-list. > > We have put in some Abuse request a couple of days ago and have not heard > back. It would be great to talk with someone about an issue effecting one of > our clients and the use of Amazon. (Cloud instances I believe) FWIW, I had an issue with a DoS attack from an EC2 machine, and it took a total of 2 weeks for them to take the box offline, despite the attack going on the entire time (and being a really obvious UDP crudflood). I imagine that is their turnaround time. I found no escalation path despite searching for phone numbers and bumping the ticket with more info a few times. -- Darius Jahandarie From owen at delong.com Wed Dec 5 04:07:40 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 4 Dec 2012 20:07:40 -0800 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> Message-ID: On Dec 4, 2012, at 1:36 PM, Brian Johnson wrote: >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Tuesday, December 04, 2012 2:22 PM >> To: Brian Johnson >> Cc: Jordan Michaels; nanog at nanog.org >> Subject: Re: William was raided for running a Tor exit node. Please help if >> >> >> On Dec 4, 2012, at 09:32 , Brian Johnson wrote: >> >>> I know I'm going to get flamed and excoriated, but here goes.... >>> >>> >>>> case evolves in and out of court. Are Tor exit-node operators going to >>>> be given the same rights as ISP's who's networks are used for illegal >>>> purposes? I would hope so, but it doesn't seem like that has happened in >>>> this case, so I am very interested to hear how the situation pans out. >>> >>> This is a misleading statement. ISP's (Common carriers) do not provide a >> knowingly illegal offering, AND they do provide the PHYSICAL infrastructure >> for packets to be passed and interconnected to other PHYSICAL networks. >> TOR exit/entrance nodes provide only the former. The lack of providing a >> physical infrastructure is crucial. Also, most ISP's (US specifically) are required >> by Law (under subpoena) to provide details to law enforcement. >>> >> >> I strongly disagree with you. >> >> TOR exit nodes provide a vital physical infrastructure to free speech >> advocates who live in jurisdictions where strong forces are aligned against >> free speech. I'm sure most TOR exit node operators would happily provide all >> the details they have if presented with an appropriate subpoena. >> > > TOR is not vital. It is political. I view this not as an issue of morals or political action. It is an issue of a technical nature. A TOR is a way to hide who you are. If I am hiding who you are from someone else and there is a law broken, who do you go after? > Merely because something is political does not exclude it from being vital. There are opportunities for free speech which would be diminished or eliminated if TOR were eliminated. As such, yes, it is, in fact a vital political tool. It was a technical issue until people started having their civil rights potentially infringed. At that point, it became political and moral also. If you are hiding who I am from someone else and I am breaking a law, I presume they would come to you asking (or even demanding) what you know about my identity. However, that's not what a TOR exit node does. The TOR exit node operator isn't hiding the identity of the sender. You can't hide what you never knew. >>> I really hate this idea of privacy on the Internet. If you really think you have >> the "right" to use the public infrastructure (to whatever extent you want to >> label the Internet as such) and be completely anonymous, I have a bridge to >> sell you. Network operators may treat your packets to whatever level of >> scrutiny that they may find necessary to determine if they want to pass your >> packets, keeping in mind that good operators want the Internet to work. >>> >> >> I really cherish this idea of privacy on the internet. It's a strong tool for >> enabling democracy and freedom of speech. >> >> First, the internet hasn't been "public infrastructure" for a very long time. It's >> a loose collection of privately owned networks with very few pieces still >> owned by government institutions. I don't think anyone has asserted a >> "right" to use that infrastructure, but, I certainly value that there are people >> who choose to provide it. I think society benefits from having such >> infrastructure available. >> >> I like free speech. I like that there are people making free speech possible in >> places where it is strongly discouraged. While I think it is a shame that child >> pornographers and other nefarious users are able to abuse this >> infrastructure to the detriment of society, the reality is that it is like any other >> tool. It has beneficial uses and harmful uses. Going after the tool is >> counterproductive and harmful. > > This is ridiculous. Owen you damn well know that if you send packets from a source, that source can be tracked back. Add a subpoena, privacy hereby destroyed. Other countries are generally less protective of the citizen than the US and as such... what was your argument again. Oh yeah. I'll be hiding behind my packets. ;P If you send packets from a source, they can be tracked back in some cases. However, if you send your packets to someone nearby, anyone outside of that path probably can't easily track them back. If they then rewrite the packets and forward them to another who repeats that process and this process is repeated a few times, then if the person attempting to do the track-back isn't aware of the packets until the very far end, it can, in fact, be virtually impossible to track them back to the originator. This, combined with some obfuscation of the actual content along the way and a lack of logging is basically how TOR works. Providing an effective cloak of anonymity has repeatedly been shown to allow important political speech to be made public under circumstances when it otherwise would not have been able to. You may not like the other uses of TOR. I certainly don't like some of the uses that TOR has been put to. However, denying that TOR has, in fact, enabled improved freedom of speech in difficult environments ignores substantial evidence to the contrary. > >> >>> I'm waiting for the next hot "application" to use a widely known "bad" port >> and see what happens. :) >> >> What's a "bad" port? 80? 443? 25? 587? Most of the malware these days uses >> one or more of those. >> > > Point given. I got off topic here. > >>> >>>> >>>> It is extremely relevant to the Internet community and to free speech in >>>> general. >>> >>> I'm actually in agreement that law enforcement may have overstepped >> here if the only reason was the TOR exit point, but having a TOR exit point to >> me, seems to be condoning the actions/statements/packets used through >> the exit point. You are knowingly hiding information that your local >> government may require you to disclose. >> >> Having a TOR exit point is making an effort to provide a service. It doesn't >> condone the nefarious uses of the service any more than running an ISP >> condones running a warez site that happens to get transit services from said >> ISP. >> >> Running a TOR exit node isn't hiding any information. It's simply not collecting >> the information in the first place. You can't hide information you never had. >> > > And supplying the Sudafed to the kiddies to use for runny noses is not condoning use for crystal meth. Agreed. I think the current effort I have to go through as an adult to buy a simple OTC medication at a time when I'm already feeling like crap is ridiculous. > >>> >>> Short answer... don't use TOR. It's not a bad thing, but it's not a good thing >> either. >> >> I strongly disagree. TOR is a tool. It's a very good thing in its ability to enable >> democratization of communications and freedom of speech. It also has some >> nefarious uses. Guess what... So do hammers. I don't see anyone calling for a >> ban on the sale of hammers or encouraging carpenters to stop using them. >> > > Once again, this is a political reason not a technical reason. I'm sorry for your political situation. > Yes, this is a political reason. TOR is a technology that is important to solving a political problem. It isn't my personal political situation, but I have tremendous respect and admiration for those courageous enough to make use of it in political situations where it is important. I live in the US. In spite of the extent to which recent government actions have reduced civil liberties and ignore the constitution, they have not quite gotten to the point of eliminating free speech. There's no technological problem with TOR. It works quite well. There's no inherent political problem with TOR. There is a political problem with certain uses of TOR. There is a worse political problem with attempting to eliminate TOR just because there is a political problem with some uses of TOR. Owen From ju at netzwerklabor.at Wed Dec 5 06:05:41 2012 From: ju at netzwerklabor.at (Jutta Zalud) Date: Wed, 5 Dec 2012 07:05:41 +0100 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <19238.1354649748@turing-police.cc.vt.edu> Message-ID: <1639967630.20121205070541@netzwerklabor.at> > A TOR node, in and of itself, is not infrastructure for passing > packets. It's a service on the infrastructure. Technically you are right. But then: what is the difference to ISPs? They offer routing- and DNS- and mail- and other services on various infrastructure. jutta From mysidia at gmail.com Wed Dec 5 08:38:49 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 5 Dec 2012 02:38:49 -0600 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <1639967630.20121205070541@netzwerklabor.at> References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <19238.1354649748@turing-police.cc.vt.edu> <1639967630.20121205070541@netzwerklabor.at> Message-ID: On 12/5/12, Jutta Zalud wrote: > Technically you are right. But then: what is the difference to ISPs? > They offer routing- and DNS- and mail- and other services on > various infrastructure. ISPs typically have a customer. They know their customer, they retain sufficient information to identify their customer, such as name, billing address, physical location, telephone number, and have a signed agreement to provide the service. They collect consideration from their customer; usually in the form of cash. The customer of an ISP is normally expected to adhere to some sort of AUP or TOU, providing terms of their use of the service. Typically including some provisions, such as 'customer is responsible for activities that are performed while dialed into their account', 'no illegal activities', ' no sending spam', conducting other network abuses. For consumer ISPs, sometimes activities such as running internet servers, reselling, or providing ISP access to 3rd parties, might be restricted (restrictions incompatible with running a TOR exit node on that service). An end user operating a TOR exit node, or wide open Wireless AP, intentionally allows other people to connect to their infrastructure and the internet whom they have no relationship with or prior dealings with, in spite of the possibility of network abuse or illegal activities, they choose to allow connectivity without first gathering information required to hold the 3rd party responsible for their activity. An intentional "anonymizer" which is in contrast to what an ISP does. The operator of an ordinary anonymizer service is subject to the possibility of court-ordered intercept upon future use. If the operator of the Tor node believes that criminal intent is the most likely use of the TOR exit node. the degree of intentional ignorance might be considered so severe, that it becomes a situation in which they are considered culpable. E.g. the Tor exit node operator might possibly be considered an accessory, to the activity occuring on their node, that they are harboring / allowing to occur anonymously. Not to say whether Tor node operators are possibly guilty of anything or not. But they are definitely different from ISPs in a number of important ways. Any similarity between Open AP/Tor Exit node operator and ISP are highly superficial. > jutta -- -JH From owen at delong.com Wed Dec 5 09:22:16 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 5 Dec 2012 01:22:16 -0800 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <19238.1354649748@turing-police.cc.vt.edu> <1639967630.20121205070541@netzwerklabor.at> Message-ID: <37FF3A62-505A-4E9B-9664-54398F03EEA9@delong.com> On Dec 5, 2012, at 12:38 AM, Jimmy Hess wrote: > On 12/5/12, Jutta Zalud wrote: >> Technically you are right. But then: what is the difference to ISPs? >> They offer routing- and DNS- and mail- and other services on >> various infrastructure. > > ISPs typically have a customer. They know their customer, they > retain sufficient information to identify their customer, such as > name, billing address, physical location, telephone number, and have > a signed agreement to provide the service. > They collect consideration from their customer; usually in the form of cash. > What if it's a free open wireless ISP where all you have to do is click an assent to a basic TOS agreement? What if it's a free open wireless ISP (such as any Apple store) where all you have to do is get within range and connect? No contract or click-thru at all? > The customer of an ISP is normally expected to adhere to some sort of > AUP or TOU, providing terms of their use of the service. Typically > including some provisions, such as 'customer is responsible for > activities that are performed while dialed into their account', 'no > illegal activities', ' no sending spam', conducting other network > abuses. > In many cases, but not all. However I do have to wonder what makes you think a civil contract would be a deterrent to someone willing to commit a criminal act? > For consumer ISPs, sometimes activities such as running internet > servers, reselling, or providing ISP access to 3rd parties, might > be restricted > (restrictions incompatible with running a TOR exit node on that service). > But such restrictions are not all that common and aren't particularly relevant to this discussion. > An end user operating a TOR exit node, or wide open Wireless AP, > intentionally allows other people to connect to their infrastructure > and the internet whom they have no relationship with or prior > dealings with, in spite of the possibility of network abuse or illegal > activities, they choose to allow connectivity without first > gathering information required to hold the 3rd party responsible for > their activity. I find it amusing that you feel the need to continuously repeat "an end user operating a TOR exit node." Is there some reason that it makes a difference whether the entity operating the TOR exit node or open Wireless AP is an end user or an ISP? Of course, I would argue that operating an open Wireless AP or a TOR node makes you a form of ISP whether you recognize the fact or not. > An intentional "anonymizer" which is in contrast to what an ISP does. > The operator of an ordinary anonymizer service is subject to the > possibility of court-ordered intercept upon future use. So is the operator of a TOR node. The primary difference being that TOR is specifically engineered to make such an intercept virtually useless. So it seems your real criticism here is simply that TOR is a more effective anonymizer. > If the operator of the Tor node believes that criminal intent is the > most likely use of the TOR exit node. the degree of intentional > ignorance might be considered so severe, that it becomes a situation > in which they are considered culpable. This assumes a whole lot of facts not in evidence. If I were to put up a TOR exit node, I would assume that the most likely intent would be free speech which is not illegal in my jurisdiction. I don't consider that I am responsible for the myriad jurisdictions that may exist at the entry and/or transit points prior to reaching said exit node. Do you have any data to support your conclusion that criminal intent is the most likely use of TOR exit nodes? > E.g. the Tor exit node operator might possibly be considered an > accessory, to the activity occuring on their node, that they are > harboring / allowing to occur anonymously. Very hard to prove that intent beyond a reasonable doubt in my opinion. > Not to say whether Tor node operators are possibly guilty of anything or not. > But they are definitely different from ISPs in a number of important ways. You have yet to show one yet. You've shown how they're different from some ISPs, but there are many ISPs operating today which don't fit your model of what constitutes an ISP, so I remain unconvinced. I'm further unconvinced that your proposed distinctions are actually meaningful from a legal perspective. Perhaps the lawyer that chimed in earlier will come back and address this question. > Any similarity between Open AP/Tor Exit node operator and ISP are > highly superficial. I guess this depends almost entirely on what properties it is that you believe define an ISP. Given the number of ISPs that don't have customers, don't collect data on their customers, and operate free open public access networks, I don't think that the properties you suggest above can be used in said definition. As I said, given that Apple Computer operates such networks quite intentionally in all of their stores as well as within range of the Apple campus in Cupertino, I think you'd be hard pressed to claim that these are strictly some small fringe exceptions. To me, an ISP is defined by the fact that they provide packet forwarding service(s) to some group of external parties. By that definition, I cannot make any legitimate claim that any of the following are not ISPs: TOR Exit nodes Tunnel Brokers 6to4 gateways/servers Teredo gateways/servers Access networks Datacenters Universities (in most cases) etc. So? You claim that those similarities are superficial?What are the deeply meaningful differences that apply across the board to all ISPs? Owen From eugen at leitl.org Wed Dec 5 09:34:48 2012 From: eugen at leitl.org (Eugen Leitl) Date: Wed, 5 Dec 2012 10:34:48 +0100 Subject: /. ITU Approves Deep Packet Inspection Message-ID: <20121205093448.GH9750@leitl.org> http://yro.slashdot.org/story/12/12/05/0115214/itu-approves-deep-packet-inspection ITU Approves Deep Packet Inspection Posted by Soulskill on Tuesday December 04, @08:19PM from the inspect-my-encryption-all-you'd-like dept. dsinc sends this quote from Techdirt about the International Telecommunications Union's ongoing conference in Dubai that will have an effect on the internet everywhere: "One of the concerns is that decisions taken there may make the Internet less a medium that can be used to enhance personal freedom than a tool for state surveillance and oppression. The new Y.2770 standard is entitled 'Requirements for deep packet inspection in Next Generation Networks', and seeks to define an international standard for deep packet inspection (DPI). As the Center for Democracy & Technology points out, it is thoroughgoing in its desire to specify technologies that can be used to spy on people. One of the big issues surrounding WCIT and the ITU has been the lack of transparency ? or even understanding what real transparency might be. So it will comes as no surprise that the new DPI standard was negotiated behind closed doors, with no drafts being made available." From jgreco at ns.sol.net Wed Dec 5 13:35:15 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 5 Dec 2012 07:35:15 -0600 (CST) Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: Message-ID: <201212051335.qB5DZGln013060@aurora.sol.net> > An end user operating a TOR exit node, or wide open Wireless AP, > intentionally allows other people to connect to their infrastructure > and the internet whom they have no relationship with or prior > dealings with, in spite of the possibility of network abuse or illegal > activities, they choose to allow connectivity without first > gathering information required to hold the 3rd party responsible for > their activity. Oh please. I don't know where you've been hiding out for the last half a decade or so, but around here, every McDonalds, Starbucks, Sam's Club, Home Depot, Lowe's, and most libraries, hotels, hospitals, and laundromats offer WiFi, and those are just the ones I can readily think of. The level of wishful-thinking implied by the quoted text about how the Internet works is mind-boggling. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From alter3d at alter3d.ca Wed Dec 5 14:08:43 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Wed, 05 Dec 2012 09:08:43 -0500 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <201212051335.qB5DZGln013060@aurora.sol.net> References: <201212051335.qB5DZGln013060@aurora.sol.net> Message-ID: <50BF556B.3030405@alter3d.ca> On 12/5/2012 8:35 AM, Joe Greco wrote: >> An end user operating a TOR exit node, or wide open Wireless AP, >> intentionally allows other people to connect to their infrastructure >> and the internet whom they have no relationship with or prior >> dealings with, in spite of the possibility of network abuse or illegal >> activities, they choose to allow connectivity without first >> gathering information required to hold the 3rd party responsible for >> their activity. > Oh please. I don't know where you've been hiding out for the last half > a decade or so, but around here, every McDonalds, Starbucks, Sam's Club, > Home Depot, Lowe's, and most libraries, hotels, hospitals, and > laundromats offer WiFi, and those are just the ones I can readily > think of. > > The level of wishful-thinking implied by the quoted text about how the > Internet works is mind-boggling. > > ... JG Yes, but THAT free WiFi is offered by responsible businesses. We certainly can't trust lowly citizens with such things. It would be chaos! The sky would fall, the world would end, and puppies would be kicked. No, such power should only be in the hands of those we trust. - Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4431 bytes Desc: S/MIME Cryptographic Signature URL: From Gabriel.McCall at thyssenkrupp.com Wed Dec 5 14:14:25 2012 From: Gabriel.McCall at thyssenkrupp.com (McCall, Gabriel) Date: Wed, 5 Dec 2012 14:14:25 +0000 Subject: Any enterprise operators very happy with their MPLS providers? Message-ID: <12B3AEACEC284C4AA5D4CB88D3D345B501FB175845@ATL01VMB001WP.tkitna.local> I'm getting ready to prepare an RFP for our next generation WAN, and would like feedback from anyone else who has 100+ MPLS nodes on their quality of account service and technical performance. My current landscape includes AT&T, Sprint, and Verizon. I'm almost completely happy with Sprint- they're about in the A- range. AT&T is muddling along at about a C, and Verizon is a solid F. I've heard very good things from some CenturyLink customers and will definitely include them in the bidder list- is anyone else doing a very good job for you? -Gabriel From zeusdadog at gmail.com Wed Dec 5 14:21:43 2012 From: zeusdadog at gmail.com (Jay Nakamura) Date: Wed, 5 Dec 2012 09:21:43 -0500 Subject: Any enterprise operators very happy with their MPLS providers? In-Reply-To: <12B3AEACEC284C4AA5D4CB88D3D345B501FB175845@ATL01VMB001WP.tkitna.local> References: <12B3AEACEC284C4AA5D4CB88D3D345B501FB175845@ATL01VMB001WP.tkitna.local> Message-ID: We have had pretty good result with Century Link (Formerly Qwest) although not on a 100+ node scale.. On Wed, Dec 5, 2012 at 9:14 AM, McCall, Gabriel wrote: > I'm getting ready to prepare an RFP for our next generation WAN, and would like feedback from anyone else who has 100+ MPLS nodes on their quality of account service and technical performance. > > My current landscape includes AT&T, Sprint, and Verizon. I'm almost completely happy with Sprint- they're about in the A- range. AT&T is muddling along at about a C, and Verizon is a solid F. I've heard very good things from some CenturyLink customers and will definitely include them in the bidder list- is anyone else doing a very good job for you? > > -Gabriel > > From aservin at lacnic.net Wed Dec 5 14:35:00 2012 From: aservin at lacnic.net (Arturo Servin) Date: Wed, 05 Dec 2012 12:35:00 -0200 Subject: Network Latency Measurements In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F9031B9C@IL-MB01.marvell.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9031B9C@IL-MB01.marvell.com> Message-ID: <50BF5B94.9060901@lacnic.net> It is in beta and in spanish, though: http://simon.labs.lacnic.net/simon/api http://simon.labs.lacnic.net/simon http://simon.labs.lacnic.net/simon/participate/ If you found it useful we could create an english version. Regards as On 04/12/2012 19:05, Tal Mizrahi wrote: > Hi, > > We are looking for publicly available statistics of network latency measurements taken in large networks. > For example, there is FCC's measurements (http://www.fcc.gov/measuring-broadband-america/2012/july). > However, we are looking for something more detailed that can show a large number of latency measurements taken periodically (preferably with as small a period as possible). > > Any help will be appreciated. > > Thanks, > Tal Mizrahi. > From jg at freedesktop.org Wed Dec 5 15:16:41 2012 From: jg at freedesktop.org (Jim Gettys) Date: Wed, 5 Dec 2012 10:16:41 -0500 Subject: Network Latency Measurements In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F9031B9C@IL-MB01.marvell.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9031B9C@IL-MB01.marvell.com> Message-ID: On Tue, Dec 4, 2012 at 4:05 PM, Tal Mizrahi wrote: > Hi, > > We are looking for publicly available statistics of network latency > measurements taken in large networks. > For example, there is FCC's measurements ( > http://www.fcc.gov/measuring-broadband-america/2012/july > > ). > However, we are looking for something more detailed that can show a large > number of latency measurements taken periodically (preferably with as small > a period as possible). > > Here are the datasets I'm aware of: ICSI Netalyzr The FCC measurements MLabs http://www.measurementlab.net/ None of them, to my knowledge, take latency measurements "periodically". I watched a nice demo at a talk about Mlabs a couple weeks ago of the ability to query their data set and plot the results. They happened to plot a million or so latency samples (and they have when those samples were taken). Just don't throw out the "can't possibly happen" outliers; bufferbloat is bad enough (if you look at the Netalyzr scatterplots you can find here http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/ you'll see why...). Unfortunately, latencies measured in *seconds* are not only possible, but not uncommon (e.g. my brother's DSL service has > 3 seconds of buffering in each direction under load). - Jim From straterra at fuhell.com Wed Dec 5 15:32:09 2012 From: straterra at fuhell.com (Thomas York) Date: Wed, 5 Dec 2012 10:32:09 -0500 Subject: China Telecom VPN problems (again) Message-ID: <0c2201cdd2fd$b1b06a20$15113e60$@fuhell.com> It looks like I'm having China Telecom issues yet again. They're batting down our SSL VPN tunnels. Switching ports doesn't help. Tunneling the SSL tunnel inside of another tunnel doesn't help. At this point I'm tired of listening to the screaming by the business users. Can someone contact me (here or off-list, I don't care) about circuits in China so that we don't have to use China Telecom? We'd only need 2-10 Mbit and Ethernet hand off. We don't need BGP or MPLS or anything remotely fancy. Our main concern is getting connectivity to the business district in Suzhou, but it'd be nice if we could also use the same carrier in Shenzhen. Thanks! -- Thomas York -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7062 bytes Desc: not available URL: From ops.lists at gmail.com Wed Dec 5 15:38:21 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 5 Dec 2012 21:08:21 +0530 Subject: China Telecom VPN problems (again) In-Reply-To: <0c2201cdd2fd$b1b06a20$15113e60$@fuhell.com> References: <0c2201cdd2fd$b1b06a20$15113e60$@fuhell.com> Message-ID: It's called the great firewall of china. Feel free to shift vendors but it won't help. Meanwhile make sure none of your users are surfing for falun gong, dalai lama, ai weiwei or whoever else the chicom censors don't like on that particular day On Wednesday, December 5, 2012, Thomas York wrote: > It looks like I'm having China Telecom issues yet again. They're batting > down our SSL VPN tunnels. Switching ports doesn't help. Tunneling the SSL > tunnel inside of another tunnel doesn't help. At this point I'm tired of > listening to the screaming by the business users. Can someone contact me > (here or off-list, I don't care) about circuits in China so that we don't > have to use China Telecom? We'd only need 2-10 Mbit and Ethernet hand off. > We don't need BGP or MPLS or anything remotely fancy. Our main concern is > getting connectivity to the business district in Suzhou, but it'd be nice > if > we could also use the same carrier in Shenzhen. > > > > Thanks! > > > > -- Thomas York > > > > > > -- --srs (iPad) From wbailey at satelliteintelligencegroup.com Wed Dec 5 15:50:41 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 5 Dec 2012 15:50:41 +0000 Subject: China Telecom VPN problems (again) In-Reply-To: Message-ID: <8200F04ED2C5EF40B246388AD4B822A512D5DF04@BL2PRD0512MB662.namprd05.prod.outlook.com> We tried to get our VPN work from the China Telecom/China Unicom beijing POP for over a year. The Chinese always claimed it was kosher, but we had something like 60%+ loss across our 4 hop VPN for the entirety of the project. Private circuits don't really exist on the mainland, HK and (maybe) Shanghai are about the only places for decent connectivity. :/ On 12/5/12 7:38 AM, "Suresh Ramasubramanian" wrote: >It's called the great firewall of china. Feel free to shift vendors but it >won't help. > >Meanwhile make sure none of your users are surfing for falun gong, >dalai lama, ai weiwei or whoever else the chicom censors don't like on >that >particular day > >On Wednesday, December 5, 2012, Thomas York wrote: > >> It looks like I'm having China Telecom issues yet again. They're batting >> down our SSL VPN tunnels. Switching ports doesn't help. Tunneling the >>SSL >> tunnel inside of another tunnel doesn't help. At this point I'm tired of >> listening to the screaming by the business users. Can someone contact me >> (here or off-list, I don't care) about circuits in China so that we >>don't >> have to use China Telecom? We'd only need 2-10 Mbit and Ethernet hand >>off. >> We don't need BGP or MPLS or anything remotely fancy. Our main concern >>is >> getting connectivity to the business district in Suzhou, but it'd be >>nice >> if >> we could also use the same carrier in Shenzhen. >> >> >> >> Thanks! >> >> >> >> -- Thomas York >> >> >> >> >> >> > >-- >--srs (iPad) > From rps at maine.edu Wed Dec 5 15:59:35 2012 From: rps at maine.edu (Ray Soucy) Date: Wed, 5 Dec 2012 10:59:35 -0500 Subject: TCP time_wait and port exhaustion for servers Message-ID: RFC 793 arbitrarily defines 2MSL (how long to hold a socket in TIME_WAIT state before cleaning up) as 4 min. Linux is a little more reasonable in this and has it baked into the source as 60 seconds in "/usr/src/linux/include/net/tcp.h": #define TCP_TIMEWAIT_LEN (60*HZ) Where there is no way to change this though /proc (probably a good idea to keep users from messing with it), I am considering re-building a kernel with a lower TCP_TIMEWAIT_LEN to deal with the following issue. With a 60 second timeout on TIME_WAIT, local port identifiers are tied up from being used for new outgoing connections (in this case a proxy server). The default local port range on Linux can easily be adjusted; but even when bumped up to a range of 32K ports, the 60 second timeout means you can only sustain about 500 new connections per second before you run out of ports. There are two options to try an deal with this, tcp_tw_reuse, and tcp_tw_recycle; but both seem to be less than ideal. With tcp_tw_reuse, it doesn't appear to be effective in situations where you're sustaining 500+ new connections per second rather than a small burst. With tcp_tw_recycle it seems like too big of a hammer and has been reported to cause problems with NATed connections. The best solution seems to be trying to keep TIME_WAIT in place, but being faster about it. 30 seconds would get you to 1000 connections a second; 15 to 2000, and 10 seconds to about 3000 a second. A few questions: Does anyone have any data on how typical it is for TIME_WAIT to be necessary beyond 10 seconds on a modern network? Has anyone done some research on how low you can make TIME_WAIT safely? Is this a terrible idea? What alternatives are there? Keep in mind this is a proxy server making outgoing connections as the source of the problem; so things like SO_REUSEADDR which work for reusing sockets for incoming connections don't seem to do much in this situation. Anyone running large proxies or load balancers have this situation? If so what is your solution? -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From amitchell at isipp.com Wed Dec 5 16:26:09 2012 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Wed, 5 Dec 2012 09:26:09 -0700 Subject: Amazon Abuse contact In-Reply-To: References: Message-ID: > > On Tue, Dec 4, 2012 at 5:40 PM, Mark Keymer wrote: >> If there is a Amazon Abuse person our there or if someone has a good contact >> to someone at Amazon can you message me off-list. >> >> We have put in some Abuse request a couple of days ago and have not heard >> back. It would be great to talk with someone about an issue effecting one of >> our clients and the use of Amazon. (Cloud instances I believe) Mark, did you get a contact? If not, please ping me off list and I will connect you with our contact. Anne Anne P. Mitchell, Esq CEO/President Institute for Social Internet Public Policy http://www.ISIPP.com Member, Cal. Bar Cyberspace Law Committee How do you protect your inboxes from spam while reducing false positives? SuretyMail! http://www.SuretyMail.com From jfmezei_nanog at vaxination.ca Wed Dec 5 16:36:19 2012 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 05 Dec 2012 11:36:19 -0500 Subject: William was raided for running a Tor exit node. Please help if In-Reply-To: <37FF3A62-505A-4E9B-9664-54398F03EEA9@delong.com> References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <19238.1354649748@turing-police.cc.vt.edu> <1639967630.20121205070541@netzwerklabor.at> <37FF3A62-505A-4E9B-9664-54398F03EEA9@delong.com> Message-ID: <50BF7803.3050301@vaxination.ca> Does it matter if an anomysing service advertises itself as allowing free speech to users in countries where free speech is censored, compared to a service that advertises itself as catering to the mafias of the world, ensuring their crimes are untraceable ? In the later case, it makes it very easy to think of the sercice operator as an accomplice to crime. But if the primary purpose of a service is legitimate, should the service operator be held liable if there is *some* misuse which cannot be prevented by the service operator ? In my opinion, the operator should remain immune until the police shows up with a warrant and the operator refuses to cooperate. Tor exit nodes are not that different from payphones or disposable pre-paid cellular service where the wireless operator has no verifiable identity/address for the purchasor of the service. Are phone companies held liable because the mafia uses a payphone to plan their crimes knowing that they can't trace calls to an individual ? From jako.andras at eik.bme.hu Wed Dec 5 16:56:06 2012 From: jako.andras at eik.bme.hu (=?ISO-8859-15?Q?J=C1K=D3_Andr=E1s?=) Date: Wed, 5 Dec 2012 17:56:06 +0100 (CET) Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: Message-ID: Ray, > With a 60 second timeout on TIME_WAIT, local port identifiers are tied > up from being used for new outgoing connections (in this case a proxy > server). The default local port range on Linux can easily be > adjusted; but even when bumped up to a range of 32K ports, the 60 > second timeout means you can only sustain about 500 new connections > per second before you run out of ports. Is that 500 new connections per second per {protocol, remote address, remote port} tuple, that's too few for your proxy? (OK, this tuple is more or less equivalent with only {remote address} if we talk about a web proxy.) Just curious. Regards, Andr?s From rps at maine.edu Wed Dec 5 17:09:31 2012 From: rps at maine.edu (Ray Soucy) Date: Wed, 5 Dec 2012 12:09:31 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: Message-ID: This would be outgoing connections sourced from the IP of the proxy, destined to whatever remote website (so 80 or 443) requested by the user. Essentially it's a modified Squid service that is used to filter HTTP for CIPA compliance (required by the government) for keep children in public schools from stumbling on to inappropriate content. Like most web traffic, the majority of these connections open and close in under a second. When we get to a point that there is enough traffic from users behind the proxy to be generating over 500 new outgoing connections per second, sustained, we start having users experience an error where there are no local ports available to Squid to use since they're all tied up in a TIME_WAIT state. Here is an example of netstat totals on a box we're seeing the behavior on: 10 LAST_ACK 32 LISTEN 5 SYN_RECV 5 CLOSE_WAIT 756 ESTABLISHED 26 FIN_WAIT1 40 FIN_WAIT2 5 CLOSING 10 SYN_SENT 481947 TIME_WAIT As a band-aid we've opened up the local port range to allow up to 50K local ports with /proc/sys/net/ipv4/ip_local_port_range, but they're brushing up against that limit again at peak times. It's a shame because memory and CPU-wise the box isn't breaking a sweat. Enabling TW_REUSE doesn't seem to have any effect for this case (/proc/sys/net/ipv4/tcp_tw_reuse) Using TW_RECYCLE drops the TIME_WAIT count to about 10K instead of 50K, but everything I read online says to avoid using TW_RECYCLE because it will break things horribly. Someone responded off-list saying that TIME_WAIT is controlled by /proc/sys/net/ipv4/tcp_fin_timeout, but that is just incorrect information that has been parroted by a lot on blogs. There is no relation between fin_timeout and TCP_TIMEWAIT_LEN. This level of use seems to translate into about 250 Mbps of traffic on average, FWIW. On Wed, Dec 5, 2012 at 11:56 AM, J?K? Andr?s wrote: > Ray, > >> With a 60 second timeout on TIME_WAIT, local port identifiers are tied >> up from being used for new outgoing connections (in this case a proxy >> server). The default local port range on Linux can easily be >> adjusted; but even when bumped up to a range of 32K ports, the 60 >> second timeout means you can only sustain about 500 new connections >> per second before you run out of ports. > > Is that 500 new connections per second per {protocol, remote address, > remote port} tuple, that's too few for your proxy? (OK, this tuple is more > or less equivalent with only {remote address} if we talk about a web > proxy.) Just curious. > > Regards, > Andr?s -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From bzs at world.std.com Wed Dec 5 17:22:02 2012 From: bzs at world.std.com (Barry Shein) Date: Wed, 5 Dec 2012 12:22:02 -0500 Subject: Six Strike Rule (Was: William was raided...) In-Reply-To: References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <50BE2D01.5030100@unfix.org> Message-ID: <20671.33466.67561.33898@world.std.com> On December 4, 2012 at 11:10 jason at thebaughers.com (Jason Baugher) wrote: > We don't do content inspection. We don't really want to know what our > customers are doing, and even if we did, there's not enough time in the day > to spend paying attention. When we get complaints from the various > copyright agencies, we warn the customer to stop. When we hit a certain > number of complaints, its bye-bye customer. This is why there's a need for some sort of reasonable, organized response outlined in writing. In my experience law enforcement (and others) will try to shift whatever investigative tasks are convenient to them to anyone in the loop. Why not, it costs them nothing to have you running around all day and night doing investigative work for them. They will generally cite the seriousness of the underlying crime as (bottomless) justification for your contribution. The rational response is to sit down as a group within some framework and come to some agreement* with them as to what is a reasonable and sufficient response in these cases. Otherwise you're just the complaint desk at Macy's taking all comers and subject to whatever they can dream up to try to get you to solve their problems. * Agreement with LEOs is best, a unilateral document would at least open discussion one would hope and move towards that end. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From joelja at bogus.com Wed Dec 5 17:22:39 2012 From: joelja at bogus.com (joel jaeggli) Date: Wed, 05 Dec 2012 09:22:39 -0800 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: Message-ID: <50BF82DF.7090905@bogus.com> On 12/5/12 9:09 AM, Ray Soucy wrote: > This would be outgoing connections sourced from the IP of the proxy, > destined to whatever remote website (so 80 or 443) requested by the > user. > > Essentially it's a modified Squid service that is used to filter HTTP > for CIPA compliance (required by the government) for keep children in > public schools from stumbling on to inappropriate content. > > Like most web traffic, the majority of these connections open and > close in under a second. When we get to a point that there is enough > traffic from users behind the proxy to be generating over 500 new > outgoing connections per second, sustained, we start having users > experience an error where there are no local ports available to Squid > to use since they're all tied up in a TIME_WAIT state. > > Here is an example of netstat totals on a box we're seeing the behavior on: > > 10 LAST_ACK > 32 LISTEN > 5 SYN_RECV > 5 CLOSE_WAIT > 756 ESTABLISHED > 26 FIN_WAIT1 > 40 FIN_WAIT2 > 5 CLOSING > 10 SYN_SENT > 481947 TIME_WAIT > > As a band-aid we've opened up the local port range to allow up to 50K > local ports with /proc/sys/net/ipv4/ip_local_port_range, but they're > brushing up against that limit again at peak times. We've found it necessary to use address pools to source outgoing connections from our DC devices in order to prevent collisions with ports in timewait. for some particularly high traffic destinations for us. It kinda sucks to burn a /28 or shorter per outbound proxy, but there you have it. > It's a shame because memory and CPU-wise the box isn't breaking a sweat. > > Enabling TW_REUSE doesn't seem to have any effect for this case > (/proc/sys/net/ipv4/tcp_tw_reuse) > Using TW_RECYCLE drops the TIME_WAIT count to about 10K instead of > 50K, but everything I read online says to avoid using TW_RECYCLE > because it will break things horribly. > > Someone responded off-list saying that TIME_WAIT is controlled by > /proc/sys/net/ipv4/tcp_fin_timeout, but that is just incorrect > information that has been parroted by a lot on blogs. There is no > relation between fin_timeout and TCP_TIMEWAIT_LEN. > > This level of use seems to translate into about 250 Mbps of traffic on > average, FWIW. > > > > > On Wed, Dec 5, 2012 at 11:56 AM, J?K? Andr?s wrote: >> Ray, >> >>> With a 60 second timeout on TIME_WAIT, local port identifiers are tied >>> up from being used for new outgoing connections (in this case a proxy >>> server). The default local port range on Linux can easily be >>> adjusted; but even when bumped up to a range of 32K ports, the 60 >>> second timeout means you can only sustain about 500 new connections >>> per second before you run out of ports. >> Is that 500 new connections per second per {protocol, remote address, >> remote port} tuple, that's too few for your proxy? (OK, this tuple is more >> or less equivalent with only {remote address} if we talk about a web >> proxy.) Just curious. >> >> Regards, >> Andr?s > > From harsha at cs.ucr.edu Wed Dec 5 17:25:01 2012 From: harsha at cs.ucr.edu (Harsha V. Madhyastha) Date: Wed, 5 Dec 2012 09:25:01 -0800 Subject: Network Latency Measurements In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F9031B9C@IL-MB01.marvell.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9031B9C@IL-MB01.marvell.com> Message-ID: <9721A6D4-0B88-4B21-844B-98C4E701D5B0@cs.ucr.edu> As part of the iPlane project, we have been gathering traceroutes daily for the last 6.5 years from a couple of hundred PlanetLab sites to over 100K prefixes. Data for the last six months is available at http://iplane.cs.washington.edu/data/iplane_logs/2012/ and all older data is at http://iplane.cs.ucr.edu/iplane_logs/ http://iplane.cs.washington.edu/data/data.html has a description of the dataset. Cheers, Harsha On Dec 4, 2012, at 1:05 PM, Tal Mizrahi wrote: > Hi, > > We are looking for publicly available statistics of network latency measurements taken in large networks. > For example, there is FCC's measurements (http://www.fcc.gov/measuring-broadband-america/2012/july). > However, we are looking for something more detailed that can show a large number of latency measurements taken periodically (preferably with as small a period as possible). > > Any help will be appreciated. > > Thanks, > Tal Mizrahi. > From owen at delong.com Wed Dec 5 17:43:26 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 5 Dec 2012 09:43:26 -0800 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: Message-ID: You could simply add another IP address to the servers's source- address pool, which effectively gives you another 32K (or whatever value you have for the local port range) identifiers. Owen On Dec 5, 2012, at 7:59 AM, Ray Soucy wrote: > RFC 793 arbitrarily defines 2MSL (how long to hold a socket in > TIME_WAIT state before cleaning up) as 4 min. > > Linux is a little more reasonable in this and has it baked into the > source as 60 seconds in "/usr/src/linux/include/net/tcp.h": > #define TCP_TIMEWAIT_LEN (60*HZ) > > Where there is no way to change this though /proc (probably a good > idea to keep users from messing with it), I am considering re-building > a kernel with a lower TCP_TIMEWAIT_LEN to deal with the following > issue. > > With a 60 second timeout on TIME_WAIT, local port identifiers are tied > up from being used for new outgoing connections (in this case a proxy > server). The default local port range on Linux can easily be > adjusted; but even when bumped up to a range of 32K ports, the 60 > second timeout means you can only sustain about 500 new connections > per second before you run out of ports. > > There are two options to try an deal with this, tcp_tw_reuse, and > tcp_tw_recycle; but both seem to be less than ideal. With > tcp_tw_reuse, it doesn't appear to be effective in situations where > you're sustaining 500+ new connections per second rather than a small > burst. With tcp_tw_recycle it seems like too big of a hammer and has > been reported to cause problems with NATed connections. > > The best solution seems to be trying to keep TIME_WAIT in place, but > being faster about it. > > 30 seconds would get you to 1000 connections a second; 15 to 2000, and > 10 seconds to about 3000 a second. > > A few questions: > > Does anyone have any data on how typical it is for TIME_WAIT to be > necessary beyond 10 seconds on a modern network? > Has anyone done some research on how low you can make TIME_WAIT safely? > Is this a terrible idea? What alternatives are there? Keep in mind > this is a proxy server making outgoing connections as the source of > the problem; so things like SO_REUSEADDR which work for reusing > sockets for incoming connections don't seem to do much in this > situation. > > Anyone running large proxies or load balancers have this situation? > If so what is your solution? > > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net From fabricio at nic.br Wed Dec 5 17:33:02 2012 From: fabricio at nic.br (Fabricio Tamusiunas) Date: Wed, 5 Dec 2012 15:33:02 -0200 Subject: Network Latency Measurements Message-ID: <33518789-685B-42BC-A918-4E353A2B9A9D@nic.br> There is a map based on the brazilians measurements. The system used for the measurements is the SIMET (http://simet.nic.br), made by NIC.br. The tests are made by end users and the location of the tests are based on the zip code provided by the users. http://simet.nic.br/mapas/ (only in portuguese - english version in progress) Regards, Fabr?cio. > De: Arturo Servin > Data: 5 de dezembro de 2012 12:35:00 BRST > Para: nanog at nanog.org, talmi at marvell.com > Assunto: Re: Network Latency Measurements > > > It is in beta and in spanish, though: > > http://simon.labs.lacnic.net/simon/api > http://simon.labs.lacnic.net/simon > http://simon.labs.lacnic.net/simon/participate/ > > If you found it useful we could create an english version. > > Regards > as > > On 04/12/2012 19:05, Tal Mizrahi wrote: >> Hi, >> >> We are looking for publicly available statistics of network latency measurements taken in large networks. >> For example, there is FCC's measurements (http://www.fcc.gov/measuring-broadband-america/2012/july). >> However, we are looking for something more detailed that can show a large number of latency measurements taken periodically (preferably with as small a period as possible). >> >> Any help will be appreciated. >> >> Thanks, >> Tal Mizrahi. From mentax at bk.ru Tue Dec 4 22:03:35 2012 From: mentax at bk.ru (=?UTF-8?B?0KHQtdGA0LPQtdC5INCl0LDRgNC70LDQvNC+0LI=?=) Date: Wed, 05 Dec 2012 02:03:35 +0400 Subject: =?UTF-8?B?SG93IHRvIGdldCBESUQgbG9jYWwgbnVtYmVycyAgKElQIFRlbGVwaG9ueSk=?= Message-ID: <1354658615.602855857@f341.mail.ru> Hi there, Can someone explain me how can I get an block of DID (Telephony numbers)? For example I need 200 numbers. Is that special organization or I must buy it somewhere?? What the rule for USA (NY) about telephony providing ? Should I have a licence to sale ip telephony? Thanks.? From otis at ocosa.com Wed Dec 5 18:55:14 2012 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Wed, 5 Dec 2012 12:55:14 -0600 Subject: How to get DID local numbers (IP Telephony) In-Reply-To: <1354658615.602855857@f341.mail.ru> References: <1354658615.602855857@f341.mail.ru> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B017FF6@ocsbs.ocosa.com> You can reach out to any VoIP/telecom Provider that has a white label program or reseller. Some states require you have a license if you are selling voice services period. Here is a link for you concerning NY: http://www.dps.ny.gov/ Read through that site or give them a call to determine if you need a license. HTH Otis -----Original Message----- From: ?????? ???????? [mailto:mentax at bk.ru] Sent: Tuesday, December 04, 2012 4:04 PM To: nanog at nanog.org Subject: How to get DID local numbers (IP Telephony) Hi there, Can someone explain me how can I get an block of DID (Telephony numbers)? For example I need 200 numbers. Is that special organization or I must buy it somewhere? What the rule for USA (NY) about telephony providing ? Should I have a licence to sale ip telephony? Thanks.? From bill at herrin.us Wed Dec 5 18:58:58 2012 From: bill at herrin.us (William Herrin) Date: Wed, 5 Dec 2012 13:58:58 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: Message-ID: On Wed, Dec 5, 2012 at 12:09 PM, Ray Soucy wrote: > Like most web traffic, the majority of these connections open and > close in under a second. When we get to a point that there is enough > traffic from users behind the proxy to be generating over 500 new > outgoing connections per second, sustained, we start having users > experience an error where there are no local ports available to Squid > to use since they're all tied up in a TIME_WAIT state. > > Here is an example of netstat totals on a box we're seeing the behavior on: > > 481947 TIME_WAIT Stupid question but how does 500 x 60 = 481947? To have that many connections in TIME_WAIT on a 60 second timer, you'd need more like 8000 connections per second, wouldn't you? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tom.taylor.stds at gmail.com Wed Dec 5 19:01:41 2012 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Wed, 05 Dec 2012 14:01:41 -0500 Subject: /. ITU Approves Deep Packet Inspection In-Reply-To: <20121205093448.GH9750@leitl.org> References: <20121205093448.GH9750@leitl.org> Message-ID: <50BF9A15.3060406@gmail.com> I'm seriously not clear why Y.2770 is characterized as "negotiated behind closed doors". Any drafts were available to all participants in the ITU-T, on exactly the same terms as drafts of other Recommendations. As an example, the draft coming out of the October, 2011 meeting can be seen at http://www.itu.int/md/T09-SG13-111010-TD-WP4-0201/en. (I have access delegated by a vendor to whom I have been consulting, by virtue of their membership in the ITU-T.) I should mention that the "Next Generation Network" within the context of which this draft was developed is more likely to be implemented by old-line operators than by pure internet operations. Tom Taylor On 05/12/2012 4:34 AM, Eugen Leitl wrote: > > http://yro.slashdot.org/story/12/12/05/0115214/itu-approves-deep-packet-inspection > > ITU Approves Deep Packet Inspection > > Posted by Soulskill on Tuesday December 04, @08:19PM > > from the inspect-my-encryption-all-you'd-like dept. > > dsinc sends this quote from Techdirt about the International > Telecommunications Union's ongoing conference in Dubai that will have an > effect on the internet everywhere: "One of the concerns is that decisions > taken there may make the Internet less a medium that can be used to enhance > personal freedom than a tool for state surveillance and oppression. The new > Y.2770 standard is entitled 'Requirements for deep packet inspection in Next > Generation Networks', and seeks to define an international standard for deep > packet inspection (DPI). As the Center for Democracy & Technology points out, > it is thoroughgoing in its desire to specify technologies that can be used to > spy on people. One of the big issues surrounding WCIT and the ITU has been > the lack of transparency ? or even understanding what real transparency might > be. So it will comes as no surprise that the new DPI standard was negotiated > behind closed doors, with no drafts being made available." > > > From morrowc.lists at gmail.com Wed Dec 5 19:13:09 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Dec 2012 14:13:09 -0500 Subject: /. ITU Approves Deep Packet Inspection In-Reply-To: <50BF9A15.3060406@gmail.com> References: <20121205093448.GH9750@leitl.org> <50BF9A15.3060406@gmail.com> Message-ID: On Wed, Dec 5, 2012 at 2:01 PM, Tom Taylor wrote: > I'm seriously not clear why Y.2770 is characterized as "negotiated behind > closed doors". Any drafts were available to all participants in the ITU-T, > on exactly the same terms as drafts of other Recommendations. As an example, > the draft coming out of the October, 2011 meeting can be seen at > http://www.itu.int/md/T09-SG13-111010-TD-WP4-0201/en. (I have access > delegated by a vendor to whom I have been consulting, by virtue of their > membership in the ITU-T.) > I suspect people mean that trying to download anything off that broken itu website gets you a page with: "If you have a TIES account, please login:" not the document you wish to download... as compared to the other (one other) 'internet standards body' website full of 'draft/proposed/finalized' standards and discussions there-of: which links to the: o open discussion mailing list(s) o open meeting minutes o current drafts and finalized standards o charter and etc... open not 'open*' as the itu site is... > I should mention that the "Next Generation Network" within the context of > which this draft was developed is more likely to be implemented by old-line > operators than by pure internet operations. hurray? > Tom Taylor > > > On 05/12/2012 4:34 AM, Eugen Leitl wrote: >> >> >> >> http://yro.slashdot.org/story/12/12/05/0115214/itu-approves-deep-packet-inspection >> >> ITU Approves Deep Packet Inspection >> >> Posted by Soulskill on Tuesday December 04, @08:19PM >> >> from the inspect-my-encryption-all-you'd-like dept. >> >> dsinc sends this quote from Techdirt about the International >> Telecommunications Union's ongoing conference in Dubai that will have an >> effect on the internet everywhere: "One of the concerns is that decisions >> taken there may make the Internet less a medium that can be used to >> enhance >> personal freedom than a tool for state surveillance and oppression. The >> new >> Y.2770 standard is entitled 'Requirements for deep packet inspection in >> Next >> Generation Networks', and seeks to define an international standard for >> deep >> packet inspection (DPI). As the Center for Democracy & Technology points >> out, >> it is thoroughgoing in its desire to specify technologies that can be used >> to >> spy on people. One of the big issues surrounding WCIT and the ITU has been >> the lack of transparency ? or even understanding what real transparency >> might >> be. So it will comes as no surprise that the new DPI standard was >> negotiated >> behind closed doors, with no drafts being made available." >> >> >> > From arturo.servin at gmail.com Wed Dec 5 19:14:07 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 05 Dec 2012 17:14:07 -0200 Subject: /. ITU Approves Deep Packet Inspection In-Reply-To: <50BF9A15.3060406@gmail.com> References: <20121205093448.GH9750@leitl.org> <50BF9A15.3060406@gmail.com> Message-ID: <50BF9CFF.6040502@gmail.com> Perhaps because you are addressing to a bunch of Internet engineers that (we) are used to create standards in open forums where everybody have a say. For the new Internet world "available to all participants in the ITU-T, on exactly the same terms as drafts of other Recommendations" is not longer valid. Regards, as On 05/12/2012 17:01, Tom Taylor wrote: > I'm seriously not clear why Y.2770 is characterized as "negotiated > behind closed doors". Any drafts were available to all participants in > the ITU-T, on exactly the same terms as drafts of other Recommendations. > As an example, the draft coming out of the October, 2011 meeting can be > seen at http://www.itu.int/md/T09-SG13-111010-TD-WP4-0201/en. (I have > access delegated by a vendor to whom I have been consulting, by virtue > of their membership in the ITU-T.) > > I should mention that the "Next Generation Network" within the context > of which this draft was developed is more likely to be implemented by > old-line operators than by pure internet operations. > > Tom Taylor > > On 05/12/2012 4:34 AM, Eugen Leitl wrote: >> >> http://yro.slashdot.org/story/12/12/05/0115214/itu-approves-deep-packet-inspection >> >> >> ITU Approves Deep Packet Inspection >> >> Posted by Soulskill on Tuesday December 04, @08:19PM >> >> from the inspect-my-encryption-all-you'd-like dept. >> >> dsinc sends this quote from Techdirt about the International >> Telecommunications Union's ongoing conference in Dubai that will have an >> effect on the internet everywhere: "One of the concerns is that decisions >> taken there may make the Internet less a medium that can be used to >> enhance >> personal freedom than a tool for state surveillance and oppression. >> The new >> Y.2770 standard is entitled 'Requirements for deep packet inspection >> in Next >> Generation Networks', and seeks to define an international standard >> for deep >> packet inspection (DPI). As the Center for Democracy & Technology >> points out, >> it is thoroughgoing in its desire to specify technologies that can be >> used to >> spy on people. One of the big issues surrounding WCIT and the ITU has >> been >> the lack of transparency ? or even understanding what real >> transparency might >> be. So it will comes as no surprise that the new DPI standard was >> negotiated >> behind closed doors, with no drafts being made available." >> >> >> From tom at cloudflare.com Wed Dec 5 19:19:37 2012 From: tom at cloudflare.com (Tom Paseka) Date: Wed, 5 Dec 2012 11:19:37 -0800 Subject: China Telecom VPN problems (again) In-Reply-To: <8200F04ED2C5EF40B246388AD4B822A512D5DF04@BL2PRD0512MB662.namprd05.prod.outlook.com> References: <8200F04ED2C5EF40B246388AD4B822A512D5DF04@BL2PRD0512MB662.namprd05.prod.outlook.com> Message-ID: Its quite easy to get MPLS-VPN connectivity into China (Pacnet, Singtel, CPCNet, etc, will offer), but at a price. Suzhou and Shenzhen are easily in reach of all the above listed providers. On Wed, Dec 5, 2012 at 7:50 AM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > We tried to get our VPN work from the China Telecom/China Unicom beijing > POP for over a year. The Chinese always claimed it was kosher, but we had > something like 60%+ loss across our 4 hop VPN for the entirety of the > project. Private circuits don't really exist on the mainland, HK and > (maybe) Shanghai are about the only places for decent connectivity. :/ > > On 12/5/12 7:38 AM, "Suresh Ramasubramanian" wrote: > > >It's called the great firewall of china. Feel free to shift vendors but it > >won't help. > > > >Meanwhile make sure none of your users are surfing for falun gong, > >dalai lama, ai weiwei or whoever else the chicom censors don't like on > >that > >particular day > > > >On Wednesday, December 5, 2012, Thomas York wrote: > > > >> It looks like I'm having China Telecom issues yet again. They're batting > >> down our SSL VPN tunnels. Switching ports doesn't help. Tunneling the > >>SSL > >> tunnel inside of another tunnel doesn't help. At this point I'm tired of > >> listening to the screaming by the business users. Can someone contact me > >> (here or off-list, I don't care) about circuits in China so that we > >>don't > >> have to use China Telecom? We'd only need 2-10 Mbit and Ethernet hand > >>off. > >> We don't need BGP or MPLS or anything remotely fancy. Our main concern > >>is > >> getting connectivity to the business district in Suzhou, but it'd be > >>nice > >> if > >> we could also use the same carrier in Shenzhen. > >> > >> > >> > >> Thanks! > >> > >> > >> > >> -- Thomas York > >> > >> > >> > >> > >> > >> > > > >-- > >--srs (iPad) > > > > > > From morrowc.lists at gmail.com Wed Dec 5 19:25:15 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 Dec 2012 14:25:15 -0500 Subject: China Telecom VPN problems (again) In-Reply-To: References: <8200F04ED2C5EF40B246388AD4B822A512D5DF04@BL2PRD0512MB662.namprd05.prod.outlook.com> Message-ID: On Wed, Dec 5, 2012 at 2:19 PM, Tom Paseka wrote: > Its quite easy to get MPLS-VPN connectivity into China (Pacnet, Singtel, > CPCNet, etc, will offer), but at a price. mpls != ipsec ... perhaps the OP wants some privacy and authentication and such? > > Suzhou and Shenzhen are easily in reach of all the above listed providers. > > On Wed, Dec 5, 2012 at 7:50 AM, Warren Bailey < > wbailey at satelliteintelligencegroup.com> wrote: > >> We tried to get our VPN work from the China Telecom/China Unicom beijing >> POP for over a year. The Chinese always claimed it was kosher, but we had >> something like 60%+ loss across our 4 hop VPN for the entirety of the >> project. Private circuits don't really exist on the mainland, HK and >> (maybe) Shanghai are about the only places for decent connectivity. :/ >> >> On 12/5/12 7:38 AM, "Suresh Ramasubramanian" wrote: >> >> >It's called the great firewall of china. Feel free to shift vendors but it >> >won't help. >> > >> >Meanwhile make sure none of your users are surfing for falun gong, >> >dalai lama, ai weiwei or whoever else the chicom censors don't like on >> >that >> >particular day >> > >> >On Wednesday, December 5, 2012, Thomas York wrote: >> > >> >> It looks like I'm having China Telecom issues yet again. They're batting >> >> down our SSL VPN tunnels. Switching ports doesn't help. Tunneling the >> >>SSL >> >> tunnel inside of another tunnel doesn't help. At this point I'm tired of >> >> listening to the screaming by the business users. Can someone contact me >> >> (here or off-list, I don't care) about circuits in China so that we >> >>don't >> >> have to use China Telecom? We'd only need 2-10 Mbit and Ethernet hand >> >>off. >> >> We don't need BGP or MPLS or anything remotely fancy. Our main concern >> >>is >> >> getting connectivity to the business district in Suzhou, but it'd be >> >>nice >> >> if >> >> we could also use the same carrier in Shenzhen. >> >> >> >> >> >> >> >> Thanks! >> >> >> >> >> >> >> >> -- Thomas York >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >-- >> >--srs (iPad) >> > >> >> >> >> From tom at cloudflare.com Wed Dec 5 19:27:00 2012 From: tom at cloudflare.com (Tom Paseka) Date: Wed, 5 Dec 2012 11:27:00 -0800 Subject: China Telecom VPN problems (again) In-Reply-To: References: <8200F04ED2C5EF40B246388AD4B822A512D5DF04@BL2PRD0512MB662.namprd05.prod.outlook.com> Message-ID: On Wed, Dec 5, 2012 at 11:25 AM, Christopher Morrow wrote: > On Wed, Dec 5, 2012 at 2:19 PM, Tom Paseka wrote: > > Its quite easy to get MPLS-VPN connectivity into China (Pacnet, Singtel, > > CPCNet, etc, will offer), but at a price. > > mpls != ipsec ... perhaps the OP wants some privacy and authentication and > such? run IPSEC over the MPLS-VPN. It'll be a lot more stable than over public internet. From owen at delong.com Wed Dec 5 19:31:14 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 5 Dec 2012 11:31:14 -0800 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: Message-ID: <4C6C8603-CC6B-4734-BE1E-5B0134B6697B@delong.com> On Dec 5, 2012, at 10:58 AM, William Herrin wrote: > On Wed, Dec 5, 2012 at 12:09 PM, Ray Soucy wrote: >> Like most web traffic, the majority of these connections open and >> close in under a second. When we get to a point that there is enough >> traffic from users behind the proxy to be generating over 500 new >> outgoing connections per second, sustained, we start having users >> experience an error where there are no local ports available to Squid >> to use since they're all tied up in a TIME_WAIT state. >> >> Here is an example of netstat totals on a box we're seeing the behavior on: >> >> 481947 TIME_WAIT > > Stupid question but how does 500 x 60 = 481947? To have that many > connections in TIME_WAIT on a 60 second timer, you'd need more like > 8000 connections per second, wouldn't you? Isn't TIME_WAIT based on disconnections, not connections? Sure, assuming all connections are for equal durations, then the disconnection rate would be roughly equal to the connection rate, and, of course over the long term they will eventually trend towards equality, but that doesn't mean that the peak of connections in TIME_WAIT will not be greater than the incoming connection rate would suggest. Owen From owen at delong.com Wed Dec 5 19:39:50 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 5 Dec 2012 11:39:50 -0800 Subject: /. ITU Approves Deep Packet Inspection In-Reply-To: <50BF9A15.3060406@gmail.com> References: <20121205093448.GH9750@leitl.org> <50BF9A15.3060406@gmail.com> Message-ID: On Dec 5, 2012, at 11:01 AM, Tom Taylor wrote: > I'm seriously not clear why Y.2770 is characterized as "negotiated behind closed doors". Any drafts were available to all participants in the ITU-T, on exactly the same terms as drafts of other Recommendations. As an example, the draft coming out of the October, 2011 meeting can be seen at http://www.itu.int/md/T09-SG13-111010-TD-WP4-0201/en. (I have access delegated by a vendor to whom I have been consulting, by virtue of their membership in the ITU-T.) Correct? All ITU Drafts and Recommendations are developed behind closed doors. (If something is developed in a process which is not open to non-members, then, it is by definition developed behind closed doors. Why is this difficult to understand?) > > I should mention that the "Next Generation Network" within the context of which this draft was developed is more likely to be implemented by old-line operators than by pure internet operations. > You say that as if we're supposed to think it is a good thing. To many of us, it is one of the many reasons we're not so thrilled by ITUs sudden interest in exercising greater authority over internet operations. Owen From sam at wwcandt.com Wed Dec 5 20:06:24 2012 From: sam at wwcandt.com (sam at wwcandt.com) Date: Wed, 5 Dec 2012 15:06:24 -0500 (EST) Subject: How to get DID local numbers (IP Telephony) In-Reply-To: <1354658615.602855857@f341.mail.ru> References: <1354658615.602855857@f341.mail.ru> Message-ID: <49328.128.190.125.2.1354737984.squirrel@www.systemetrixs.com> I'm not sure about the license that you may need IANAL but you can get DIDs from a number of resellers I use http://www.voxbeam.com/, Level3 http://www.level3.com, and vitelity http://www.vitelity.com Hope that helps. Sam Moats > > > > > > > Hi there, > > Can someone explain me how can I get an block of DID (Telephony numbers)? > For example I need 200 numbers. Is that special organization or I must buy > it somewhere??? > What the rule for USA (NY) about telephony providing ? Should I have a > licence to sale ip telephony? > > Thanks.?? > > > > > > > From wbailey at satelliteintelligencegroup.com Wed Dec 5 19:48:31 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 5 Dec 2012 19:48:31 +0000 Subject: China Telecom VPN problems (again) In-Reply-To: References: <8200F04ED2C5EF40B246388AD4B822A512D5DF04@BL2PRD0512MB662.namprd05.prod.outlook.com> , Message-ID: Since when is heavy encryption cool in China? Export restrictions smoke all of the decent crypto options. Secondly, anything that is going to happen mpls wise is going to go through MIIT.. You would be shocked how long licenses could take. I was the senior engineer on a project that involved in-flight connectivity via satellite, 2 years later and there are still no licenses. When I asked the Chinese officials (senior party officials) about an unrestricted pipe past the great firewall I was laughed out of the room.. The Chinese exert total control of outbound data on the mainland. Even when you get the OK to turn up, they still want a hard feed into their DPI, in our case knowing the sites (foreign flagged aircraft) transiting the network were only in their AIRSPACE. China is a cool place, but you need to take your patience and checkbook if you want to have any hope in getting what you want. >From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Tom Paseka Date: 12/05/2012 11:27 AM (GMT-08:00) To: Christopher Morrow Cc: Warren Bailey ,nanog at nanog.org Subject: Re: China Telecom VPN problems (again) On Wed, Dec 5, 2012 at 11:25 AM, Christopher Morrow > wrote: On Wed, Dec 5, 2012 at 2:19 PM, Tom Paseka > wrote: > Its quite easy to get MPLS-VPN connectivity into China (Pacnet, Singtel, > CPCNet, etc, will offer), but at a price. mpls != ipsec ... perhaps the OP wants some privacy and authentication and such? run IPSEC over the MPLS-VPN. It'll be a lot more stable than over public internet. From rps at maine.edu Wed Dec 5 19:55:40 2012 From: rps at maine.edu (Ray Soucy) Date: Wed, 5 Dec 2012 14:55:40 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: Message-ID: For each second that goes by you remove X addresses from the available pool of ports for new connections for whatever the TCP_TIMEWAIT_LEN is set to (60 seconds by default in Linux). In this case it's making quick connections for HTTP requests (most of which finish in less than a second). Say you have a pool of 30,000 ports and 500 new connections per second (typical): 1 second goes by you now have 29500 10 seconds go by you now have 25000 30 seconds go by you now have 15000 at 59 seconds you get to 29500, at 60 you get back 500 and stay at 29500 and that keeps rolling at 29500. Everyone is happy. Now say that you're seeing an average of 550 connections a second. Suddenly there aren't any available ports to use. So, your first option is to bump up the range of allowed local ports; easy enough, but even if you open it up as much as you can and go from 1025 to 65535, that's still only 64000 ports; with your 60 second TCP_TIMEWAIT_LEN, you can sustain an average of 1000 connections a second. Our problem is that our busy sites are easily peaking to that 1000 connection a second average, and when we enable TCP_TW_RECYCLE, we see them go past that to 1500 or so connections per second sustained. Unfortinately, TCP_TW_RECYCLE is a little too blunt of a hammer and breaks TCP. >From what I've read and heard from others, in a high connection environment the key is really to drop down the TCP_TIMEWAIT_LEN. My question is basically, "how low can you go?" There seems to be consensus around 20 seconds being safe, 15 being a 99% OK, and 10 or less being problematic. So if I rebuild the kernel to use a 20 second timeout, then that 30000 port pool can sustain 1500, and a 60000 port pool can sustain 3000 connections per second. The software could be re-written to round-robin though IP addresses for outgoing requests, but trying to avoid that. On Wed, Dec 5, 2012 at 1:58 PM, William Herrin wrote: > On Wed, Dec 5, 2012 at 12:09 PM, Ray Soucy wrote: >> Like most web traffic, the majority of these connections open and >> close in under a second. When we get to a point that there is enough >> traffic from users behind the proxy to be generating over 500 new >> outgoing connections per second, sustained, we start having users >> experience an error where there are no local ports available to Squid >> to use since they're all tied up in a TIME_WAIT state. >> >> Here is an example of netstat totals on a box we're seeing the behavior on: >> >> 481947 TIME_WAIT > > Stupid question but how does 500 x 60 = 481947? To have that many > connections in TIME_WAIT on a 60 second timer, you'd need more like > 8000 connections per second, wouldn't you? > > Regards, > Bill Herrin > > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From j at 2600hz.com Wed Dec 5 19:51:08 2012 From: j at 2600hz.com (Joshua Goldbard) Date: Wed, 5 Dec 2012 19:51:08 +0000 Subject: How to get DID local numbers (IP Telephony) In-Reply-To: <49328.128.190.125.2.1354737984.squirrel@www.systemetrixs.com> References: <1354658615.602855857@f341.mail.ru> <49328.128.190.125.2.1354737984.squirrel@www.systemetrixs.com> Message-ID: Hey, We use a number of different carriers. Have had very good experience with Bandwidth.com. If you're doing anything with numbering APIs they have a good one. Most CLEC's or ILEC's will sell you DID blocks but you need to do something with them (attach to PRI or allocate via SIP). I assume you know this already, but the bind is that a lot of carriers won't sell you blocks of DIDs without other associated products. Hope that helps. Cheers, Joshua Community Manager for http://www.2600hz.com On Dec 5, 2012, at 12:06 PM, wrote: > I'm not sure about the license that you may need IANAL but you can get > DIDs from a number of resellers I use http://www.voxbeam.com/, Level3 > http://www.level3.com, and vitelity http://www.vitelity.com > > Hope that helps. > > Sam Moats > >> >> >> >> >> >> >> Hi there, >> >> Can someone explain me how can I get an block of DID (Telephony numbers)? >> For example I need 200 numbers. Is that special organization or I must buy >> it somewhere?? >> What the rule for USA (NY) about telephony providing ? Should I have a >> licence to sale ip telephony? >> >> Thanks.? >> >> >> >> >> >> >> > > From rps at maine.edu Wed Dec 5 20:00:44 2012 From: rps at maine.edu (Ray Soucy) Date: Wed, 5 Dec 2012 15:00:44 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: Message-ID: There is an extra 7 on that number, it was 48194 (was sitting on a different PC so I typed it instead of copy-paste). On Wed, Dec 5, 2012 at 1:58 PM, William Herrin wrote: > On Wed, Dec 5, 2012 at 12:09 PM, Ray Soucy wrote: >> Like most web traffic, the majority of these connections open and >> close in under a second. When we get to a point that there is enough >> traffic from users behind the proxy to be generating over 500 new >> outgoing connections per second, sustained, we start having users >> experience an error where there are no local ports available to Squid >> to use since they're all tied up in a TIME_WAIT state. >> >> Here is an example of netstat totals on a box we're seeing the behavior on: >> >> 481947 TIME_WAIT > > Stupid question but how does 500 x 60 = 481947? To have that many > connections in TIME_WAIT on a 60 second timer, you'd need more like > 8000 connections per second, wouldn't you? > > Regards, > Bill Herrin > > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From Valdis.Kletnieks at vt.edu Wed Dec 5 20:11:02 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 05 Dec 2012 15:11:02 -0500 Subject: China Telecom VPN problems (again) In-Reply-To: Your message of "Wed, 05 Dec 2012 19:48:31 +0000." References: <8200F04ED2C5EF40B246388AD4B822A512D5DF04@BL2PRD0512MB662.namprd05.prod.outlook.com> , Message-ID: <34501.1354738262@turing-police.cc.vt.edu> On Wed, 05 Dec 2012 19:48:31 +0000, Warren Bailey said: > Since when is heavy encryption cool in China? Export restrictions smoke all > of the decent crypto options. OK, I'll bite.. What crypto options are getting stuck due to export restrictions (as opposed to import restrictions on the other end)? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From bill at herrin.us Wed Dec 5 20:56:30 2012 From: bill at herrin.us (William Herrin) Date: Wed, 5 Dec 2012 15:56:30 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: Message-ID: On Wed, Dec 5, 2012 at 2:55 PM, Ray Soucy wrote: > For each second that goes by you remove X addresses from the available > pool of ports for new connections for whatever the TCP_TIMEWAIT_LEN is > set to (60 seconds by default in Linux). > > In this case it's making quick connections for HTTP requests (most of > which finish in less than a second). > > Say you have a pool of 30,000 ports and 500 new connections per second > (typical): > 1 second goes by you now have 29500 > 10 seconds go by you now have 25000 > 30 seconds go by you now have 15000 > at 59 seconds you get to 29500, > at 60 you get back 500 and stay at 29500 and that keeps rolling at > 29500. Everyone is happy. The thing is, Linux doesn't behave quite that way. If you do an anonymous connect(), that is you socket() and then connect() without a bind() in the middle, then the limit applies *per destination IP:port pair*. So, you should be able to do 30,000 connections to 192.168.1.1 port 80, another 30,000 connections to 192.168.1.2 port 80, and so on. You should only fail if you A) bump against the top of NR_OPEN or B) try to do a massive number of TCP connections to the same remote IP address. Try it: set up a listener on discard that just closes the connection and repeat connect() to 127.0.0.5 until you get an error. Then confirm that you're out of ports: telnet 127.0.0.5 9 Trying 127.0.0.5... telnet: Unable to connect to remote host: Cannot assign requested address And confirm that you can still make outbound connections to a different IP address: telnet 127.0.0.4 9 Trying 127.0.0.4... Connected to 127.0.0.4. Escape character is '^]'. Connection closed by foreign host. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jlewis at lewis.org Wed Dec 5 21:11:32 2012 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 5 Dec 2012 16:11:32 -0500 (EST) Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: Message-ID: On Wed, 5 Dec 2012, Ray Soucy wrote: > So if I rebuild the kernel to use a 20 second timeout, then that 30000 > port pool can sustain 1500, and a 60000 port pool can sustain 3000 > connections per second. > > The software could be re-written to round-robin though IP addresses > for outgoing requests, but trying to avoid that. It's kind of a hack, but you don't have to rewrite the software to get different source IPs for different connections. On linux, you could do the following: *) Keep your normal default route *) Configure extra IPs as aliases (eth0:0, eth0:1,...) on the proxy *) Split up the internet into however many subnets you have proxy host IPs *) route each part of the internet to your default gateway tacking on "dev eth0:n". This will make the default IP for reaching each subnet of the internet the IP from eth0:n. Of course you probably won't get very good load balancing of connections over your IPs that way, but it's better than nothing and a really quick fix that would give you immediate additional capacity. I was going to also suggest, that to get better balancing, you could periodically (for some relatively short period) rotate the internet subnet routes such that you'd change which parts of the internet were pointed at which dev eth0:n every so many seconds or minutes, but that's kind of annoying to people like me (similar to the problem I recently posted about with AT&T 3G data web proxy). Having your software round robin the source IPs would probably introduce the same problem/effect. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From marka at isc.org Wed Dec 5 22:01:27 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Dec 2012 09:01:27 +1100 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: Your message of "Wed, 05 Dec 2012 15:56:30 CDT." References: Message-ID: <20121205220127.7F6F12CA0F17@drugs.dv.isc.org> In message , William Herrin writes: > On Wed, Dec 5, 2012 at 2:55 PM, Ray Soucy wrote: > > For each second that goes by you remove X addresses from the available > > pool of ports for new connections for whatever the TCP_TIMEWAIT_LEN is > > set to (60 seconds by default in Linux). > > > > In this case it's making quick connections for HTTP requests (most of > > which finish in less than a second). > > > > Say you have a pool of 30,000 ports and 500 new connections per second > > (typical): > > 1 second goes by you now have 29500 > > 10 seconds go by you now have 25000 > > 30 seconds go by you now have 15000 > > at 59 seconds you get to 29500, > > at 60 you get back 500 and stay at 29500 and that keeps rolling at > > 29500. Everyone is happy. > > > The thing is, Linux doesn't behave quite that way. > > If you do an anonymous connect(), that is you socket() and then > connect() without a bind() in the middle, then the limit applies *per > destination IP:port pair*. So, you should be able to do 30,000 > connections to 192.168.1.1 port 80, another 30,000 connections to > 192.168.1.2 port 80, and so on. The socket api is missing a bind + connect call which restricts the source address when making the connect. This is needed when you are required to use a fixed source address. > You should only fail if you A) bump against the top of NR_OPEN or B) > try to do a massive number of TCP connections to the same remote IP > address. > > Try it: set up a listener on discard that just closes the connection > and repeat connect() to 127.0.0.5 until you get an error. Then confirm > that you're out of ports: > > telnet 127.0.0.5 9 > Trying 127.0.0.5... > telnet: Unable to connect to remote host: Cannot assign requested address > > And confirm that you can still make outbound connections to a > different IP address: > > telnet 127.0.0.4 9 > Trying 127.0.0.4... > Connected to 127.0.0.4. > Escape character is '^]'. > Connection closed by foreign host. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From fred at cisco.com Wed Dec 5 22:06:29 2012 From: fred at cisco.com (Fred Baker (fred)) Date: Wed, 5 Dec 2012 22:06:29 +0000 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: Message-ID: <8C48B86A895913448548E6D15DA7553B6F9FC4@xmb-rcd-x09.cisco.com> If you want to get into software rewriting, the simplest thing I might come up with would be to put TCBs in some form of LRU list and, at a point where you need a port back, close the TCB that least recently did anything. My understanding is that this was implemented 15 years ago to manage SYN attacks, and could be built on to manage this form of "attack". Or, change the period of time a TCB is willing to stay in time-wait. Instead of 60 seconds, make it 10. On Dec 5, 2012, at 1:11 PM, Jon Lewis wrote: > On Wed, 5 Dec 2012, Ray Soucy wrote: > >> So if I rebuild the kernel to use a 20 second timeout, then that 30000 >> port pool can sustain 1500, and a 60000 port pool can sustain 3000 >> connections per second. >> >> The software could be re-written to round-robin though IP addresses >> for outgoing requests, but trying to avoid that. > > It's kind of a hack, but you don't have to rewrite the software to get different source IPs for different connections. On linux, you could do the following: > > *) Keep your normal default route > *) Configure extra IPs as aliases (eth0:0, eth0:1,...) on the proxy > *) Split up the internet into however many subnets you have proxy host IPs *) route each part of the internet to your default gateway tacking on "dev eth0:n". > > This will make the default IP for reaching each subnet of the internet the IP from eth0:n. > > Of course you probably won't get very good load balancing of connections over your IPs that way, but it's better than nothing and a really quick fix that would give you immediate additional capacity. > > I was going to also suggest, that to get better balancing, you could periodically (for some relatively short period) rotate the internet subnet routes such that you'd change which parts of the internet were pointed at which dev eth0:n every so many seconds or minutes, but that's kind of annoying to people like me (similar to the problem I recently posted about with AT&T 3G data web proxy). Having your software round robin the source IPs would probably introduce the same problem/effect. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From cyril at bouthors.org Wed Dec 5 21:18:48 2012 From: cyril at bouthors.org (Cyril Bouthors) Date: Wed, 05 Dec 2012 22:18:48 +0100 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: (Ray Soucy's message of "Wed, 5 Dec 2012 10:59:35 -0500") References: Message-ID: <87boe8mc3r.fsf@lenovo.isvtec.com> On 5 Dec 2012, rps at maine.edu wrote: > Where there is no way to change this though /proc 10:17PM lenovo:~% sudo sysctl -a |grep wait net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60 net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120 10:17PM lenovo:~% ? We use this to work around the default limit on our internal load balancers. HIH. -- Cyril Bouthors - Administration Syst?me, Infog?rance ISVTEC SARL, 14 avenue de l'Op?ra, 75001 Paris 1 rue ?mile Zola, 69002 Lyon T?l : 01 84 16 16 17 - Fax : 01 77 72 57 24 Ligne directe : 0x7B9EE3B0E From bill at herrin.us Wed Dec 5 22:24:47 2012 From: bill at herrin.us (William Herrin) Date: Wed, 5 Dec 2012 17:24:47 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: <20121205220127.7F6F12CA0F17@drugs.dv.isc.org> References: <20121205220127.7F6F12CA0F17@drugs.dv.isc.org> Message-ID: On Wed, Dec 5, 2012 at 5:01 PM, Mark Andrews wrote: > In message , > William Herrin writes: >> The thing is, Linux doesn't behave quite that way. >> >> If you do an anonymous connect(), that is you socket() and then >> connect() without a bind() in the middle, then the limit applies *per >> destination IP:port pair*. So, you should be able to do 30,000 >> connections to 192.168.1.1 port 80, another 30,000 connections to >> 192.168.1.2 port 80, and so on. > > The socket api is missing a bind + connect call which restricts the > source address when making the connect. This is needed when you > are required to use a fixed source address. Hi Mark, There are ways around this problem in Linux. For example you can mark a packet with iptables based on the uid of the process which created it and then you can NAT the source address based on the mark. Little messy but the tools are there. Anyway, Ray didn't indicate that he needed a fixed source address other than the one the machine would ordinarily choose for itself. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From terry.baranski.list at gmail.com Wed Dec 5 22:30:16 2012 From: terry.baranski.list at gmail.com (Terry Baranski) Date: Wed, 5 Dec 2012 17:30:16 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: Message-ID: <50bfcb0f.46cbe00a.5413.ffffb592@mx.google.com> On Wed, 5 Dec 2012, Ray Soucy wrote: > My question is basically, "how low can you go?" > > There seems to be consensus around 20 seconds being safe, > 15 being a 99% OK, and 10 or less being problematic. I'm trying to imagine how even 10 could be problematic nowadays. Have you found people reporting specific issues with 10? -Terry From marka at isc.org Wed Dec 5 22:35:29 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Dec 2012 09:35:29 +1100 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: Your message of "Wed, 05 Dec 2012 17:24:47 CDT." References: <20121205220127.7F6F12CA0F17@drugs.dv.isc.org> Message-ID: <20121205223529.99B6B2CA166E@drugs.dv.isc.org> In message , William Herrin writes: > On Wed, Dec 5, 2012 at 5:01 PM, Mark Andrews wrote: > > In message om>, > > William Herrin writes: > >> The thing is, Linux doesn't behave quite that way. > >> > >> If you do an anonymous connect(), that is you socket() and then > >> connect() without a bind() in the middle, then the limit applies *per > >> destination IP:port pair*. So, you should be able to do 30,000 > >> connections to 192.168.1.1 port 80, another 30,000 connections to > >> 192.168.1.2 port 80, and so on. > > > > The socket api is missing a bind + connect call which restricts the > > source address when making the connect. This is needed when you > > are required to use a fixed source address. > > Hi Mark, > > There are ways around this problem in Linux. For example you can mark > a packet with iptables based on the uid of the process which created > it and then you can NAT the source address based on the mark. Little > messy but the tools are there. And not available to the ordinary user. Nameservers potentially run into this limit. This is something The OpenGroup need to address when updating the next revision of the socket api in POSIX. > Anyway, Ray didn't indicate that he needed a fixed source address > other than the one the machine would ordinarily choose for itself. But he didn't say it wasn't required either. Mark -- 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 Wed Dec 5 22:39:29 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Dec 2012 09:39:29 +1100 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: Your message of "Thu, 06 Dec 2012 09:35:29 +1100." Message-ID: <20121205223929.5DC6E2CA16DA@drugs.dv.isc.org> Mark Andrews writes: > > In message >, > William Herrin writes: > > On Wed, Dec 5, 2012 at 5:01 PM, Mark Andrews wrote: > > > In message .c > > om>, > > > William Herrin writes: > > >> The thing is, Linux doesn't behave quite that way. > > >> > > >> If you do an anonymous connect(), that is you socket() and then > > >> connect() without a bind() in the middle, then the limit applies *per > > >> destination IP:port pair*. So, you should be able to do 30,000 > > >> connections to 192.168.1.1 port 80, another 30,000 connections to > > >> 192.168.1.2 port 80, and so on. > > > > > > The socket api is missing a bind + connect call which restricts the > > > source address when making the connect. This is needed when you > > > are required to use a fixed source address. > > > > Hi Mark, > > > > There are ways around this problem in Linux. For example you can mark > > a packet with iptables based on the uid of the process which created > > it and then you can NAT the source address based on the mark. Little > > messy but the tools are there. > > And not available to the ordinary user. Nameservers potentially run > into this limit. This is something The OpenGroup need to address when > updating the next revision of the socket api in POSIX. Even a "LATEBINDPORT" setsockopt call would do so that bind() on ties down the source address not the source address and port. > > Anyway, Ray didn't indicate that he needed a fixed source address > > other than the one the machine would ordinarily choose for itself. > > But he didn't say it wasn't required either. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tom.taylor.stds at gmail.com Wed Dec 5 23:07:00 2012 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Wed, 05 Dec 2012 18:07:00 -0500 Subject: /. ITU Approves Deep Packet Inspection In-Reply-To: <50BF9C7E.7000506@massar.ch> References: <20121205093448.GH9750@leitl.org> <50BF9A15.3060406@gmail.com> <50BF9C7E.7000506@massar.ch> Message-ID: <50BFD394.3080402@gmail.com> On 05/12/2012 2:11 PM, Jeroen Massar wrote: > On 2012-12-05 14:01, Tom Taylor wrote: >> I'm seriously not clear why Y.2770 is characterized as "negotiated >> behind closed doors". Any drafts were available to all participants in >> the ITU-T, on exactly the same terms as drafts of other Recommendations. >> As an example, the draft coming out of the October, 2011 meeting can be >> seen at http://www.itu.int/md/T09-SG13-111010-TD-WP4-0201/en. (I have >> access delegated by a vendor to whom I have been consulting, by virtue >> of their membership in the ITU-T.) > > So, how exactly can most people on for instance this list access that > URL? You yourself would not be able to access it where it not that you > found some loophole setup. > ... Agreed that the ITU-T is a membership organization, but the Questions and Study Group work programs are open to view (Q. 17/13 specifically covers DPI, and has more documents coming down the pipe). If you want to follow some Question you can probably get access through your government (State Dept. in the US, Dept. of Communications in Canada). The membership rules don't apply so stringently to Rapporteurs' meetings, so you can get in touch with the Rapporteur of a Question you are interested in and find out where to get copies of documents contributed into those meetings. All this is by the by -- you are more likely to be affected by the IETF than by anything coming out of the ITU-T. From drc at virtualized.org Wed Dec 5 23:08:33 2012 From: drc at virtualized.org (David Conrad) Date: Wed, 5 Dec 2012 15:08:33 -0800 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: <8C48B86A895913448548E6D15DA7553B6F9FC4@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B6F9FC4@xmb-rcd-x09.cisco.com> Message-ID: <24A4E198-186C-49A5-8B7C-FD1080DF8480@virtualized.org> On Dec 5, 2012, at 2:06 PM, Fred Baker (fred) wrote: > If you want to get into software rewriting, the simplest thing I might come up with would be to put TCBs in some form of LRU list and, at a point where you need a port back, close the TCB that least recently did anything. My understanding is that this was implemented 15 years ago to manage SYN attacks, and could be built on to manage this form of "attack". I can say for certain that it was implemented (at least) twice that long ago (circa 1983) in a TCP implementation for a particular memory constrained environment ("640K should be good enough for anybody") :). Regards, -drc From brent at brentrjones.com Wed Dec 5 23:09:45 2012 From: brent at brentrjones.com (Brent Jones) Date: Wed, 5 Dec 2012 15:09:45 -0800 Subject: 75 Broad NYC explosion Message-ID: I heard through the grapevine that there was an explosion in the basement of 75 Broad St in NYC. Provider isn't able to provide any details at this time, but would anyone local have additional information on what is happening there? -- Brent Jones brent at brentrjones.com From owen at delong.com Wed Dec 5 23:14:40 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 5 Dec 2012 15:14:40 -0800 Subject: /. ITU Approves Deep Packet Inspection In-Reply-To: <50BFD394.3080402@gmail.com> References: <20121205093448.GH9750@leitl.org> <50BF9A15.3060406@gmail.com> <50BF9C7E.7000506@massar.ch> <50BFD394.3080402@gmail.com> Message-ID: On Dec 5, 2012, at 15:07 , Tom Taylor wrote: > On 05/12/2012 2:11 PM, Jeroen Massar wrote: >> On 2012-12-05 14:01, Tom Taylor wrote: >>> I'm seriously not clear why Y.2770 is characterized as "negotiated >>> behind closed doors". Any drafts were available to all participants in >>> the ITU-T, on exactly the same terms as drafts of other Recommendations. >>> As an example, the draft coming out of the October, 2011 meeting can be >>> seen at http://www.itu.int/md/T09-SG13-111010-TD-WP4-0201/en. (I have >>> access delegated by a vendor to whom I have been consulting, by virtue >>> of their membership in the ITU-T.) >> >> So, how exactly can most people on for instance this list access that >> URL? You yourself would not be able to access it where it not that you >> found some loophole setup. >> > ... > Agreed that the ITU-T is a membership organization, but the Questions and Study Group work programs are open to view (Q. 17/13 specifically covers DPI, and has more documents coming down the pipe). If you want to follow some Question you can probably get access through your government (State Dept. in the US, Dept. of Communications in Canada). The membership rules don't apply so stringently to Rapporteurs' meetings, so you can get in touch with the Rapporteur of a Question you are interested in and find out where to get copies of documents contributed into those meetings. > > All this is by the by -- you are more likely to be affected by the IETF than by anything coming out of the ITU-T. I am affected by ITU-T every day. I use telephones. I am a Ham radio operator. I am a pilot. I use international digital circuits. All of these things are affected by ITU-T. Yes, anyone willing to expend enough effort and/or resources can get behind many of the closed doors for a non-participatory role in ITU process. To become participatory, you must be a government or invited by a government as part of their delegation. Contrasting this to the openness of the IETF, ICANN, and the RIRs, I think there is a pretty strong case to be made that the ITU is a closed-door process by comparison. Owen From mnathani at winvive.com Wed Dec 5 23:17:14 2012 From: mnathani at winvive.com (Mansoor Nathani) Date: Wed, 5 Dec 2012 18:17:14 -0500 Subject: 75 Broad NYC explosion In-Reply-To: References: Message-ID: Looks like the building was evacuated: http://twitter.com/tekmaven/status/276456362454704128 Mansoor On Wed, Dec 5, 2012 at 6:09 PM, Brent Jones wrote: > 75 Broad St From mikevs at xs4all.net Wed Dec 5 23:25:53 2012 From: mikevs at xs4all.net (Miquel van Smoorenburg) Date: Thu, 6 Dec 2012 00:25:53 +0100 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: <20121205220127.7F6F12CA0F17@drugs.dv.isc.org> References: Message-ID: <201212052325.qB5NPrZe005631@xs8.xs4all.nl> In article you write: > >In message , > William Herrin writes: >> The thing is, Linux doesn't behave quite that way. >> >> If you do an anonymous connect(), that is you socket() and then >> connect() without a bind() in the middle, then the limit applies *per >> destination IP:port pair*. So, you should be able to do 30,000 >> connections to 192.168.1.1 port 80, another 30,000 connections to >> 192.168.1.2 port 80, and so on. > >The socket api is missing a bind + connect call which restricts the >source address when making the connect. This is needed when you >are required to use a fixed source address. William was talking about the destination address. Linux (and I would hope any other network stack) can really open a million connections from one source address, as long as it's not to one destination address but to lots of different ones. It's not the (srcip,srcport) tuple that needs to be unique; it's the (srcip,srcport,dstip,dstport) tuple. Anyway, you can actually bind to a source address and still have a dynamic source port; just use port 0. Lots of tools do this. (for example, strace nc -s 127.0.0.2 127.0.0.1 22 and see what it does) Mike. From acooper at cdt.org Wed Dec 5 23:47:50 2012 From: acooper at cdt.org (Alissa Cooper) Date: Wed, 5 Dec 2012 18:47:50 -0500 Subject: /. ITU Approves Deep Packet Inspection In-Reply-To: <50BFD394.3080402@gmail.com> References: <20121205093448.GH9750@leitl.org> <50BF9A15.3060406@gmail.com> <50BF9C7E.7000506@massar.ch> <50BFD394.3080402@gmail.com> Message-ID: <05953939-44AB-4929-897E-17B535C8A9F2@cdt.org> On Dec 5, 2012, at 6:07 PM, Tom Taylor wrote: > Agreed that the ITU-T is a membership organization, but the Questions and Study Group work programs are open to view (Q. 17/13 specifically covers DPI, and has more documents coming down the pipe). If you want to follow some Question you can probably get access through your government (State Dept. in the US, Dept. of Communications in Canada). The membership rules don't apply so stringently to Rapporteurs' meetings, so you can get in touch with the Rapporteur of a Question you are interested in and find out where to get copies of documents contributed into those meetings. The above is not exactly what I would call an ideal process for ensuring that standards receive broad input from subject matter experts, regardless of where they're located or who they might know in their central governments. In any event, the point of the original blog post was not to criticize closed membership organizations per se, it was to point out the shortcomings of making standards mandatory (as some proposed changes to the ITRs would do) when they are generated by such membership organizations. Alissa From marka at isc.org Thu Dec 6 00:49:09 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Dec 2012 11:49:09 +1100 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: Your message of "Thu, 06 Dec 2012 00:25:53 BST." <201212052325.qB5NPrZe005631@xs8.xs4all.nl> References: <201212052325.qB5NPrZe005631@xs8.xs4all.nl> Message-ID: <20121206004909.B302F2CA212F@drugs.dv.isc.org> In message <201212052325.qB5NPrZe005631 at xs8.xs4all.nl>, "Miquel van Smoorenburg" writes: > In article you write: > > > >In message m>, > > William Herrin writes: > >> The thing is, Linux doesn't behave quite that way. > >> > >> If you do an anonymous connect(), that is you socket() and then > >> connect() without a bind() in the middle, then the limit applies *per > >> destination IP:port pair*. So, you should be able to do 30,000 > >> connections to 192.168.1.1 port 80, another 30,000 connections to > >> 192.168.1.2 port 80, and so on. > > > >The socket api is missing a bind + connect call which restricts the > >source address when making the connect. This is needed when you > >are required to use a fixed source address. > > William was talking about the destination address. Linux (and I would > hope any other network stack) can really open a million connections > from one source address, as long as it's not to one destination address > but to lots of different ones. It's not the (srcip,srcport) tuple that > needs to be unique; it's the (srcip,srcport,dstip,dstport) tuple. > > Anyway, you can actually bind to a source address and still have a > dynamic source port; just use port 0. Lots of tools do this. > > (for example, strace nc -s 127.0.0.2 127.0.0.1 22 and see what it does) > > Mike. Eventually the bind call fails. Below was a counter: dest address in hex 16376: 1a003ff9 16377: 1a003ffa bind: before bind: Can't assign requested address 16378: 1a003ffb connect: Can't assign requested address bind: before bind: Can't assign requested address and if you remove the bind() the connect fails 16378: 1a003ffb 16379: 1a003ffc connect: Can't assign requested address 16380: 1a003ffd this is with a simple loop socket() ioctl(FIONBIO) bind(addr++:80) connect() I had a firewall dropping the connection attempts -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jlewis at lewis.org Thu Dec 6 01:44:43 2012 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 5 Dec 2012 20:44:43 -0500 (EST) Subject: TCP time_wait and port exhaustion for servers In-Reply-To: <87boe8mc3r.fsf@lenovo.isvtec.com> References: <87boe8mc3r.fsf@lenovo.isvtec.com> Message-ID: On Wed, 5 Dec 2012, Cyril Bouthors wrote: > On 5 Dec 2012, rps at maine.edu wrote: > >> Where there is no way to change this though /proc > > 10:17PM lenovo:~% sudo sysctl -a |grep wait > net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 > net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 > net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 > net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120 > net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60 > net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120 Those netfilter connection tracking tunables have nothing to do with the kernel's TCP socket handling. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From marka at isc.org Thu Dec 6 03:29:24 2012 From: marka at isc.org (Mark Andrews) Date: Thu, 06 Dec 2012 14:29:24 +1100 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: Your message of "Thu, 06 Dec 2012 11:49:09 +1100." <20121206004909.B302F2CA212F@drugs.dv.isc.org> References: <201212052325.qB5NPrZe005631@xs8.xs4all.nl> <20121206004909.B302F2CA212F@drugs.dv.isc.org> Message-ID: <20121206032925.26F8C2CA3318@drugs.dv.isc.org> In message <20121206004909.B302F2CA212F at drugs.dv.isc.org>, Mark Andrews writes: > > In message <201212052325.qB5NPrZe005631 at xs8.xs4all.nl>, "Miquel van Smoorenburg" > writes: > > In article you write: > > > > > >In message > m>, > > > William Herrin writes: > > >> The thing is, Linux doesn't behave quite that way. > > >> > > >> If you do an anonymous connect(), that is you socket() and then > > >> connect() without a bind() in the middle, then the limit applies *per > > >> destination IP:port pair*. So, you should be able to do 30,000 > > >> connections to 192.168.1.1 port 80, another 30,000 connections to > > >> 192.168.1.2 port 80, and so on. > > > > > >The socket api is missing a bind + connect call which restricts the > > >source address when making the connect. This is needed when you > > >are required to use a fixed source address. > > > > William was talking about the destination address. Linux (and I would > > hope any other network stack) can really open a million connections > > from one source address, as long as it's not to one destination address > > but to lots of different ones. It's not the (srcip,srcport) tuple that > > needs to be unique; it's the (srcip,srcport,dstip,dstport) tuple. > > > > Anyway, you can actually bind to a source address and still have a > > dynamic source port; just use port 0. Lots of tools do this. > > > > (for example, strace nc -s 127.0.0.2 127.0.0.1 22 and see what it does) > > > > Mike. > > Eventually the bind call fails. Below was a > > counter: dest address in hex > > 16376: 1a003ff9 > 16377: 1a003ffa > bind: before bind: Can't assign requested address > 16378: 1a003ffb > connect: Can't assign requested address > bind: before bind: Can't assign requested address > > and if you remove the bind() the connect fails > > 16378: 1a003ffb > 16379: 1a003ffc > connect: Can't assign requested address > 16380: 1a003ffd > > this is with a simple loop > > socket() > ioctl(FIONBIO) > bind(addr++:80) > connect() > > I had a firewall dropping the connection attempts To get more one needs to setsockopt SO_REUSEADDR but that consumes all the port space so applications that need to listen for incoming connections on the same machine will break. If you also set IP_PORTRANGE_HIGH and have configured the system so that the high range does not match the default range then you can avoid the above issue. This is the default configuration for some but not all platforms. Sockets with IP_PORTRANGE_HIGH set are not expected to accept incoming traffic. So if you are making a out bound connections you should set SO_REUSEADDR and IP_PORTRANGE_HIGH options on the socket to avoid local port limits. Not most applications do not do this which is fine until you are using 10's of thousands of outgoing sockets. Mark > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bill at herrin.us Thu Dec 6 04:29:22 2012 From: bill at herrin.us (William Herrin) Date: Wed, 5 Dec 2012 23:29:22 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: <20121206004909.B302F2CA212F@drugs.dv.isc.org> References: <201212052325.qB5NPrZe005631@xs8.xs4all.nl> <20121206004909.B302F2CA212F@drugs.dv.isc.org> Message-ID: On Wed, Dec 5, 2012 at 7:49 PM, Mark Andrews wrote: > counter: dest address in hex > > 16376: 1a003ff9 > 16377: 1a003ffa > bind: before bind: Can't assign requested address > 16378: 1a003ffb > connect: Can't assign requested address > bind: before bind: Can't assign requested address > > and if you remove the bind() the connect fails > > 16378: 1a003ffb > 16379: 1a003ffc > connect: Can't assign requested address > 16380: 1a003ffd Tried it. When I removed the bind() I made it to a quarter million connections before I ran out of ram on the test machine and the out of memory killer swung into action. Don't know what your problem is. for (count=0; count<1000000; count++) { s=sockets[count]=socket(AF_INET,SOCK_STREAM,0); if (s<0) { printf ("\nCould not get socket #%d\n",count); sleep (900); return 1; } if (connect(sockets[count], (struct sockaddr *) &sa, sizeof(sa))<0) { if (errno != 115) { printf ("\nErrno %d on socket #%d\n",(int) errno, count); sleep (900); return 1; } } sa.sin_addr.s_addr = htonl(ntohl(sa.sin_addr.s_addr)+1); now = time(NULL); if (now!=before) { before=now; fprintf (stdout,"%d\r",count); fflush (stdout); } } Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From frnkblk at iname.com Thu Dec 6 05:00:31 2012 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 5 Dec 2012 23:00:31 -0600 Subject: Streaming video traffic increase from Level3? Message-ID: <008801cdd36e$9e577f10$db067d30$@iname.com> This evening I saw a quadruple increase in traffic volume from Level3 address space, a one-third increase in peak streaming video usage overall, and when I did a few checks with our netflow tool, it looks like customers that were streaming Netflix content just days before are now getting it out of Level3 space rather than our local cache or our upstream provider's Netflix cache. We also exceeded our previous peak usage by 12%. Did something change with Netflix that would have resulted in greater usage? Did Netflix defaults change so that customers are now using HD, or a higher-rate bitrate HD? Frank From mansaxel at besserwisser.org Thu Dec 6 08:39:03 2012 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 6 Dec 2012 09:39:03 +0100 Subject: Any enterprise operators very happy with their MPLS providers? In-Reply-To: <12B3AEACEC284C4AA5D4CB88D3D345B501FB175845@ATL01VMB001WP.tkitna.local> References: <12B3AEACEC284C4AA5D4CB88D3D345B501FB175845@ATL01VMB001WP.tkitna.local> Message-ID: <20121206083903.GF20002@besserwisser.org> Subject: Any enterprise operators very happy with their MPLS providers? Date: Wed, Dec 05, 2012 at 02:14:25PM +0000 Quoting McCall, Gabriel (Gabriel.McCall at thyssenkrupp.com): > I'm getting ready to prepare an RFP for our next generation WAN, and would like feedback from anyone else who has 100+ MPLS nodes on their quality of account service and technical performance. > > My current landscape includes AT&T, Sprint, and Verizon. I'm almost completely happy with Sprint- they're about in the A- range. AT&T is muddling along at about a C, and Verizon is a solid F. I've heard very good things from some CenturyLink customers and will definitely include them in the bidder list- is anyone else doing a very good job for you? We did a survey around 2008-9 in Sweden and concluded that the risk of large hysteresis IPDV and Q-in-Q outweighed the attractiveness (mainly price) of running on top of somebody elses MPLS. A major contributing factor was, and is, also that we ourselves are running MPLS for our logical separation needs, and that we predicted and got a lot of real-time critical RTP streams on the internal WAN. We bought "Gigabit Ethernet compatible channels" over mainly dark fiber or WDM and included text in the call for tender about not even trying to offer MPLS-based L2.. This was done under EU Public call for tender legislation, which was a challenge. We are quite happy, and slashed our old inflated price for relatively small SDH links by a lot. If, OTOH, you are not a very distributed radio company trying to do RTP in 48kHz 24-bit linear stereo over internal WAN, using multicast, you might be fine with a MPLS offering... -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I have a VISION! It's a RANCID double-FISHWICH on an ENRICHED BUN!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From adam.vitkovsky at swan.sk Thu Dec 6 08:55:01 2012 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Thu, 6 Dec 2012 09:55:01 +0100 Subject: /. ITU Approves Deep Packet Inspection In-Reply-To: <20121205093448.GH9750@leitl.org> References: <20121205093448.GH9750@leitl.org> Message-ID: <016101cdd38f$6038ed60$20aac820$@swan.sk> So is it recommended now to go over all the NGN core routers and restore them to default with: no lawful-intercept disable cmd? :) adam From ops.lists at gmail.com Thu Dec 6 11:30:31 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 06 Dec 2012 03:30:31 -0800 Subject: Google Fiber - keeps you regular Message-ID: <50c081d7.0xwaJdqoLgLNIuML%ops.lists@gmail.com> http://www.youtube.com/watch?v=re0VRK6ouwI&feature=share you'll probably laugh so hard you won't even need the fiber From kyrian at ore.org Thu Dec 6 13:25:28 2012 From: kyrian at ore.org (Kyrian) Date: Thu, 06 Dec 2012 13:25:28 +0000 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: Message-ID: <20121206132528.18044lmiz7spnq4g@webmail.orenet.co.uk> On 5 Dec 2012, rps at maine.edu wrote: > > Where there is no way to change this though /proc ... > Those netfilter connection tracking tunables have nothing to do with the > kernel's TCP socket handling. > No, but these do... net.ipv4.tcp_keepalive_intvl = 15 net.ipv4.tcp_keepalive_probes = 3 net.ipv4.tcp_keepalive_time = 90 net.ipv4.tcp_fin_timeout = 30 I think the OP was wrong, and missed something. I'm no TCP/IP expert, but IME connections go into TIME_WAIT for a period pertaining to the above tuneables (X number of probes at Y interval until the remote end is declared likely dead and gone), and then go into FIN_WAIT and then IIRC FIN_WAIT2 or some other state like that before they are finally killed off. Those tunables certainly seem to have actually worked in the real world for me, whether they are right "in theory" or not is possibly another matter. Broadly speaking I agree with the other posters who've suggested adding other IP addresses and opening up the local port range available. I'm assuming the talk of 30k connections is because the OP's proxy has a 'one in one out' situation going on with connections, and that's why your ~65k pool for connections is halved. K. From rps at maine.edu Thu Dec 6 13:31:32 2012 From: rps at maine.edu (Ray Soucy) Date: Thu, 6 Dec 2012 08:31:32 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: <20121205220127.7F6F12CA0F17@drugs.dv.isc.org> Message-ID: It does require a fixed source address. The box is also a router and firewall, so it has many IP addresses available to it. On Wed, Dec 5, 2012 at 5:24 PM, William Herrin wrote: > On Wed, Dec 5, 2012 at 5:01 PM, Mark Andrews wrote: >> In message , >> William Herrin writes: >>> The thing is, Linux doesn't behave quite that way. >>> >>> If you do an anonymous connect(), that is you socket() and then >>> connect() without a bind() in the middle, then the limit applies *per >>> destination IP:port pair*. So, you should be able to do 30,000 >>> connections to 192.168.1.1 port 80, another 30,000 connections to >>> 192.168.1.2 port 80, and so on. >> >> The socket api is missing a bind + connect call which restricts the >> source address when making the connect. This is needed when you >> are required to use a fixed source address. > > Hi Mark, > > There are ways around this problem in Linux. For example you can mark > a packet with iptables based on the uid of the process which created > it and then you can NAT the source address based on the mark. Little > messy but the tools are there. > > Anyway, Ray didn't indicate that he needed a fixed source address > other than the one the machine would ordinarily choose for itself. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From rps at maine.edu Thu Dec 6 13:32:03 2012 From: rps at maine.edu (Ray Soucy) Date: Thu, 6 Dec 2012 08:32:03 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: <87boe8mc3r.fsf@lenovo.isvtec.com> References: <87boe8mc3r.fsf@lenovo.isvtec.com> Message-ID: This tunes conntrack, not local TCP on the server itself. On Wed, Dec 5, 2012 at 4:18 PM, Cyril Bouthors wrote: > On 5 Dec 2012, rps at maine.edu wrote: > >> Where there is no way to change this though /proc > > 10:17PM lenovo:~% sudo sysctl -a |grep wait > net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 > net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 > net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 > net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120 > net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60 > net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120 > 10:17PM lenovo:~% > > ? > > We use this to work around the default limit on our internal load balancers. > > HIH. > -- > Cyril Bouthors - Administration Syst?me, Infog?rance > ISVTEC SARL, 14 avenue de l'Op?ra, 75001 Paris > 1 rue ?mile Zola, 69002 Lyon > T?l : 01 84 16 16 17 - Fax : 01 77 72 57 24 > Ligne directe : 0x7B9EE3B0E -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From rsk at gsp.org Thu Dec 6 13:45:18 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 6 Dec 2012 08:45:18 -0500 Subject: Fwd: [Infowarrior] - Leaked: ITU's secret Internet surveillance standard discussion draft] Message-ID: <20121206134518.GA3100@gsp.org> ----- Forwarded message from Richard Forno ----- > From: Richard Forno > Date: Thu, 6 Dec 2012 08:21:15 -0500 > To: Infowarrior List > Subject: [Infowarrior] - Leaked: ITU's secret Internet surveillance standard > discussion draft > > > Leaked: ITU's secret Internet surveillance standard discussion draft > http://boingboing.net/2012/12/05/leaked-itus-secret-internet.html > > --- > Just because i'm near the punchbowl doesn't mean I'm also drinking from it. > > _______________________________________________ > Infowarrior mailing list > Infowarrior at attrition.org > https://attrition.org/mailman/listinfo/infowarrior ----- End forwarded message ----- From rps at maine.edu Thu Dec 6 13:58:10 2012 From: rps at maine.edu (Ray Soucy) Date: Thu, 6 Dec 2012 08:58:10 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: <20121206132528.18044lmiz7spnq4g@webmail.orenet.co.uk> References: <20121206132528.18044lmiz7spnq4g@webmail.orenet.co.uk> Message-ID: > net.ipv4.tcp_keepalive_intvl = 15 > net.ipv4.tcp_keepalive_probes = 3 > net.ipv4.tcp_keepalive_time = 90 > net.ipv4.tcp_fin_timeout = 30 As discussed, those do not affect TCP_TIMEWAIT_LEN. There is a lot of misinformation out there on this subject so please don't just Google for 5 min. and chime in with a "solution" that you haven't verified yourself. We can expand the ephemeral port range to be a full 60K (and we have as a band-aid), but that only delays the issue as use grows. I can verify that changing it via: echo 1025 65535 > /proc/sys/net/ipv4/ip_local_port_range Does work for the full range, as a spot check shows ports as low as 2000 and as high as 64000 being used. While this works fine for the majority of our sites as they average well below that, for a handful peak hours can spike above 1000 connections per second; so we would really like to see something closer to an ability to provide closer to 2000 or 2500 connections a second for the amount of bandwidth being delivered through the unit (full gigabit). But ideally we would find a way to significantly reduce the number of ports being chewed up for outgoing connections. On the incoming side everything just makes use of the server port locally so it's not an issue. Trying to avoid using multiple source addresses for this as it would involve a fairly large configuration change to about 100+ units; each requiring coordination with the end-user, but it is a last resort option. The other issue is that this is all essentially squid, so a drastic re-design of how it handles networking is not ideal either. On Thu, Dec 6, 2012 at 8:25 AM, Kyrian wrote: > On 5 Dec 2012, rps at maine.edu wrote: > >> > Where there is no way to change this though /proc > > > ... > >> Those netfilter connection tracking tunables have nothing to do with the >> kernel's TCP socket handling. >> > No, but these do... > > net.ipv4.tcp_keepalive_intvl = 15 > net.ipv4.tcp_keepalive_probes = 3 > net.ipv4.tcp_keepalive_time = 90 > net.ipv4.tcp_fin_timeout = 30 > > I think the OP was wrong, and missed something. > > I'm no TCP/IP expert, but IME connections go into TIME_WAIT for a period > pertaining to the above tuneables (X number of probes at Y interval until > the remote end is declared likely dead and gone), and then go into FIN_WAIT > and then IIRC FIN_WAIT2 or some other state like that before they are > finally killed off. Those tunables certainly seem to have actually worked in > the real world for me, whether they are right "in theory" or not is possibly > another matter. > > Broadly speaking I agree with the other posters who've suggested adding > other IP addresses and opening up the local port range available. > > I'm assuming the talk of 30k connections is because the OP's proxy has a > 'one in one out' situation going on with connections, and that's why your > ~65k pool for connections is halved. > > K. > > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From kyrian at ore.org Thu Dec 6 15:20:09 2012 From: kyrian at ore.org (Kyrian) Date: Thu, 06 Dec 2012 15:20:09 +0000 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: <20121206132528.18044lmiz7spnq4g@webmail.orenet.co.uk> Message-ID: <20121206152009.392229pc987pze7c@webmail.orenet.co.uk> Quoting Ray Soucy : >> net.ipv4.tcp_keepalive_intvl = 15 >> net.ipv4.tcp_keepalive_probes = 3 >> net.ipv4.tcp_keepalive_time = 90 >> net.ipv4.tcp_fin_timeout = 30 > > As discussed, those do not affect TCP_TIMEWAIT_LEN. > > There is a lot of misinformation out there on this subject so please > don't just Google for 5 min. and chime in with a "solution" that you > haven't verified yourself. > ... >> Those tunables certainly seem to have actually worked in >> the real world for me, whether they are right "in theory" or not is possibly >> another matter. >> TLDR? They worked for me, to reduce connections in a TIME_WAIT state, in a real situation, after well over 5 minutes of Googling. Exactly as I said. Further, they differed from the (netfilter) ones posted previously that were stated as not having anything to do with it by someone or other. There's no cause at all for your snotty message back. What you didn't state in your email was whether these connections were being left in TIME_WAIT because they had not been closed (eg. mobile devices or similar that are somewhat notorious for not closing connections properly), or whether the "normal" close process was taking too long. I suspect that if you had clarified that point initially, things would have made more sense all round. The tunables listed above, AIUI handle connections that were not properly terminated, and idling out, whereas I believe (having had the opportunity to consider it in more depth) your situation seems more to do with "properly" terminated connections that have hard-coded behaviours in the kernel. Perhaps you can clarify for the benefit of the masses. Also, if you are going to hack the kernel to make that change, I urge you to make it part of the sysctl mechanism as well, and to send a patch back to the kernel developers to help out others who might be in a similar situation to you. This is both to help the community, and give you an easier means to tweak the setting as needed in future without a further kernel recompile. K. -- Kev Green, aka Kyrian. E: kyrian@ore.org WWW: http://kyrian.ore.org/ ISP/Perl/PHP/Linux/Security Contractor, via http://www.orenet.co.uk/ From william.allen.simpson at gmail.com Thu Dec 6 16:28:36 2012 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Thu, 06 Dec 2012 11:28:36 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: <20121206152009.392229pc987pze7c@webmail.orenet.co.uk> References: <20121206132528.18044lmiz7spnq4g@webmail.orenet.co.uk> <20121206152009.392229pc987pze7c@webmail.orenet.co.uk> Message-ID: <50C0C7B4.8040702@gmail.com> On 12/6/12 10:20 AM, Kyrian wrote: > Also, if you are going to hack the kernel to make that change, I urge you to make it part of the sysctl mechanism as well, and to send a patch back to the kernel developers to help out others who might be in a similar situation to you. This is both to help > the community, and give you an easier means to tweak the setting as needed in future without a further kernel recompile. > Of course, this whole problem would have gone away years ago, had more folks implemented RFC6013. Or prior recommendations going back 15+ years. Meanwhile, my experience with the Linux kernel team is that about 1/2 of the tweak will go in, and the rest will fall by the wayside. Only about 1/3 of RFC6013 made it into 2.6.32, even though I started feeding them code 6 months before publication. From jfmezei_nanog at vaxination.ca Thu Dec 6 16:33:30 2012 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Thu, 06 Dec 2012 11:33:30 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: <20121206132528.18044lmiz7spnq4g@webmail.orenet.co.uk> Message-ID: <50C0C8DA.1040007@vaxination.ca> Question: If a TCP connection is left hanging and continues to hoard the port for some time before it times out, shouldn't the work to be focused on finding out why the connection is not properly closed instead of trying to support a greater number of hung connections waiting to time out ? From mhuff at ox.com Thu Dec 6 17:11:42 2012 From: mhuff at ox.com (Matthew Huff) Date: Thu, 6 Dec 2012 12:11:42 -0500 Subject: Cogent outage? Message-ID: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> About 10 minutes ago we stopped being able to pass traffic through cogent. I de-peered us from Cogent, and everything appears better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing anything? ---- Matthew Huff? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5339 bytes Desc: not available URL: From ssaner at hubris.net Thu Dec 6 17:15:08 2012 From: ssaner at hubris.net (Steven Saner) Date: Thu, 06 Dec 2012 11:15:08 -0600 Subject: Cogent outage? In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> Message-ID: <50C0D29C.9080607@hubris.net> On 12/06/2012 11:11 AM, Matthew Huff wrote: > About 10 minutes ago we stopped being able to pass traffic through cogent. I de-peered us from Cogent, and everything appears > better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing anything? > Passing normal traffic in Kansas City. Steve -- -------------------------------------------------------------------------- Steven Saner Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communications http://www.hubris.net From emoore at sover.net Thu Dec 6 17:17:09 2012 From: emoore at sover.net (Evan Moore) Date: Thu, 6 Dec 2012 12:17:09 -0500 Subject: Cogent outage? In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> Message-ID: <1DD516A954DB5C49AC4D727BBB55ADFB25233C245E@Exchange-01.office.sover.net> I may have seen this as well. I touch Cogent in Boston. Seems to be returning as of 1717 GMT. ERM Evan R Moore Network Engineer Sovernet Communications -----Original Message----- From: Matthew Huff [mailto:mhuff at ox.com] Sent: Thursday, December 06, 2012 12:12 PM To: 'nanog at nanog.org' Subject: Cogent outage? About 10 minutes ago we stopped being able to pass traffic through cogent. I de-peered us from Cogent, and everything appears better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing anything? ---- Matthew Huff? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 From rps at maine.edu Thu Dec 6 17:18:17 2012 From: rps at maine.edu (Ray Soucy) Date: Thu, 6 Dec 2012 12:18:17 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: <50C0C8DA.1040007@vaxination.ca> References: <20121206132528.18044lmiz7spnq4g@webmail.orenet.co.uk> <50C0C8DA.1040007@vaxination.ca> Message-ID: This issue is for really for connections that close properly and without any issue. The application closes the socket and doesn't care about it; but the OS keeps it in the TIME_WAIT state as required by the RFC for TCP in case data tries to be sent after the connection has closed (out of order transmission). I think we're going to go with dropping it to 30 seconds instead of 60 seconds and seeing how that goes. It seems to be the direction taken by people who have implemented high traffic load balancers and proxy servers. I was hoping someone would have real data on what a realistic time window is for keeping a socket in a TIME_WAIT state, but it doesn't seem like anyone has collected data on it. On Thu, Dec 6, 2012 at 11:33 AM, Jean-Francois Mezei wrote: > Question: > > If a TCP connection is left hanging and continues to hoard the port for > some time before it times out, shouldn't the work to be focused on > finding out why the connection is not properly closed instead of trying > to support a greater number of hung connections waiting to time out ? > > > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From m4dh4tt3r at gmail.com Thu Dec 6 17:19:52 2012 From: m4dh4tt3r at gmail.com (Christopher Nielsen) Date: Thu, 6 Dec 2012 12:19:52 -0500 Subject: Cogent outage? In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> Message-ID: Passing normal traffic in San Jose and Ashburn. On Thu, Dec 6, 2012 at 12:11 PM, Matthew Huff wrote: > About 10 minutes ago we stopped being able to pass traffic through cogent. I de-peered us from Cogent, and everything appears > better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing anything? > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > -- Christopher Nielsen "They who can give up essential liberty for temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "The tree of liberty must be refreshed from time to time with the blood of patriots & tyrants." --Thomas Jefferson From nick at flhsi.com Thu Dec 6 17:19:48 2012 From: nick at flhsi.com (Nick Olsen) Date: Thu, 6 Dec 2012 12:19:48 -0500 Subject: Cogent outage? Message-ID: <2931a46d$18e6dd17$4dcaabe6$@flhsi.com> No issues seen in Orlando either. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Steven Saner" Sent: Thursday, December 06, 2012 12:17 PM To: nanog at nanog.org Subject: Re: Cogent outage? On 12/06/2012 11:11 AM, Matthew Huff wrote: > About 10 minutes ago we stopped being able to pass traffic through cogent. I de-peered us from Cogent, and everything appears > better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing anything? > Passing normal traffic in Kansas City. Steve -- -------------------------------------------------------------------------- Steven Saner Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communications http://www.hubris.net From paul4004 at gmail.com Thu Dec 6 17:21:52 2012 From: paul4004 at gmail.com (PC) Date: Thu, 6 Dec 2012 10:21:52 -0700 Subject: Cogent outage? In-Reply-To: <1DD516A954DB5C49AC4D727BBB55ADFB25233C245E@Exchange-01.office.sover.net> References: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> <1DD516A954DB5C49AC4D727BBB55ADFB25233C245E@Exchange-01.office.sover.net> Message-ID: No visible issues in the DC area. On Thu, Dec 6, 2012 at 10:17 AM, Evan Moore wrote: > I may have seen this as well. I touch Cogent in Boston. > > Seems to be returning as of 1717 GMT. > > ERM > > Evan R Moore > Network Engineer > Sovernet Communications > > > -----Original Message----- > From: Matthew Huff [mailto:mhuff at ox.com] > Sent: Thursday, December 06, 2012 12:12 PM > To: 'nanog at nanog.org' > Subject: Cogent outage? > > About 10 minutes ago we stopped being able to pass traffic through cogent. > I de-peered us from Cogent, and everything appears > better. When I call cogent, all I get is a busy signal (must be a major > outage). Anyone else seeing anything? > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > > > From jmillay at vermontel.com Thu Dec 6 17:23:33 2012 From: jmillay at vermontel.com (Jeremiah Millay) Date: Thu, 6 Dec 2012 17:23:33 +0000 Subject: Cogent outage? In-Reply-To: <1DD516A954DB5C49AC4D727BBB55ADFB25233C245E@Exchange-01.office.sover.net> References: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> <1DD516A954DB5C49AC4D727BBB55ADFB25233C245E@Exchange-01.office.sover.net> Message-ID: <1BCAAB14D63EE94BB4D367020193DDB608EE640C@VTELMAIL.vermonttel.com> Evan, We are hearing reports of this from our customers as well. We connect to them in NY and Boston. Jeremiah Millay Network Engineer Vermont Telephone Co., Inc. Phone: 802 885-7796 Mobile: 802 289-2116 E-Mail: jmillay at vermontel.com -----Original Message----- From: Evan Moore [mailto:emoore at sover.net] Sent: Thursday, December 06, 2012 12:17 PM To: 'Matthew Huff'; 'nanog at nanog.org' Subject: RE: Cogent outage? I may have seen this as well. I touch Cogent in Boston. Seems to be returning as of 1717 GMT. ERM Evan R Moore Network Engineer Sovernet Communications -----Original Message----- From: Matthew Huff [mailto:mhuff at ox.com] Sent: Thursday, December 06, 2012 12:12 PM To: 'nanog at nanog.org' Subject: Cogent outage? About 10 minutes ago we stopped being able to pass traffic through cogent. I de-peered us from Cogent, and everything appears better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing anything? ---- Matthew Huff? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 From wbailey at satelliteintelligencegroup.com Thu Dec 6 17:30:13 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 6 Dec 2012 17:30:13 +0000 Subject: Cogent outage? In-Reply-To: <2931a46d$18e6dd17$4dcaabe6$@flhsi.com> References: <2931a46d$18e6dd17$4dcaabe6$@flhsi.com> Message-ID: Internet pulse shows cogent being difficult. >From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Nick Olsen Date: 12/06/2012 9:28 AM (GMT-08:00) To: Steven Saner ,nanog at nanog.org Subject: Re: Cogent outage? No issues seen in Orlando either. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "Steven Saner" Sent: Thursday, December 06, 2012 12:17 PM To: nanog at nanog.org Subject: Re: Cogent outage? On 12/06/2012 11:11 AM, Matthew Huff wrote: > About 10 minutes ago we stopped being able to pass traffic through cogent. I de-peered us from Cogent, and everything appears > better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing anything? > Passing normal traffic in Kansas City. Steve -- -------------------------------------------------------------------------- Steven Saner Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communications http://www.hubris.net From mike at jellydonut.org Thu Dec 6 17:30:56 2012 From: mike at jellydonut.org (Michael Proto) Date: Thu, 6 Dec 2012 12:30:56 -0500 Subject: Cogent outage? In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> Message-ID: I'm seeing packet loss between my Atlanta Cogent connection and some servers we have in both Dallas and London. According to Cogent's status page they're having an outage in the NYC area. -Proto http://status.cogentco.com/ On Thu, Dec 6, 2012 at 12:11 PM, Matthew Huff wrote: > About 10 minutes ago we stopped being able to pass traffic through cogent. I de-peered us from Cogent, and everything appears > better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing anything? > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > From mhuff at ox.com Thu Dec 6 17:34:55 2012 From: mhuff at ox.com (Matthew Huff) Date: Thu, 6 Dec 2012 12:34:55 -0500 Subject: Cogent outage? In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F901AAC1413F44@PUR-EXCH07.ox.com> We are peered in Westchester Co, NY (north of NYC). Reports from status.cogentco.com suggest a problem in NYC. I wonder if it's related to the 75 Broad Street explosion this morning. According to Cogent status, they are running on generator. ---- Matthew Huff? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: Michael Proto [mailto:mike at jellydonut.org] > Sent: Thursday, December 06, 2012 12:31 PM > To: Matthew Huff > Cc: nanog at nanog.org > Subject: Re: Cogent outage? > > I'm seeing packet loss between my Atlanta Cogent connection and some > servers we have in both Dallas and London. According to Cogent's > status page they're having an outage in the NYC area. > > > -Proto > > http://status.cogentco.com/ > > On Thu, Dec 6, 2012 at 12:11 PM, Matthew Huff wrote: > > About 10 minutes ago we stopped being able to pass traffic through cogent. I de-peered us from > Cogent, and everything appears > > better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing > anything? > > > > ---- > > Matthew Huff | 1 Manhattanville Rd > > Director of Operations | Purchase, NY 10577 > > OTA Management LLC | Phone: 914-460-4039 > > aim: matthewbhuff | Fax: 914-460-4139 > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5339 bytes Desc: not available URL: From wbailey at satelliteintelligencegroup.com Thu Dec 6 17:39:52 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 6 Dec 2012 17:39:52 +0000 Subject: Cogent outage? In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com>, Message-ID: Internet pulse now shows cogent with increased latency on nearly every peer. >From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Christopher Nielsen Date: 12/06/2012 9:31 AM (GMT-08:00) To: Matthew Huff Cc: nanog at nanog.org Subject: Re: Cogent outage? Passing normal traffic in San Jose and Ashburn. On Thu, Dec 6, 2012 at 12:11 PM, Matthew Huff wrote: > About 10 minutes ago we stopped being able to pass traffic through cogent. I de-peered us from Cogent, and everything appears > better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing anything? > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > -- Christopher Nielsen "They who can give up essential liberty for temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "The tree of liberty must be refreshed from time to time with the blood of patriots & tyrants." --Thomas Jefferson From jmillay at vermontel.com Thu Dec 6 17:50:42 2012 From: jmillay at vermontel.com (Jeremiah Millay) Date: Thu, 6 Dec 2012 17:50:42 +0000 Subject: Cogent outage? In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> Message-ID: <1BCAAB14D63EE94BB4D367020193DDB608EE6598@VTELMAIL.vermonttel.com> We just disabled our peering with Cogent in Boston and things have improved. We still have peering with them established in NYC (60 Hudson). Jeremiah Millay Network Engineer Vermont Telephone Co., Inc. Phone: 802 885-7796 Mobile: 802 289-2116 E-Mail: jmillay at vermontel.com -----Original Message----- From: Michael Proto [mailto:mike at jellydonut.org] Sent: Thursday, December 06, 2012 12:31 PM To: Matthew Huff Cc: nanog at nanog.org Subject: Re: Cogent outage? I'm seeing packet loss between my Atlanta Cogent connection and some servers we have in both Dallas and London. According to Cogent's status page they're having an outage in the NYC area. -Proto http://status.cogentco.com/ On Thu, Dec 6, 2012 at 12:11 PM, Matthew Huff wrote: > About 10 minutes ago we stopped being able to pass traffic through > cogent. I de-peered us from Cogent, and everything appears better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing anything? > > ---- > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff | Fax: 914-460-4139 > > From ekim.ittag at gmail.com Thu Dec 6 17:51:21 2012 From: ekim.ittag at gmail.com (Mike Gatti) Date: Thu, 6 Dec 2012 09:51:21 -0800 Subject: Solutions for DoS & DDoS Message-ID: <0D89D80C-D288-402F-8723-B837EA52313C@gmail.com> Hello Everyone, I'm assisting a non-profit organization to research solutions to secure their network from DOS/DDOS attacks. So far we have gone the route of discussing with their ISP's to see what solutions they have to offer, believing that the carriers are better positioned to block the attack from the source. I wanted to get the lists thoughts on our approach going the carrier route and/or hear about successful implementation of other solutions. Thanks, -- Michael Gatti 949.371.5474 (UTC -8) From frnkblk at iname.com Thu Dec 6 19:08:50 2012 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 6 Dec 2012 13:08:50 -0600 Subject: Streaming video traffic increase from Level3? In-Reply-To: <008801cdd36e$9e577f10$db067d30$@iname.com> References: <008801cdd36e$9e577f10$db067d30$@iname.com> Message-ID: <006b01cdd3e5$2090e270$61b2a750$@iname.com> We think we found out the source of usage -- the local college's Men's Volleyball team played last night against the neighboring (rival) school. The local college's streams are fixed at 1.5 Mbps, so you just need a few people watching to make it add up in hurry. That would explain the usage and why we saw the traffic as streaming video. Sorry for the noise, Frank -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Wednesday, December 05, 2012 11:01 PM To: nanog at nanog.org Subject: Streaming video traffic increase from Level3? This evening I saw a quadruple increase in traffic volume from Level3 address space, a one-third increase in peak streaming video usage overall, and when I did a few checks with our netflow tool, it looks like customers that were streaming Netflix content just days before are now getting it out of Level3 space rather than our local cache or our upstream provider's Netflix cache. We also exceeded our previous peak usage by 12%. Did something change with Netflix that would have resulted in greater usage? Did Netflix defaults change so that customers are now using HD, or a higher-rate bitrate HD? Frank From SNaslund at medline.com Thu Dec 6 19:17:22 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 6 Dec 2012 13:17:22 -0600 Subject: China Telecom VPN problems (again) In-Reply-To: <34501.1354738262@turing-police.cc.vt.edu> References: <8200F04ED2C5EF40B246388AD4B822A512D5DF04@BL2PRD0512MB662.namprd05.prod.outlook.com> , <34501.1354738262@turing-police.cc.vt.edu> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D89DA04@MUNEXBE1.medline.com> Make sure you check this out in detail. My export / import people found out that if the device is going to be in control of and used by a US company doing business in China, there are a lot less encryption restrictions. The ruling was that it was not an export if the device remains the property of and in control of a US company. The thought is that they want US companies to be able to secure their own VPN traffic. There are also apparently some key escrow rules whereby you are supposed to give the Chinese government your keys. I am told by US gov't employee that almost no one does that and the Chinese government makes it a point not to hassle US companies. Your mileage may vary and I am not an import / export expert. Steven Naslund -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Wednesday, December 05, 2012 2:11 PM To: Warren Bailey Cc: nanog at nanog.org Subject: Re: China Telecom VPN problems (again) On Wed, 05 Dec 2012 19:48:31 +0000, Warren Bailey said: > Since when is heavy encryption cool in China? Export restrictions > smoke all of the decent crypto options. OK, I'll bite.. What crypto options are getting stuck due to export restrictions (as opposed to import restrictions on the other end)? From SNaslund at medline.com Thu Dec 6 19:21:40 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 6 Dec 2012 13:21:40 -0600 Subject: China Telecom VPN problems (again) In-Reply-To: References: <8200F04ED2C5EF40B246388AD4B822A512D5DF04@BL2PRD0512MB662.namprd05.prod.outlook.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D89DA10@MUNEXBE1.medline.com> Agreed. I have run IPsec over MPLS with no problem in China on several carriers. Internet connectivity also worked but performance was spotty due to overloaded firewall or circuits in and out of the country. Steven Naslund -----Original Message----- From: Tom Paseka [mailto:tom at cloudflare.com] Sent: Wednesday, December 05, 2012 1:27 PM To: Christopher Morrow Cc: nanog at nanog.org Subject: Re: China Telecom VPN problems (again) On Wed, Dec 5, 2012 at 11:25 AM, Christopher Morrow wrote: > On Wed, Dec 5, 2012 at 2:19 PM, Tom Paseka wrote: > > Its quite easy to get MPLS-VPN connectivity into China (Pacnet, > > Singtel, CPCNet, etc, will offer), but at a price. > > mpls != ipsec ... perhaps the OP wants some privacy and authentication > and such? run IPSEC over the MPLS-VPN. It'll be a lot more stable than over public internet. From SNaslund at medline.com Thu Dec 6 19:24:26 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 6 Dec 2012 13:24:26 -0600 Subject: China Telecom VPN problems (again) In-Reply-To: References: <8200F04ED2C5EF40B246388AD4B822A512D5DF04@BL2PRD0512MB662.namprd05.prod.outlook.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D89DA16@MUNEXBE1.medline.com> There are lots of carriers but unfortunately they all seem to use China Telecom infrastructure for transport so there is not really a way to get better Internet service there. In our experience MPLS performs better because China Telecom seems to hand off service to the international MPLS carriers before the big Internet bottleneck. Steven Naslund -----Original Message----- From: Christopher Morrow [mailto:morrowc.lists at gmail.com] Sent: Wednesday, December 05, 2012 1:25 PM To: Tom Paseka Cc: nanog at nanog.org Subject: Re: China Telecom VPN problems (again) On Wed, Dec 5, 2012 at 2:19 PM, Tom Paseka wrote: > Its quite easy to get MPLS-VPN connectivity into China (Pacnet, > Singtel, CPCNet, etc, will offer), but at a price. mpls != ipsec ... perhaps the OP wants some privacy and authentication and such? > > Suzhou and Shenzhen are easily in reach of all the above listed providers. > > On Wed, Dec 5, 2012 at 7:50 AM, Warren Bailey < > wbailey at satelliteintelligencegroup.com> wrote: > >> We tried to get our VPN work from the China Telecom/China Unicom >> beijing POP for over a year. The Chinese always claimed it was >> kosher, but we had something like 60%+ loss across our 4 hop VPN for >> the entirety of the project. Private circuits don't really exist on >> the mainland, HK and >> (maybe) Shanghai are about the only places for decent connectivity. >> :/ >> >> On 12/5/12 7:38 AM, "Suresh Ramasubramanian" wrote: >> >> >It's called the great firewall of china. Feel free to shift vendors >> >but it won't help. >> > >> >Meanwhile make sure none of your users are surfing for falun gong, >> >dalai lama, ai weiwei or whoever else the chicom censors don't like >> >on that particular day >> > >> >On Wednesday, December 5, 2012, Thomas York wrote: >> > >> >> It looks like I'm having China Telecom issues yet again. They're >> >>batting down our SSL VPN tunnels. Switching ports doesn't help. >> >>Tunneling the SSL tunnel inside of another tunnel doesn't help. At >> >>this point I'm tired of listening to the screaming by the business >> >>users. Can someone contact me (here or off-list, I don't care) >> >>about circuits in China so that we don't have to use China >> >>Telecom? We'd only need 2-10 Mbit and Ethernet hand off. >> >> We don't need BGP or MPLS or anything remotely fancy. Our main >> >>concern is getting connectivity to the business district in >> >>Suzhou, but it'd be nice if we could also use the same carrier in >> >>Shenzhen. >> >> >> >> >> >> >> >> Thanks! >> >> >> >> >> >> >> >> -- Thomas York >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >-- >> >--srs (iPad) >> > >> >> >> >> From SNaslund at medline.com Thu Dec 6 19:30:32 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 6 Dec 2012 13:30:32 -0600 Subject: How to get DID local numbers (IP Telephony) In-Reply-To: <1354658615.602855857@f341.mail.ru> References: <1354658615.602855857@f341.mail.ru> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D89DA37@MUNEXBE1.medline.com> You can get DID numbers from a carrier when you buy a service from them. There is usually a ratio of how many DIDs you can get for a certain service. I know you will need state utilities commission licenses at least if you want to become a telephone carrier. IP only voice service I am not sure about, could be considered a data service but I think if you are handing out DOD numbers, you are a phone carrier. There is a lot of regulatory stuff for utilities in the US. A lot more than can be explained here. Involves lots of taxes, law enforcement access, insurance, 911 communications, etc. There is probably no more regulated business in the US than communications. Steven Naslund -----Original Message----- From: ?????? ???????? [mailto:mentax at bk.ru] Sent: Tuesday, December 04, 2012 4:04 PM To: nanog at nanog.org Subject: How to get DID local numbers (IP Telephony) Hi there, Can someone explain me how can I get an block of DID (Telephony numbers)? For example I need 200 numbers. Is that special organization or I must buy it somewhere? What the rule for USA (NY) about telephony providing ? Should I have a licence to sale ip telephony? Thanks.? From derek at derekivey.com Thu Dec 6 19:48:13 2012 From: derek at derekivey.com (Derek Ivey) Date: Thu, 6 Dec 2012 14:48:13 -0500 Subject: How to get DID local numbers (IP Telephony) In-Reply-To: <1354658615.602855857@f341.mail.ru> References: <1354658615.602855857@f341.mail.ru> Message-ID: <7418B62C-6DDF-4776-AFB4-67C4A53E932D@derekivey.com> If you're looking to use SIP, I've had a good experience with Flowroute.com. I got one of my customers a block of 20 DIDs from them. Flowroute had to order the block from the CLEC in their area code and it took about two weeks. Derek On Dec 4, 2012, at 5:03 PM, ?????? ???????? wrote: > > > > > > > Hi there, > > Can someone explain me how can I get an block of DID (Telephony numbers)? For example I need 200 numbers. Is that special organization or I must buy it somewhere? > What the rule for USA (NY) about telephony providing ? Should I have a licence to sale ip telephony? > > Thanks. > > > > > > From SNaslund at medline.com Thu Dec 6 19:54:40 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 6 Dec 2012 13:54:40 -0600 Subject: Six Strike Rule (Was: William was raided...) In-Reply-To: <20671.33466.67561.33898@world.std.com> References: <20121203071911.GA2160@nike.aronius.se> <201212030822.qB38MsPx072907@aurora.sol.net> <20121203113102.GA24383@gsp.org> <50BD0133.6090509@viviotech.net> <50BE2D01.5030100@unfix.org> <20671.33466.67561.33898@world.std.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0D89DA90@MUNEXBE1.medline.com> If you are a facilities based broadband provider in the US you have to comply with CALEA. There is no "coming to some agreement", you have a legal obligation to comply. No more, and no less. You don't have to comply with requests from agencies other than law enforcement under CALEA but you may need to under other requirements such as DMCA. You should know what the minimum legal requirements are and if you don't want to do more than that, fine. However, you could get a court order telling you to do almost anything and it would be expensive and potentially put you in contempt not to comply with them. I am not a lawyer but dealt with these requirements for years on the job. Steven Naslund -----Original Message----- From: Barry Shein [mailto:bzs at world.std.com] Sent: Wednesday, December 05, 2012 11:22 AM To: nanog at nanog.org Subject: Re: Six Strike Rule (Was: William was raided...) On December 4, 2012 at 11:10 jason at thebaughers.com (Jason Baugher) wrote: > We don't do content inspection. We don't really want to know what our > customers are doing, and even if we did, there's not enough time in the day > to spend paying attention. When we get complaints from the various > copyright agencies, we warn the customer to stop. When we hit a certain > number of complaints, its bye-bye customer. This is why there's a need for some sort of reasonable, organized response outlined in writing. In my experience law enforcement (and others) will try to shift whatever investigative tasks are convenient to them to anyone in the loop. Why not, it costs them nothing to have you running around all day and night doing investigative work for them. They will generally cite the seriousness of the underlying crime as (bottomless) justification for your contribution. The rational response is to sit down as a group within some framework and come to some agreement* with them as to what is a reasonable and sufficient response in these cases. Otherwise you're just the complaint desk at Macy's taking all comers and subject to whatever they can dream up to try to get you to solve their problems. * Agreement with LEOs is best, a unilateral document would at least open discussion one would hope and move towards that end. -- -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 jra at baylink.com Thu Dec 6 20:10:19 2012 From: jra at baylink.com (Jay Ashworth) Date: Thu, 6 Dec 2012 15:10:19 -0500 (EST) Subject: How to get DID local numbers (IP Telephony) In-Reply-To: <1354658615.602855857@f341.mail.ru> Message-ID: <7761921.37942.1354824619805.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "?????? ????????" > Can someone explain me how can I get an block of DID (Telephony > numbers)? For example I need 200 numbers. Is that special organization > or I must buy it somewhere? > What the rule for USA (NY) about telephony providing ? Should I have a > licence to sale ip telephony? DID numbers are actually E.164 addresses, which are relevant in the context of the IPSTN. Because they are addresses on a specific network, in order to have some assigned to you, you need to have a connection to that network. Generally, that connection is either via SIP+RTP over IP to a VoIP gateway provider, who in turn connects to the PSTN using PRI trunks to their supplier's switch, or who is themselves the operator of a switch which is connected to the PSTN by SS7... or you yourself do one of those two things, in (very) roughly increasing order of cost. We'll assume for the moment, that you do not want to become a CLEC. (The rest of this message is even more USAdian than the first part.) To get DID numbers in a given area, you need to purchase connectivity service from a telco or gateway provider with physical facilities in that area. On the VoIP side, it's common for the "DID" to be the actual thing you purchase, and the transport and minutes (if any) come along with it. If you're buying a local PRI circuit to a local RBOC/CLEC, then "blocks" of DID's are something you buy at extra cost, and you tell the telco how to group the channels on your PRIs, and which DIDs to route to which trunkgroups. In both cases, outbound-only service is possible to buy, so the DID(s) are actually optional. In short, though, if you have physical gear in the US somewhere, you can buy a PRI and put DIDs on it; if you don't, you can contract with one or more VoIP providers who do, and backhaul the traffic that way. If you ever decide you have to switch the DIDs to a different carrier, you will find that this is easier and harder depending on whom you're working with; I don't think there's a rule. Did that help? 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 James.S.Harris at techdata.com Thu Dec 6 20:00:08 2012 From: James.S.Harris at techdata.com (Harris, James (IT)) Date: Thu, 6 Dec 2012 20:00:08 +0000 Subject: Cogent outage? In-Reply-To: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F901AAC1413F3D@PUR-EXCH07.ox.com> Message-ID: <02FA0319C8FB234B830154004555E59C551ECA4E@USCLWEMBX04.us.tdworldwide.com> Seeing 25% packet lost between Tampa and Munich at 19:59 UTC James Harris 727-571-9328 -----Original Message----- From: Matthew Huff [mailto:mhuff at ox.com] Sent: Thursday, December 06, 2012 12:12 PM To: 'nanog at nanog.org' Subject: Cogent outage? About 10 minutes ago we stopped being able to pass traffic through cogent. I de-peered us from Cogent, and everything appears better. When I call cogent, all I get is a busy signal (must be a major outage). Anyone else seeing anything? ---- Matthew Huff? | 1 Manhattanville Rd Director of Operations???| Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 From bill at herrin.us Thu Dec 6 20:49:51 2012 From: bill at herrin.us (William Herrin) Date: Thu, 6 Dec 2012 15:49:51 -0500 Subject: Online/double-conversion UPS economy/high efficiency modes? Message-ID: Hi folks, I'm looking at several brands of rackmount 3kva double-conversion UPSes, such as Tripp Lite and Eaton Powerware. I'm specifically looking for something that will work as a line-interactive UPS until the power starts to misbehave and will then switch to double-conversion mode until a while after the last power bump. Basically I want the best of both worlds: save money on my power bill most of the time (double-conversion UPSes generally waste 10%-15% of the consumed kilowatt hours) but switch to nice clean double-conversion when the storms roll through and the power gets rough. Here's where I'm looking for help: the vendor web sites have scanty details about how the UPSes behave in their high efficiency modes. I'm hoping folks here have used some of the UPSes with this feature and can offer feedback. When does the UPS decide to switch to double-conversion? When does it decide to switch back? Are the options tunable? Through what interface? Can I write software that monitors a weather report and sends an SNMP message to switch the UPS to double conversion mode ahead of a storm? Eaton's 9130 says "On the High Efficiency setting, the UPS operates normally on Bypass, transfers to inverter in less than 10 ms when utility fails, and transfers back to Bypass in 1 minute after utility returns. The indicator illuminates when the UPS transfers to Bypass." http://lit.powerware.com/ll_download.asp?file=Eaton%209130%20UPS.pdf Tripp Lite's SU3000RTXL3U only says "If the UPS has been placed into Economy Mode (available on select UPS systems), it configures an online UPS to function as a switching UPS. When the UPS system is in Economy Mode, it operates at increased efficiency while AC utility power is available (within +/- 10% nominal) and switches to battery power if AC utility power is interrupted." http://www.tripplite.com/shared/techdoc/Owners-Manual/932471.pdf What others should I consider? Can anyone offer details? Thanks, Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From angst1974 at yahoo.com Thu Dec 6 20:53:07 2012 From: angst1974 at yahoo.com (Steve) Date: Thu, 6 Dec 2012 15:53:07 -0500 Subject: Solutions for DoS & DDoS In-Reply-To: References: Message-ID: The ideal solution is a carrier that has its own true DDoS mitigation platform, and does not rely on black hole routing . Have the carrier handle the the large bulk flood attacks, then have your own prem base mitigation platform take care of the more application specific attacks that get through . This represents the best solution , and also the most expensive . So it may not work for a non profit. This Email was sent from Steve's iPad > Message: 4 > Date: Thu, 6 Dec 2012 09:51:21 -0800 > From: Mike Gatti > To: NANOG list > Subject: Solutions for DoS & DDoS > Message-ID: <0D89D80C-D288-402F-8723-B837EA52313C at gmail.com> > Content-Type: text/plain; charset=us-ascii > > Hello Everyone, > > I'm assisting a non-profit organization to research solutions to secure their network from DOS/DDOS attacks. So far we have gone the route of discussing with their ISP's to see what solutions they have to offer, believing that the carriers are better positioned to block the attack from the source. > > I wanted to get the lists thoughts on our approach going the carrier route and/or hear about successful implementation of other solutions. > > Thanks, > -- > Michael Gatti > 949.371.5474 > (UTC -8) > > > > > > > ------------------------------ > > > End of NANOG Digest, Vol 59, Issue 24 > ************************************* From l-nanog at iodi.se Thu Dec 6 21:08:53 2012 From: l-nanog at iodi.se (Joseph Chin) Date: Thu, 6 Dec 2012 21:08:53 -0000 Subject: Solutions for DoS & DDoS In-Reply-To: <0D89D80C-D288-402F-8723-B837EA52313C@gmail.com> References: <0D89D80C-D288-402F-8723-B837EA52313C@gmail.com> Message-ID: <06ef01cdd3f5$e6892bd0$b39b8370$@iodi.se> Is the cause of this non-profit a controversial one with a good likelihood of attracting the attention of demographics with the ability to mount DDoS attacks? If your upstream can do it for a good price (on account of being a non-profit organization) and they have lots of bandwidth along with a decent stack of mitigation gear, and some clue on how to operate them, then that should be the first choice. But DDoS mitigation is not their core business, so be prepared for them to blackhole your IP if things get difficult. Make sure your SLA is as bulletproof as possible or at least understand how bad things can get before they bail out on you. If the asset you want to protect is on standard web ports (ie 80 and 443) and is a likely DDoS target (per my first question), then one of the affordable DDoS-Mitigation-as-a-Service (DMaaS) providers would be a better fit for the task. Your upstream will appreciate not becoming collateral victim of the attack traffic. My good friend (who was also a co-founder of Peer1) founded dosarrest.com. They seem to be quite successful and have protected some high profile customers, so feel free to give them a call. If the non-profit is in the high risk of attack profile (ie any cause that is likely to offend techno-savvy bullies or religious fanatics), then you should talk to Prolexic/Verisign/Neustar/NexusGuard. If you are in the high risk category and you cause is that of free-speech, maybe the good folks at virtualroad.org (with help from Prolexic) can help. Regards, Joe -----Original Message----- From: Mike Gatti [mailto:ekim.ittag at gmail.com] Sent: Thursday, December 06, 2012 5:51 PM To: NANOG list Subject: Solutions for DoS & DDoS Hello Everyone, I'm assisting a non-profit organization to research solutions to secure their network from DOS/DDOS attacks. So far we have gone the route of discussing with their ISP's to see what solutions they have to offer, believing that the carriers are better positioned to block the attack from the source. I wanted to get the lists thoughts on our approach going the carrier route and/or hear about successful implementation of other solutions. Thanks, -- Michael Gatti 949.371.5474 (UTC -8) From joly at punkcast.com Thu Dec 6 21:16:19 2012 From: joly at punkcast.com (Joly MacFie) Date: Thu, 6 Dec 2012 16:16:19 -0500 Subject: Solutions for DoS & DDoS In-Reply-To: <0D89D80C-D288-402F-8723-B837EA52313C@gmail.com> References: <0D89D80C-D288-402F-8723-B837EA52313C@gmail.com> Message-ID: By coincidence we have just published the video archive of our "Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape" event last Wednesday. It's at http://youtu.be/FR0660X9lGc We'll have a full transcript up early next week. j On Thu, Dec 6, 2012 at 12:51 PM, Mike Gatti wrote: > Hello Everyone, > > I'm assisting a non-profit organization to research solutions to secure > their network from DOS/DDOS attacks. So far we have gone the route of > discussing with their ISP's to see what solutions they have to offer, > believing that the carriers are better positioned to block the attack from > the source. > > I wanted to get the lists thoughts on our approach going the carrier route > and/or hear about successful implementation of other solutions. > > Thanks, > -- > Michael Gatti > 949.371.5474 > (UTC -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 mike-nanog at tiedyenetworks.com Thu Dec 6 21:16:53 2012 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 06 Dec 2012 13:16:53 -0800 Subject: Online/double-conversion UPS economy/high efficiency modes? In-Reply-To: References: Message-ID: <50C10B45.20400@tiedyenetworks.com> On 12/06/2012 12:49 PM, William Herrin wrote: > Hi folks, > > I'm looking at several brands of rackmount 3kva double-conversion > UPSes, such as Tripp Lite and Eaton Powerware. I'm specifically > looking for something that will work as a line-interactive UPS until > the power starts to misbehave and will then switch to > double-conversion mode until a while after the last power bump. > I recently went to the tripplite 16kva online double conversion ups and did note the increased ineffeciency. However, the financial cost of that ineffeciency doesn't appear to be more than $40 - $60 / mo. So I am wondering at your scale with only a 3kva model, really, what is the final dollar cost to you versus the effort and dubious benefits of writing scripts or depending on embedded logic to do the right thing? The whole reason you have online double conversion vs line interactive, is to have the best available protection, and when you are on line interactive - even if it can switch - you are still taking that risk of power issues that will jump your ups and hit your connected equipment anyways. Mike- From michael.bubb at gmail.com Thu Dec 6 21:09:30 2012 From: michael.bubb at gmail.com (Michael Bubb) Date: Thu, 6 Dec 2012 16:09:30 -0500 Subject: Cogent outage? Message-ID: We got a notice from Internap a few hours ago: "At approximately 12:10 EST Internap shut down the BGP session with Cogent as we were widespread packet loss issues through their network out of our New York (NYM) PNAP. We are contacting Cogent to see if they are aware of what the issue is. " They have not as yet updated this yrs Michael -- Michael Bubb +1.646.783.8769 https://www.google.com/profiles/michael.bubb "The first principle is that you must not fool yourself--and you are the easiest person to fool." - Richard Feynman All things are a flowing, Sage Heraclitus says; But a tawdry cheapness Shall reign throughout our days. - Pound From johnl at iecc.com Thu Dec 6 21:30:48 2012 From: johnl at iecc.com (John Levine) Date: 6 Dec 2012 21:30:48 -0000 Subject: =?UTF-8?B?SG93IHRvIGdldCBESUQgbG9jYWwgbnVtYmVycyAgKElQIFRlbGVwaG9ueSk=?= In-Reply-To: <1354658615.602855857@f341.mail.ru> Message-ID: <20121206213048.10399.qmail@joyce.lan> >Can someone explain me how can I get an block of DID (Telephony numbers)? As I think recent messages have shown, it's not possible to provide a useful answer unless you give us some hint about what you want to do with the traffic from those numbers. If you want to deliver it via SIP over the public Internet, there's a set of specialist vendors like Voxbone. If you want to route it via dedicated trunks such as PRIs to a server physically located in the area where to which the DIDs are assigned, you should talk to a CLEC (or whatever they're called in other countries.) If you want to do something else, well what is it? From blair.trosper at gmail.com Thu Dec 6 21:36:12 2012 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 6 Dec 2012 15:36:12 -0600 Subject: Cogent outage? In-Reply-To: References: Message-ID: We've seen BGP resets on our servers in Tampa...with Cogent no longer being the preferred route for outgoing traffic. The preferred path from out DC is now through Hurricane (AS6939). Blair Trosper Updraft Networks & LEARN (North Texas GigaPOP) On Thu, Dec 6, 2012 at 3:09 PM, Michael Bubb wrote: > We got a notice from Internap a few hours ago: > > > "At approximately 12:10 EST Internap shut down the BGP session with Cogent > as we were widespread packet loss issues through their network out of our > New York (NYM) PNAP. > > We are contacting Cogent to see if they are aware of what the issue is. " > > > They have not as yet updated this > > yrs > > Michael > > -- > Michael Bubb +1.646.783.8769 > https://www.google.com/profiles/michael.bubb > > "The first principle is that you must not fool yourself--and you are the > easiest person to fool." - Richard Feynman > > All things are a flowing, > Sage Heraclitus says; > But a tawdry cheapness > Shall reign throughout our days. - Pound > From e.sorge at gmail.com Thu Dec 6 21:37:01 2012 From: e.sorge at gmail.com (Enrico Sorge) Date: Thu, 6 Dec 2012 22:37:01 +0100 Subject: Amazon Abuse contact In-Reply-To: <50BE7BDE.9020901@viviotech.net> References: <50BE7BDE.9020901@viviotech.net> Message-ID: http://aws.amazon.com/security/vulnerability-reporting/ On Tue, Dec 4, 2012 at 11:40 PM, Mark Keymer wrote: > Hi, > > If there is a Amazon Abuse person our there or if someone has a good > contact to someone at Amazon can you message me off-list. > > We have put in some Abuse request a couple of days ago and have not heard > back. It would be great to talk with someone about an issue effecting one > of our clients and the use of Amazon. (Cloud instances I believe) > > Thank you in advance. > > Sincerely, > > -- > Mark Keymer > CFO/COO > Vivio Technologies > 509-593-4207 x1002 > > > From l-nanog at iodi.se Thu Dec 6 21:41:04 2012 From: l-nanog at iodi.se (Joseph Chin) Date: Thu, 6 Dec 2012 21:41:04 -0000 Subject: Online/double-conversion UPS economy/high efficiency modes? In-Reply-To: <50C10B45.20400@tiedyenetworks.com> References: <50C10B45.20400@tiedyenetworks.com> Message-ID: <06f901cdd3fa$65e40720$31ac1560$@iodi.se> That is so old-school FUD re line-interactive vs double-conversion. Very much the tubeless vs tubed tire debate all over again. Buy well-engineered quality brand products (ie Emerson/Liebert, Schneider/APC) then it will be a non-issue. -----Original Message----- From: Mike [mailto:mike-nanog at tiedyenetworks.com] Sent: Thursday, December 06, 2012 9:17 PM To: nanog at nanog.org Subject: Re: Online/double-conversion UPS economy/high efficiency modes? On 12/06/2012 12:49 PM, William Herrin wrote: > Hi folks, > > I'm looking at several brands of rackmount 3kva double-conversion > UPSes, such as Tripp Lite and Eaton Powerware. I'm specifically > looking for something that will work as a line-interactive UPS until > the power starts to misbehave and will then switch to > double-conversion mode until a while after the last power bump. > I recently went to the tripplite 16kva online double conversion ups and did note the increased ineffeciency. However, the financial cost of that ineffeciency doesn't appear to be more than $40 - $60 / mo. So I am wondering at your scale with only a 3kva model, really, what is the final dollar cost to you versus the effort and dubious benefits of writing scripts or depending on embedded logic to do the right thing? The whole reason you have online double conversion vs line interactive, is to have the best available protection, and when you are on line interactive - even if it can switch - you are still taking that risk of power issues that will jump your ups and hit your connected equipment anyways. Mike- From michael.bubb at gmail.com Thu Dec 6 21:45:04 2012 From: michael.bubb at gmail.com (Michael Bubb) Date: Thu, 6 Dec 2012 16:45:04 -0500 Subject: Cogent outage? In-Reply-To: References: Message-ID: Internap just updated: Cogent has said that the issue they were having has been resolved. Internap's BGP session was turned back up at approximately 15:45 EST and traffic has been stable since that time. On Thu, Dec 6, 2012 at 4:36 PM, Blair Trosper wrote: > We've seen BGP resets on our servers in Tampa...with Cogent no longer > being the preferred route for outgoing traffic. The preferred path from > out DC is now through Hurricane (AS6939). > > Blair Trosper > Updraft Networks & LEARN (North Texas GigaPOP) > > > On Thu, Dec 6, 2012 at 3:09 PM, Michael Bubb wrote: > >> We got a notice from Internap a few hours ago: >> >> >> "At approximately 12:10 EST Internap shut down the BGP session with Cogent >> as we were widespread packet loss issues through their network out of our >> New York (NYM) PNAP. >> >> We are contacting Cogent to see if they are aware of what the issue is. " >> >> >> They have not as yet updated this >> >> yrs >> >> Michael >> >> -- >> Michael Bubb +1.646.783.8769 >> https://www.google.com/profiles/michael.bubb >> >> "The first principle is that you must not fool yourself--and you are the >> easiest person to fool." - Richard Feynman >> >> All things are a flowing, >> Sage Heraclitus says; >> But a tawdry cheapness >> Shall reign throughout our days. - Pound >> > > -- Michael Bubb +1.646.783.8769 https://www.google.com/profiles/michael.bubb "The first principle is that you must not fool yourself--and you are the easiest person to fool." - Richard Feynman All things are a flowing, Sage Heraclitus says; But a tawdry cheapness Shall reign throughout our days. - Pound From alex at corp.nac.net Thu Dec 6 21:46:22 2012 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 6 Dec 2012 16:46:22 -0500 Subject: Online/double-conversion UPS economy/high efficiency modes? In-Reply-To: <50C10B45.20400@tiedyenetworks.com> References: <50C10B45.20400@tiedyenetworks.com> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB81BEF4789BE@EXCHMBX.hq.nac.net> > > I'm looking at several brands of rackmount 3kva double-conversion > > UPSes, such as Tripp Lite and Eaton Powerware. I'm specifically > > looking for something that will work as a line-interactive UPS until > > the power starts to misbehave and will then switch to > > double-conversion mode until a while after the last power bump. Not entirely the topic asked, but we have good experience doing this at the 500 kva module level. We are using the 'eBoost' method from GE, which is more or less what you ask for. It keeps the inverter and rectifier alive and energized, but current flow is via the bypass static switch. We have used this for about a year or so now, and even including hurricane sandy craziness, have seen in excess of 98% usage of eBoost. When in that mode, system efficiency jumps from about 92% to 99.8% efficient. A huge savings per 500 kva / 450 kw. 450 kw * 24h * 30d * 7.8% increase in efficiency is 25,272 kw-hrs saved per month, or at $0.12/kw-hr is $3,032/month/450 kw of load. The point is that it works, works well, and is green. http://www.gedigitalenergy.com/products/brochures/PowerQuality/brochure-eBoost-GEA-D1050-GB.pdf To this point: > even if it can switch - you are still taking that risk of power issues that will > jump your ups and hit your connected equipment anyways. If the overall power system is designed correctly, this should never be an issue. We did pretty extensive testing on this. I don't know if anyone does this at the very-small level. I know GE's smallest unit is 300 kva for eBoost. "Question everything, assume nothing, discuss all, and resolve quickly." -- Alex Rubenstein, AR97, K2AHR, alex at nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- From sethm at rollernet.us Thu Dec 6 22:19:31 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 06 Dec 2012 14:19:31 -0800 Subject: Online/double-conversion UPS economy/high efficiency modes? In-Reply-To: References: Message-ID: <50C119F3.9030005@rollernet.us> On 12/6/12 12:49 PM, William Herrin wrote: > Hi folks, > > I'm looking at several brands of rackmount 3kva double-conversion > UPSes, such as Tripp Lite and Eaton Powerware. I'm specifically > looking for something that will work as a line-interactive UPS until > the power starts to misbehave and will then switch to > double-conversion mode until a while after the last power bump. > > Basically I want the best of both worlds: save money on my power bill > most of the time (double-conversion UPSes generally waste 10%-15% of > the consumed kilowatt hours) but switch to nice clean > double-conversion when the storms roll through and the power gets > rough. > > Here's where I'm looking for help: the vendor web sites have scanty > details about how the UPSes behave in their high efficiency modes. I'm > hoping folks here have used some of the UPSes with this feature and > can offer feedback. > > When does the UPS decide to switch to double-conversion? When does it > decide to switch back? Are the options tunable? Through what > interface? Can I write software that monitors a weather report and > sends an SNMP message to switch the UPS to double conversion mode > ahead of a storm? > > > Eaton's 9130 says "On the High Efficiency setting, the UPS operates > normally on Bypass, transfers to inverter in less than 10 ms when > utility fails, and transfers back to Bypass in 1 minute after utility > returns. The indicator illuminates when the UPS transfers to Bypass." > http://lit.powerware.com/ll_download.asp?file=Eaton%209130%20UPS.pdf > I have a 700VA 9130 rackmount that I recently bought to give it an eval run (although the first was a dud). There is a 3kVA model. For my small load it reports a PF of 0.91 online. It is selectable between normal and high efficiency mode through the front panel. I would assume the tolerance settings in there related to bypass availability would trigger online mode. If it does kick over to online from high efficiency bypass it'll stay there for a minute to watch for stability before going back. The network card (Network Card-MS) is extremely sparse in being able to configure it remotely. It's mainly just for status. It does not have an option in the web interface to toggle the mode or change the bypass tolerance settings, however, there is a MIB object for "power strategy" that says it's read-write but I haven't tried writing to it yet. I guess I can try it and report back. ~Seth From jmaimon at ttec.com Thu Dec 6 22:31:21 2012 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 06 Dec 2012 17:31:21 -0500 Subject: Verizon ISP ATM ports Message-ID: <50C11CB9.9010006@ttec.com> Hey All, Its that time of the year again, and I am looking for verizon ATM/DSL wholesale DSL ports for NY/NJ latas. Off-list replies are welcome. Thanks, Joe From otis at ocosa.com Thu Dec 6 23:09:26 2012 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Thu, 6 Dec 2012 17:09:26 -0600 Subject: Google Fiber - keeps you regular In-Reply-To: <50c081d7.0xwaJdqoLgLNIuML%ops.lists@gmail.com> References: <50c081d7.0xwaJdqoLgLNIuML%ops.lists@gmail.com> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B018002@ocsbs.ocosa.com> Why does the youtube video link lead back to their Fiber Internet/TV offering? Maybe I'm lost but the video is about a Google Fiber Bar right? Otis -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] Sent: Thursday, December 06, 2012 5:31 AM To: nanog at nanog.org Subject: Google Fiber - keeps you regular http://www.youtube.com/watch?v=re0VRK6ouwI&feature=share you'll probably laugh so hard you won't even need the fiber From ops.lists at gmail.com Thu Dec 6 23:35:34 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 7 Dec 2012 05:05:34 +0530 Subject: Google Fiber - keeps you regular In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018002@ocsbs.ocosa.com> References: <50c081d7.0xwaJdqoLgLNIuML%ops.lists@gmail.com> <5FE1FB6D43B8A647BBC821840C1AEA8B018002@ocsbs.ocosa.com> Message-ID: All jokes about crappy Internet service aside, that is? On Friday, December 7, 2012, Otis L. Surratt, Jr. wrote: > Why does the youtube video link lead back to their Fiber Internet/TV > offering? > Maybe I'm lost but the video is about a Google Fiber Bar right? > > Otis > > -----Original Message----- > From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com ] > Sent: Thursday, December 06, 2012 5:31 AM > To: nanog at nanog.org > Subject: Google Fiber - keeps you regular > > Introducing the Google Fiber Bar > > you'll probably laugh so hard you won't even need the fiber > > -- --srs (iPad) From otis at ocosa.com Thu Dec 6 23:53:54 2012 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Thu, 6 Dec 2012 17:53:54 -0600 Subject: Google Fiber - keeps you regular In-Reply-To: References: <50c081d7.0xwaJdqoLgLNIuML%ops.lists@gmail.com><5FE1FB6D43B8A647BBC821840C1AEA8B018002@ocsbs.ocosa.com> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B018007@ocsbs.ocosa.com> Yep. But you know I wouldn't be surprised if Google entered that market. That's why I was asking. You never know these days. From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] Sent: Thursday, December 06, 2012 5:36 PM To: Otis L. Surratt, Jr. Cc: nanog at nanog.org Subject: Re: Google Fiber - keeps you regular All jokes about crappy Internet service aside, that is? On Friday, December 7, 2012, Otis L. Surratt, Jr. wrote: Why does the youtube video link lead back to their Fiber Internet/TV offering? Maybe I'm lost but the video is about a Google Fiber Bar right? Otis -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] Sent: Thursday, December 06, 2012 5:31 AM To: nanog at nanog.org Subject: Google Fiber - keeps you regular Introducing the Google Fiber Bar you'll probably laugh so hard you won't even need the fiber -- --srs (iPad) From ops.lists at gmail.com Fri Dec 7 00:17:50 2012 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 7 Dec 2012 05:47:50 +0530 Subject: Google Fiber - keeps you regular In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018007@ocsbs.ocosa.com> References: <50c081d7.0xwaJdqoLgLNIuML%ops.lists@gmail.com> <5FE1FB6D43B8A647BBC821840C1AEA8B018002@ocsbs.ocosa.com> <5FE1FB6D43B8A647BBC821840C1AEA8B018007@ocsbs.ocosa.com> Message-ID: If you look at www.google.com/fiber they do seem to be in that market now On Friday, December 7, 2012, Otis L. Surratt, Jr. wrote: > Yep. But you know I wouldn't be surprised if Google entered that market. > That's why I was asking. You never know these days. > > From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com ] > Sent: Thursday, December 06, 2012 5:36 PM > To: Otis L. Surratt, Jr. > Cc: nanog at nanog.org > Subject: Re: Google Fiber - keeps you regular > > All jokes about crappy Internet service aside, that is? > > On Friday, December 7, 2012, Otis L. Surratt, Jr. wrote: > Why does the youtube video link lead back to their Fiber Internet/TV > offering? > Maybe I'm lost but the video is about a Google Fiber Bar right? > > Otis > > -----Original Message----- > From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com ] > Sent: Thursday, December 06, 2012 5:31 AM > To: nanog at nanog.org > Subject: Google Fiber - keeps you regular > > Introducing the Google Fiber Bar > > you'll probably laugh so hard you won't even need the fiber > > > -- > --srs (iPad) > -- --srs (iPad) From alex at corp.nac.net Fri Dec 7 00:19:40 2012 From: alex at corp.nac.net (Alex Rubenstein) Date: Thu, 6 Dec 2012 19:19:40 -0500 Subject: Online/double-conversion UPS economy/high efficiency modes? In-Reply-To: <50C119F3.9030005@rollernet.us> References: <50C119F3.9030005@rollernet.us> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB81BEF4789EE@EXCHMBX.hq.nac.net> > I have a 700VA 9130 rackmount that I recently bought to give it an eval run > (although the first was a dud). There is a 3kVA model. For my small load it > reports a PF of 0.91 online. PF, as in power factor? That has nothing to do with UPS efficiency. From sethm at rollernet.us Fri Dec 7 00:26:50 2012 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 6 Dec 2012 16:26:50 -0800 Subject: Online/double-conversion UPS economy/high efficiency modes? In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB81BEF4789EE@EXCHMBX.hq.nac.net> References: <50C119F3.9030005@rollernet.us> <2D0AF14BA6FB334988BC1F5D4FC38CB81BEF4789EE@EXCHMBX.hq.nac.net> Message-ID: <48E493A1-2DF2-4117-8C7E-15A4551EDB49@rollernet.us> I apologize for mentioning it; thanks for taking the time to point out such data could not possibly be useful. ~Seth Sent from my iPad, please excuse my brevity. On Dec 6, 2012, at 16:19, Alex Rubenstein wrote: >> I have a 700VA 9130 rackmount that I recently bought to give it an eval run >> (although the first was a dud). There is a 3kVA model. For my small load it >> reports a PF of 0.91 online. > > PF, as in power factor? That has nothing to do with UPS efficiency. > > > From mark at viviotech.net Fri Dec 7 00:31:46 2012 From: mark at viviotech.net (Mark Keymer) Date: Thu, 06 Dec 2012 16:31:46 -0800 Subject: Amazon Abuse contact In-Reply-To: References: <50BE7BDE.9020901@viviotech.net> Message-ID: <50C138F2.6060706@viviotech.net> Thank you for everyone's help. We were contacted by Amazon today. Sincerely, Mark Keymer On 12/6/2012 1:37 PM, Enrico Sorge wrote: > http://aws.amazon.com/security/vulnerability-reporting/ > > > > > On Tue, Dec 4, 2012 at 11:40 PM, Mark Keymer > wrote: > > Hi, > > If there is a Amazon Abuse person our there or if someone has a > good contact to someone at Amazon can you message me off-list. > > We have put in some Abuse request a couple of days ago and have > not heard back. It would be great to talk with someone about an > issue effecting one of our clients and the use of Amazon. (Cloud > instances I believe) > > Thank you in advance. > > Sincerely, > > -- > Mark Keymer > CFO/COO > Vivio Technologies > 509-593-4207 x1002 > > > From erol at easydns.com Fri Dec 7 01:26:00 2012 From: erol at easydns.com (Erol Blakely) Date: Thu, 06 Dec 2012 20:26:00 -0500 Subject: Solutions for DoS & DDoS In-Reply-To: References: Message-ID: <50C145A8.2060804@easydns.com> My experience with most providers has been that null routing is the "industry standard" when a DDoS hits their network. I would suggest approaching companies who specialize in DDoS mitigation - Prolexic and Blacklotus to name two I am familiar with. These outfits may have something that works for a non-profit from a pricing point of view. Ping me off list, I deal with a few providers and may be able to point you in the right direction. /e On 2012-12-06 3:53 PM, Steve wrote: > The ideal solution is a carrier that has its own true DDoS mitigation platform, and does not rely on black hole routing . Have the carrier handle the the large bulk flood attacks, then have your own prem base mitigation platform take care of the more application specific attacks that get through . > > This represents the best solution , and also the most expensive . So it may not work for a non profit. > > This Email was sent from Steve's iPad >> Message: 4 >> Date: Thu, 6 Dec 2012 09:51:21 -0800 >> From: Mike Gatti >> To: NANOG list >> Subject: Solutions for DoS & DDoS >> Message-ID: <0D89D80C-D288-402F-8723-B837EA52313C at gmail.com> >> Content-Type: text/plain; charset=us-ascii >> >> Hello Everyone, >> >> I'm assisting a non-profit organization to research solutions to secure their network from DOS/DDOS attacks. So far we have gone the route of discussing with their ISP's to see what solutions they have to offer, believing that the carriers are better positioned to block the attack from the source. >> >> I wanted to get the lists thoughts on our approach going the carrier route and/or hear about successful implementation of other solutions. >> >> Thanks, >> -- >> Michael Gatti >> 949.371.5474 >> (UTC -8) >> >> >> >> >> >> >> ------------------------------ >> >> >> End of NANOG Digest, Vol 59, Issue 24 >> ************************************* > -- Erol Blakely easyDNS Technologies Inc. From amaged at gmail.com Fri Dec 7 03:17:52 2012 From: amaged at gmail.com (Ahmed Maged) Date: Thu, 6 Dec 2012 19:17:52 -0800 Subject: Solutions for DoS & DDoS In-Reply-To: <50C145A8.2060804@easydns.com> References: <50C145A8.2060804@easydns.com> Message-ID: The most popular solution is Arbor Clean pipes. they have different ways you can get this : http://www.arbornetworks.com/ On Thu, Dec 6, 2012 at 5:26 PM, Erol Blakely wrote: > My experience with most providers has been that null routing is the > "industry standard" when a DDoS hits their network. > > I would suggest approaching companies who specialize in DDoS mitigation - > Prolexic and Blacklotus to name two I am familiar with. These outfits may > have something that works for a non-profit from a pricing point of view. > > Ping me off list, I deal with a few providers and may be able to point you > in the right direction. > > /e > > > On 2012-12-06 3:53 PM, Steve wrote: > >> The ideal solution is a carrier that has its own true DDoS mitigation >> platform, and does not rely on black hole routing . Have the carrier handle >> the the large bulk flood attacks, then have your own prem base mitigation >> platform take care of the more application specific attacks that get >> through . >> >> This represents the best solution , and also the most expensive . So it >> may not work for a non profit. >> >> This Email was sent from Steve's iPad >> >>> Message: 4 >>> Date: Thu, 6 Dec 2012 09:51:21 -0800 >>> From: Mike Gatti >>> To: NANOG list >>> Subject: Solutions for DoS & DDoS >>> Message-ID: <0D89D80C-D288-402F-8723-**B837EA52313C at gmail.com<0D89D80C-D288-402F-8723-B837EA52313C at gmail.com> >>> > >>> Content-Type: text/plain; charset=us-ascii >>> >>> Hello Everyone, >>> >>> I'm assisting a non-profit organization to research solutions to secure >>> their network from DOS/DDOS attacks. So far we have gone the route of >>> discussing with their ISP's to see what solutions they have to offer, >>> believing that the carriers are better positioned to block the attack from >>> the source. >>> >>> I wanted to get the lists thoughts on our approach going the carrier >>> route and/or hear about successful implementation of other solutions. >>> >>> Thanks, >>> -- >>> Michael Gatti >>> 949.371.5474 >>> (UTC -8) >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> >>> >>> End of NANOG Digest, Vol 59, Issue 24 >>> *************************************** >>> >> >> > -- > Erol Blakely > easyDNS Technologies Inc. > > From kawamucho at mesh.ad.jp Fri Dec 7 08:33:04 2012 From: kawamucho at mesh.ad.jp (Seiichi Kawamura) Date: Fri, 07 Dec 2012 17:33:04 +0900 Subject: earthquake in Japan right now Message-ID: <50C1A9C0.3000604@mesh.ad.jp> FYI, another big earthquake in Japan just now. M7.3 Seiichi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From froztbyte at froztbyte.net Fri Dec 7 08:36:37 2012 From: froztbyte at froztbyte.net (JP Viljoen) Date: Fri, 7 Dec 2012 10:36:37 +0200 Subject: earthquake in Japan right now In-Reply-To: <50C1A9C0.3000604@mesh.ad.jp> References: <50C1A9C0.3000604@mesh.ad.jp> Message-ID: <9A78D41B-A5C3-4A41-A242-96292E19BF16@froztbyte.net> On 07 Dec 2012, at 10:33 AM, Seiichi Kawamura wrote: > FYI, another big earthquake in Japan just now. M7.3 Inland or coast? From acaruso at mre-consulting.com Fri Dec 7 08:37:01 2012 From: acaruso at mre-consulting.com (Caruso, Anthony) Date: Fri, 7 Dec 2012 08:37:01 +0000 Subject: earthquake in Japan right now In-Reply-To: <50C1A9C0.3000604@mesh.ad.jp> References: <50C1A9C0.3000604@mesh.ad.jp> Message-ID: <97485DEF-C5B5-434A-AA32-6809B66182CA@mre-consulting.com> I just heard the same thing on the radio. Tsunami warnings are also in effect. God speed to all in the path. -T On Dec 7, 2012, at 2:33 AM, "Seiichi Kawamura" wrote: > FYI, another big earthquake in Japan just now. M7.3 > > Seiichi > ________________________________ This email message and any attachments are for the sole use of the intended recipient(s) and contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments. From adrian at changeover.za.net Fri Dec 7 08:37:56 2012 From: adrian at changeover.za.net (Adrian Moisey) Date: Fri, 7 Dec 2012 10:37:56 +0200 Subject: earthquake in Japan right now In-Reply-To: <9A78D41B-A5C3-4A41-A242-96292E19BF16@froztbyte.net> References: <50C1A9C0.3000604@mesh.ad.jp> <9A78D41B-A5C3-4A41-A242-96292E19BF16@froztbyte.net> Message-ID: http://www.google.org/publicalerts/alert?aid=d8c6cebb80c5dbfb&hl=en&gl=US&source=web On Fri, Dec 7, 2012 at 10:36 AM, JP Viljoen wrote: > On 07 Dec 2012, at 10:33 AM, Seiichi Kawamura > wrote: > > FYI, another big earthquake in Japan just now. M7.3 > > Inland or coast? > > From kyhwana at gmail.com Fri Dec 7 08:39:43 2012 From: kyhwana at gmail.com (Daniel Richards) Date: Fri, 7 Dec 2012 21:39:43 +1300 Subject: earthquake in Japan right now In-Reply-To: <9A78D41B-A5C3-4A41-A242-96292E19BF16@froztbyte.net> References: <50C1A9C0.3000604@mesh.ad.jp> <9A78D41B-A5C3-4A41-A242-96292E19BF16@froztbyte.net> Message-ID: See http://earthquake.usgs.gov/earthquakes/eventpage/usc000e5n4#summary and http://ptwc.weather.gov/ On Fri, Dec 7, 2012 at 9:36 PM, JP Viljoen wrote: > On 07 Dec 2012, at 10:33 AM, Seiichi Kawamura wrote: >> FYI, another big earthquake in Japan just now. M7.3 > > Inland or coast? > From kawamucho at mesh.ad.jp Fri Dec 7 08:45:35 2012 From: kawamucho at mesh.ad.jp (Seiichi Kawamura) Date: Fri, 07 Dec 2012 17:45:35 +0900 Subject: earthquake in Japan right now In-Reply-To: <9A78D41B-A5C3-4A41-A242-96292E19BF16@froztbyte.net> References: <50C1A9C0.3000604@mesh.ad.jp> <9A78D41B-A5C3-4A41-A242-96292E19BF16@froztbyte.net> Message-ID: <50C1ACAF.7000605@mesh.ad.jp> Off coast. Pretty close to the 311 quake. I'm not hearing any major circuit outages here yet but it seems like traffic to social sites are rising. Seiichi (2012/12/07 17:36), JP Viljoen wrote: > On 07 Dec 2012, at 10:33 AM, Seiichi Kawamura wrote: >> FYI, another big earthquake in Japan just now. M7.3 > > Inland or coast? > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From swmike at swm.pp.se Fri Dec 7 08:45:48 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 7 Dec 2012 09:45:48 +0100 (CET) Subject: earthquake in Japan right now In-Reply-To: <9A78D41B-A5C3-4A41-A242-96292E19BF16@froztbyte.net> References: <50C1A9C0.3000604@mesh.ad.jp> <9A78D41B-A5C3-4A41-A242-96292E19BF16@froztbyte.net> Message-ID: On Fri, 7 Dec 2012, JP Viljoen wrote: > On 07 Dec 2012, at 10:33 AM, Seiichi Kawamura wrote: >> FYI, another big earthquake in Japan just now. M7.3 > > Inland or coast? -- Mikael Abrahamsson email: swmike at swm.pp.se From george.herbert at gmail.com Fri Dec 7 08:57:52 2012 From: george.herbert at gmail.com (George Herbert) Date: Fri, 7 Dec 2012 00:57:52 -0800 Subject: earthquake in Japan right now In-Reply-To: <9A78D41B-A5C3-4A41-A242-96292E19BF16@froztbyte.net> References: <50C1A9C0.3000604@mesh.ad.jp> <9A78D41B-A5C3-4A41-A242-96292E19BF16@froztbyte.net> Message-ID: <87EB9766-A2D8-47B1-ABEB-A48E6752D9FD@gmail.com> 250 or so km east of Sendai, near the big offshore quake zone from last year. CNN and the USGS have the basic info but no tsunami warning or damage info yet as fas as I saw. George William Herbert Sent from my iPhone On Dec 7, 2012, at 12:36 AM, JP Viljoen wrote: > On 07 Dec 2012, at 10:33 AM, Seiichi Kawamura wrote: >> FYI, another big earthquake in Japan just now. M7.3 > > Inland or coast? > From randy at psg.com Fri Dec 7 09:02:49 2012 From: randy at psg.com (Randy Bush) Date: Fri, 07 Dec 2012 18:02:49 +0900 Subject: earthquake in Japan right now In-Reply-To: <50C1A9C0.3000604@mesh.ad.jp> References: <50C1A9C0.3000604@mesh.ad.jp> Message-ID: > FYI, another big earthquake in Japan just now. M7.3 it kept going for a good while. we went for cover. From randy at psg.com Fri Dec 7 09:04:26 2012 From: randy at psg.com (Randy Bush) Date: Fri, 07 Dec 2012 18:04:26 +0900 Subject: earthquake in Japan right now In-Reply-To: <50C1A9C0.3000604@mesh.ad.jp> References: <50C1A9C0.3000604@mesh.ad.jp> Message-ID: fwiw, i watch http://twitter.com/quake_alert_en randy From yuri at yurisk.info Fri Dec 7 09:30:52 2012 From: yuri at yurisk.info (Yuri Slobodyanyuk) Date: Fri, 7 Dec 2012 11:30:52 +0200 Subject: Solutions for DoS & DDoS In-Reply-To: <0D89D80C-D288-402F-8723-B837EA52313C@gmail.com> References: <0D89D80C-D288-402F-8723-B837EA52313C@gmail.com> Message-ID: I can think of few options here (basically restating what has been said already) : - Black hole routing on ISP side - just makes the client unreachable outside ISP , available everywhere, free. Not really a protection as aids the attacker in achieving his goal - shutting down the client - Managed DDOS As a Service on ISP side - ISP has a dedicated solution to stop attacks on ISP premises (by dedicated I mean some hardware installed) . Vendors vary (Arbor/Radware/etc..) and actually are not of much importance to the end client - only SLA should be in place. Costs money, advisable when undergoing non-stop/frequent attacks of moderate severity. If an attack reaches gigabits bandwidth consumption the ISP may revert back to Black Hole to protect its backbone and other clients. - If speaking of web/email services - hosted solution is viable to some degree (e..g Amazon AWS Cloudfront, Google Apps, CDNs etc) . IT is not a DEDICATED hosted solution against DDOS, so be prepared for the provider to shut down the client if the attack gets heavy enough - Hosted web/email solutions WITH dedicated DDOS protection included, including insurance that client will not be shut down on heavy load attack (Prolexic etc) . Costs money (not cheap at all) and if your site is not to be attacked like krebsonsecurity.com or fbi.gov probably an overkill. HTH > -- > Taking challenges one by one. http://yurisk.info From cciehelps at gmail.com Fri Dec 7 10:05:26 2012 From: cciehelps at gmail.com (ku po) Date: Fri, 7 Dec 2012 18:05:26 +0800 Subject: PHP library for IOS devices In-Reply-To: References: Message-ID: I can imagine this could be very powerful tool if completed. Just wondering, is there any existing Cisco libraries/tools in any languages? Pearl maybe? https://plus.google.com/communities/107233969484096327465 CCIEhelp On Wed, Nov 28, 2012 at 11:35 PM, Ray Soucy wrote: > Quick note as many on-list may find this useful. > > I've maintained a PHP class to connect to IOS devices over telnet and > parse the output into something useful for various internal tools for > a few years now. I've recently worked with the author of phpseclib to > create an SSH version of the library. > > It's still in a pre-release state until I have time to clean it up, > but I've uploaded an archive of the SSH version and the modified > phpseclib for anyone who needs in the meantime. > > You can find it at the bottom of the Cisco for PHP page: > > http://soucy.org/project/cisco/ > > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network > www.maineren.net > > From jay at miscreant.org Fri Dec 7 12:19:24 2012 From: jay at miscreant.org (Jay Mitchell) Date: Fri, 7 Dec 2012 23:19:24 +1100 Subject: PHP library for IOS devices In-Reply-To: References: Message-ID: <0e3e01cdd475$1ac7b450$50571cf0$@miscreant.org> Heaps, but I started my search here: http://sourceforge.net/projects/cosi-nms/files/ --jm -----Original Message----- From: ku po [mailto:cciehelps at gmail.com] Sent: Friday, 7 December 2012 9:05 PM To: NANOG Subject: Re: PHP library for IOS devices I can imagine this could be very powerful tool if completed. Just wondering, is there any existing Cisco libraries/tools in any languages? Pearl maybe? https://plus.google.com/communities/107233969484096327465 CCIEhelp On Wed, Nov 28, 2012 at 11:35 PM, Ray Soucy wrote: > Quick note as many on-list may find this useful. > > I've maintained a PHP class to connect to IOS devices over telnet and > parse the output into something useful for various internal tools for > a few years now. I've recently worked with the author of phpseclib to > create an SSH version of the library. > > It's still in a pre-release state until I have time to clean it up, > but I've uploaded an archive of the SSH version and the modified > phpseclib for anyone who needs in the meantime. > > You can find it at the bottom of the Cisco for PHP page: > > http://soucy.org/project/cisco/ > > > > > -- > Ray Patrick Soucy > Network Engineer > University of Maine System > > T: 207-561-3526 > F: 207-561-3531 > > MaineREN, Maine's Research and Education Network www.maineren.net > > From joquendo at e-fensive.net Fri Dec 7 15:28:54 2012 From: joquendo at e-fensive.net (J. Oquendo) Date: Fri, 7 Dec 2012 09:28:54 -0600 Subject: SSL on Juniper.net Message-ID: <20121207152854.GA60697@e-fensive.net> Yes, semi off/on topic I am aware, but because there are many here who visit the site, figured I'd ask. Anyone else having certificate issues on Juniper.net && their support login? This just started today. www.juniper.net is pushing an Akamai cert, support.j* is pushing a Comodo cert. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF From askoorb+nanog at gmail.com Fri Dec 7 15:46:31 2012 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Fri, 7 Dec 2012 15:46:31 +0000 Subject: SSL on Juniper.net In-Reply-To: <20121207152854.GA60697@e-fensive.net> References: <20121207152854.GA60697@e-fensive.net> Message-ID: Hi, On Fri, Dec 7, 2012 at 3:28 PM, J. Oquendo wrote: > > > Yes, semi off/on topic I am aware, but because there are > many here who visit the site, figured I'd ask. Anyone else > having certificate issues on Juniper.net && their support > login? This just started today. > > www.juniper.net is pushing an Akamai cert, support.j* is > pushing a Comodo cert. > When having to diagnose HTTPS problems, I've found the automated tests from Qualys SSL Labs to be a handy first step to save time. In this instance it appears that www.juniper.net is a standard Akamai setup (nothing special there, fairly OKish), but somebody has put the wrong certificate at support.juniper.net (the certificate presented there is for ipv6.juniper.net, origin-www.juniper.net and www.juniper.net only). https://sslcheck.globalsign.com/en_GB/sslcheck?host=www.juniper.net and https://sslcheck.globalsign.com/en_GB/sslcheck?host=support.juniper.net if anyone wants to have a look Alex From cscora at apnic.net Fri Dec 7 18:52:23 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 Dec 2012 04:52:23 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201212071852.qB7IqNVr016070@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 08 Dec, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 436440 Prefixes after maximum aggregation: 180518 Deaggregation factor: 2.42 Unique aggregates announced to Internet: 213616 Total ASes present in the Internet Routing Table: 42792 Prefixes per ASN: 10.20 Origin-only ASes present in the Internet Routing Table: 33895 Origin ASes announcing only one prefix: 15847 Transit ASes present in the Internet Routing Table: 5707 Transit-only ASes present in the Internet Routing Table: 135 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 40 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 1150 Unregistered ASNs in the Routing Table: 420 Number of 32-bit ASNs allocated by the RIRs: 3560 Number of 32-bit ASNs visible in the Routing Table: 3190 Prefixes from 32-bit ASNs in the Routing Table: 8632 Special use prefixes present in the Routing Table: 15 Prefixes being announced from unallocated address space: 153 Number of addresses announced to Internet: 2618209004 Equivalent to 156 /8s, 14 /16s and 178 /24s Percentage of available address space announced: 70.7 Percentage of allocated address space announced: 70.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.0 Total number of prefixes smaller than registry allocations: 153938 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 105256 Total APNIC prefixes after maximum aggregation: 32667 APNIC Deaggregation factor: 3.22 Prefixes being announced from the APNIC address blocks: 106149 Unique aggregates announced from the APNIC address blocks: 43289 APNIC Region origin ASes present in the Internet Routing Table: 4803 APNIC Prefixes per ASN: 22.10 APNIC Region origin ASes announcing only one prefix: 1250 APNIC Region transit ASes present in the Internet Routing Table: 793 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 383 Number of APNIC addresses announced to Internet: 715881888 Equivalent to 42 /8s, 171 /16s and 125 /24s Percentage of available APNIC address space announced: 83.7 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: 155641 Total ARIN prefixes after maximum aggregation: 78471 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 156370 Unique aggregates announced from the ARIN address blocks: 70031 ARIN Region origin ASes present in the Internet Routing Table: 15331 ARIN Prefixes per ASN: 10.20 ARIN Region origin ASes announcing only one prefix: 5789 ARIN Region transit ASes present in the Internet Routing Table: 1596 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 18 Number of ARIN addresses announced to Internet: 1088929152 Equivalent to 64 /8s, 231 /16s and 189 /24s Percentage of available ARIN address space announced: 57.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 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: 112008 Total RIPE prefixes after maximum aggregation: 58057 RIPE Deaggregation factor: 1.93 Prefixes being announced from the RIPE address blocks: 114875 Unique aggregates announced from the RIPE address blocks: 73582 RIPE Region origin ASes present in the Internet Routing Table: 16984 RIPE Prefixes per ASN: 6.76 RIPE Region origin ASes announcing only one prefix: 8129 RIPE Region transit ASes present in the Internet Routing Table: 2764 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 40 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2062 Number of RIPE addresses announced to Internet: 649605028 Equivalent to 38 /8s, 184 /16s and 47 /24s Percentage of available RIPE address space announced: 94.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: 45021 Total LACNIC prefixes after maximum aggregation: 8937 LACNIC Deaggregation factor: 5.04 Prefixes being announced from the LACNIC address blocks: 48547 Unique aggregates announced from the LACNIC address blocks: 22960 LACNIC Region origin ASes present in the Internet Routing Table: 1735 LACNIC Prefixes per ASN: 27.98 LACNIC Region origin ASes announcing only one prefix: 497 LACNIC Region transit ASes present in the Internet Routing Table: 329 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 721 Number of LACNIC addresses announced to Internet: 120301608 Equivalent to 7 /8s, 43 /16s and 168 /24s Percentage of available LACNIC address space announced: 71.7 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 9764 Total AfriNIC prefixes after maximum aggregation: 2332 AfriNIC Deaggregation factor: 4.19 Prefixes being announced from the AfriNIC address blocks: 10346 Unique aggregates announced from the AfriNIC address blocks: 3620 AfriNIC Region origin ASes present in the Internet Routing Table: 582 AfriNIC Prefixes per ASN: 17.78 AfriNIC Region origin ASes announcing only one prefix: 182 AfriNIC Region transit ASes present in the Internet Routing Table: 128 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 43028480 Equivalent to 2 /8s, 144 /16s and 144 /24s Percentage of available AfriNIC address space announced: 42.7 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2932 11557 902 Korea Telecom (KIX) 17974 2432 826 46 PT TELEKOMUNIKASI INDONESIA 7545 1812 301 90 TPG Internet Pty Ltd 4755 1664 383 177 TATA Communications formerly 9829 1412 1155 41 BSNL National Internet Backbo 9583 1180 88 498 Sify Limited 7552 1140 1062 11 Vietel Corporation 4808 1126 2056 317 CNCGROUP IP network: China169 24560 1035 385 165 Bharti Airtel Ltd., Telemedia 9498 1025 307 70 BHARTI Airtel Ltd. 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 7029 3197 994 218 Windstream Communications Inc 6389 3133 3719 142 bellsouth.net, inc. 18566 2082 382 180 Covad Communications 22773 1940 2932 131 Cox Communications, Inc. 1785 1935 678 124 PaeTec Communications, Inc. 20115 1687 1607 623 Charter Communications 4323 1589 1153 395 Time Warner Telecom 30036 1370 290 754 Mediacom Communications Corp 7018 1285 10533 852 AT&T WorldNet Services 7011 1215 322 692 Citizens Utilities 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 1757 544 16 Corbina telecom 2118 1424 97 15 EUnet/RELCOM Autonomous Syste 12479 859 777 64 Uni2 Autonomous System 34984 857 210 217 BILISIM TELEKOM 13188 745 95 132 Educational Network 31148 738 38 13 FreeNet ISP 6830 715 2313 436 UPC Distribution Services 20940 705 227 544 Akamai Technologies European 58113 613 68 372 LIR DATACENTER TELECOM SRL 8551 602 367 39 Bezeq International 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 10620 2263 386 207 TVCABLE BOGOTA 28573 2199 1290 71 NET Servicos de Comunicao S.A 7303 1671 1138 202 Telecom Argentina Stet-France 8151 1603 3028 356 UniNet S.A. de C.V. 6503 1536 435 67 AVANTEL, S.A. 27947 759 85 93 Telconet S.A 3816 660 309 71 Empresa Nacional de Telecomun 11172 603 85 68 Servicios Alestra S.A de C.V 18881 602 716 18 Global Village Telecom 22047 579 326 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 24863 874 275 36 LINKdotNET AS number 36998 772 48 3 MOBITEL 8452 546 958 13 TEDATA 6713 519 666 20 Itissalat Al-MAGHRIB 24835 291 80 8 RAYA Telecom - Egypt 3741 267 906 225 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 33776 190 12 13 Starcomms Nigeria Limited 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 7029 3197 994 218 Windstream Communications Inc 6389 3133 3719 142 bellsouth.net, inc. 4766 2932 11557 902 Korea Telecom (KIX) 17974 2432 826 46 PT TELEKOMUNIKASI INDONESIA 10620 2263 386 207 TVCABLE BOGOTA 28573 2199 1290 71 NET Servicos de Comunicao S.A 18566 2082 382 180 Covad Communications 22773 1940 2932 131 Cox Communications, Inc. 1785 1935 678 124 PaeTec Communications, Inc. 7545 1812 301 90 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3133 2991 bellsouth.net, inc. 17974 2432 2386 PT TELEKOMUNIKASI INDONESIA 28573 2199 2128 NET Servicos de Comunicao S.A 10620 2263 2056 TVCABLE BOGOTA 4766 2932 2030 Korea Telecom (KIX) 18566 2082 1902 Covad Communications 1785 1935 1811 PaeTec Communications, Inc. 22773 1940 1809 Cox Communications, Inc. 8402 1757 1741 Corbina telecom 7545 1812 1722 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 59530 UNALLOCATED 5.8.182.0/24 31261 GARS Telecom 61408 UNALLOCATED 5.56.0.0/21 174 Cogent Communication 61395 UNALLOCATED 5.83.56.0/22 3292 TDC Tele Danmark 61395 UNALLOCATED 5.83.60.0/22 3292 TDC Tele Danmark 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 3549 Global Crossing 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 59521 UNALLOCATED 5.134.192.0/21 29518 Labs2 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.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.112.114.0/24 23884 Proimage Engineering and Comm 41.222.80.0/21 37110 Moztel LDA 41.223.108.0/22 36966 >>UNKNOWN<< 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.66.32.0/20 18864 >>UNKNOWN<< 64.187.160.0/20 54858 Condointernet.net 64.187.208.0/24 174 Cogent Communications 64.187.209.0/24 23005 Power Pulse 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:18 /9:13 /10:29 /11:87 /12:244 /13:477 /14:857 /15:1551 /16:12480 /17:6569 /18:10967 /19:21557 /20:30819 /21:32936 /22:43986 /23:40759 /24:228826 /25:1360 /26:1735 /27:866 /28:183 /29:79 /30:17 /31:0 /32:25 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2622 3197 Windstream Communications Inc 18566 2032 2082 Covad Communications 6389 1776 3133 bellsouth.net, inc. 8402 1476 1757 Corbina telecom 30036 1279 1370 Mediacom Communications Corp 22773 1274 1940 Cox Communications, Inc. 11492 1147 1183 Cable One 6503 1055 1536 AVANTEL, S.A. 1785 1020 1935 PaeTec Communications, Inc. 7011 953 1215 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:644 2:710 3:1 4:13 5:667 6:3 8:488 12:1952 13:3 14:700 15:11 16:3 17:6 20:27 23:214 24:1790 27:1409 31:1311 32:54 33:2 34:2 36:7 37:1069 38:845 39:2 40:140 41:2678 42:179 44:3 46:1701 47:3 49:511 50:622 52:12 54:27 55:8 57:28 58:1066 59:581 60:235 61:1367 62:1025 63:2022 64:4362 65:2206 66:4486 67:2084 68:1181 69:3248 70:922 71:548 72:1900 74:2627 75:479 76:297 77:1032 78:1001 79:509 80:1212 81:982 82:627 83:533 84:530 85:1154 86:475 87:959 88:353 89:1766 90:305 91:5360 92:589 93:1611 94:2020 95:1359 96:457 97:322 98:966 99:40 100:31 101:286 103:1905 105:516 106:119 107:203 108:491 109:1694 110:823 111:974 112:459 113:740 114:643 115:971 116:886 117:776 118:970 119:1256 120:378 121:795 122:1733 123:1165 124:1325 125:1287 128:560 129:202 130:296 131:642 132:319 133:143 134:254 135:62 136:215 137:234 138:343 139:167 140:180 141:304 142:506 143:355 144:491 145:81 146:521 147:269 148:735 149:330 150:154 151:235 152:399 153:187 154:22 155:441 156:226 157:379 158:256 159:678 160:335 161:415 162:372 163:188 164:580 165:451 166:476 167:566 168:992 169:131 170:985 171:169 172:6 173:1704 174:634 175:459 176:852 177:1461 178:1701 180:1345 181:181 182:1122 183:305 184:625 185:117 186:2102 187:1443 188:1799 189:1609 190:6160 192:6087 193:5821 194:4646 195:3665 196:1248 197:279 198:3981 199:5131 200:6018 201:1974 202:8811 203:8739 204:4435 205:2557 206:2755 207:2817 208:4080 209:3651 210:2916 211:1533 212:2109 213:1858 214:888 215:74 216:5176 217:1608 218:590 219:341 220:1259 221:542 222:336 223:361 End of report From danny at danysek.cz Fri Dec 7 19:13:27 2012 From: danny at danysek.cz (Daniel Suchy) Date: Fri, 07 Dec 2012 20:13:27 +0100 Subject: Google Fiber - keeps you regular In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B018007@ocsbs.ocosa.com> References: <50c081d7.0xwaJdqoLgLNIuML%ops.lists@gmail.com><5FE1FB6D43B8A647BBC821840C1AEA8B018002@ocsbs.ocosa.com> <5FE1FB6D43B8A647BBC821840C1AEA8B018007@ocsbs.ocosa.com> Message-ID: <50C23FD7.2070403@danysek.cz> There's one tiny detail: Published on Apr 1, 2012... It's April fool... :-) - Daniel On 12/07/2012 12:53 AM, Otis L. Surratt, Jr. wrote: > Yep. But you know I wouldn't be surprised if Google entered that market. That's why I was asking. You never know these days. > > From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] > Sent: Thursday, December 06, 2012 5:36 PM > To: Otis L. Surratt, Jr. > Cc: nanog at nanog.org > Subject: Re: Google Fiber - keeps you regular > > All jokes about crappy Internet service aside, that is? > > On Friday, December 7, 2012, Otis L. Surratt, Jr. wrote: > Why does the youtube video link lead back to their Fiber Internet/TV > offering? > Maybe I'm lost but the video is about a Google Fiber Bar right? > > Otis > > -----Original Message----- > From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] > Sent: Thursday, December 06, 2012 5:31 AM > To: nanog at nanog.org > Subject: Google Fiber - keeps you regular > > Introducing the Google Fiber Bar > > you'll probably laugh so hard you won't even need the fiber > > From betty at newnog.org Fri Dec 7 20:20:09 2012 From: betty at newnog.org (Betty Burke ) Date: Fri, 7 Dec 2012 15:20:09 -0500 Subject: [NANOG-announce] Best Current Operational Practices Working Group Message-ID: CALL FOR VOLUNTEERS The NANOG Best Current Operational Practices Working Group is seeking volunteers to take part in the creation of official best practices documents. We are also looking for a co-Chairman to assist NANOG WG, Chair Aaron Hughes. The goal of the BCOP-WG is to produce professional Best Practices documents that can be used globally by the network engineering community. The NANOG BCOP-WG works together with other operator forums, ARIN, and ISOC. The NANOG organization will support the BCOP-WG through professional resources, web sites, meeting space, and financial support. A mailing list is being set up and an organizational meeting will occur at NANOG 57 in Orlando in February 2013. Some areas for BCOP development include: - Address Assignment - Routing Protocol implementation - Routing Policy - Network Security Policy - Network Deployment - DNS Operations - and more! Please volunteer if you are able to devote some time to the effort and have a willingness to write and edit BCOP documents. The plan is to publish numerous official BCOP documents each year with significant professional exposure for authors and editors. This is a great way to get involved in the NANOG organization, to develop yourself professionally, and to serve the larger Internet community. If interested, please reply to betty at nanog.org. Daniel Golding and Betty Burke Members of the NANOG Board of Directors -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From mpalmer at hezmatt.org Fri Dec 7 21:51:02 2012 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 8 Dec 2012 08:51:02 +1100 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: References: <20121206132528.18044lmiz7spnq4g@webmail.orenet.co.uk> Message-ID: <20121207215102.GN4679@hezmatt.org> On Thu, Dec 06, 2012 at 08:58:10AM -0500, Ray Soucy wrote: > > net.ipv4.tcp_keepalive_intvl = 15 > > net.ipv4.tcp_keepalive_probes = 3 > > net.ipv4.tcp_keepalive_time = 90 > > net.ipv4.tcp_fin_timeout = 30 > > As discussed, those do not affect TCP_TIMEWAIT_LEN. > > There is a lot of misinformation out there on this subject so please > don't just Google for 5 min. and chime in with a "solution" that you > haven't verified yourself. > > We can expand the ephemeral port range to be a full 60K (and we have > as a band-aid), but that only delays the issue as use grows. I can > verify that changing it via: > > echo 1025 65535 > /proc/sys/net/ipv4/ip_local_port_range > > Does work for the full range, as a spot check shows ports as low as > 2000 and as high as 64000 being used. I can attest to the effectiveness of this method, however be sure and add any ports in that range that you use as incoming ports for services to /proc/sys/net/ipv4/ip_local_reserved_ports, otherwise the first time you restart a service that uses a high port (*cough*NRPE*cough*), its port will probably get snarfed for an outgoing connection and then you're in a sad, sad place. - Matt -- [An ad for Microsoft] uses the musical theme of the "Confutatis Maledictis" from Mozart's Requiem. "Where do you want to go today?" is on the screen, while the chorus sings "Confutatis maledictis, flammis acribus addictis,". Translation: "The damned and accursed are convicted to the flames of hell." From cidr-report at potaroo.net Fri Dec 7 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Dec 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201212072200.qB7M00qC022200@wattle.apnic.net> This report has been generated at Fri Dec 7 21:13:08 2012 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 30-11-12 435823 252122 01-12-12 436665 250891 02-12-12 436407 251001 03-12-12 436577 251165 04-12-12 437029 251157 05-12-12 437195 252441 06-12-12 437689 251620 07-12-12 438154 251279 AS Summary 42907 Number of ASes in routing system 17844 Number of ASes announcing only one prefix 3197 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 115225824 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'). --- 07Dec12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 439125 251228 187897 42.8% All ASes AS6389 3132 145 2987 95.4% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2199 72 2127 96.7% NET Servicos de Comunicao S.A. AS4766 2932 920 2012 68.6% KIXS-AS-KR Korea Telecom AS17974 2432 558 1874 77.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 1940 132 1808 93.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS7029 3197 1456 1741 54.5% WINDSTREAM - Windstream Communications Inc AS18566 2082 423 1659 79.7% COVAD - Covad Communications Co. AS10620 2263 653 1610 71.1% Telmex Colombia S.A. AS2118 1424 51 1373 96.4% RELCOM-AS OOO "NPO Relcom" AS7303 1671 397 1274 76.2% Telecom Argentina S.A. AS4323 1594 401 1193 74.8% TWTC - tw telecom holdings, inc. AS4755 1664 556 1108 66.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1140 207 933 81.8% VIETEL-AS-AP Vietel Corporation AS8151 1609 702 907 56.4% Uninet S.A. de C.V. AS18101 1017 173 844 83.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7545 1817 1032 785 43.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS17908 841 60 781 92.9% TCISL Tata Communications AS4808 1126 350 776 68.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS1785 1934 1159 775 40.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS9808 775 32 743 95.9% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS13977 857 118 739 86.2% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS855 715 56 659 92.2% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS17676 709 89 620 87.4% GIGAINFRA Softbank BB Corp. AS3356 1116 499 617 55.3% LEVEL3 Level 3 Communications AS3549 1055 442 613 58.1% GBLX Global Crossing Ltd. AS22561 1038 431 607 58.5% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 1000 405 595 59.5% VZGNI-TRANSIT - Verizon Online LLC AS24560 1035 446 589 56.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS36998 772 203 569 73.7% SDN-MOBITEL AS18881 602 41 561 93.2% Global Village Telecom Total 45688 12209 33479 73.3% 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- 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.222.80.0/21 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.160.0/20 AS54858 AS-SBI - Condointernet.net 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 68.234.0.0/19 AS40430 COLO4JAX-AS - colo4jax, LLC 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 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 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.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.217.250.0/24 AS43108 GARM-AS Garm Technologies Ltd. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.29.237.0/24 AS13200 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 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.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 185.11.236.0/22 AS57910 SCIP-AS Soluciones Corporativas IP, SL 185.12.148.0/22 AS51747 INTERNETBOLAGET InternetBolaget Sweden AB 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 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.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 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.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 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 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 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 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.87.96.0/21 AS40638 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. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 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 Dec 7 22:00:01 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 Dec 2012 22:00:01 GMT Subject: BGP Update Report Message-ID: <201212072200.qB7M01Cp022215@wattle.apnic.net> BGP Update Report Interval: 29-Nov-12 -to- 06-Dec-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 58444 1.4% 26.1 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS37113 52105 1.3% 1132.7 -- tangerine-ug-as 3 - AS3909 41215 1.0% 1248.9 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - AS9829 41144 1.0% 29.1 -- BSNL-NIB National Internet Backbone 5 - AS10620 36921 0.9% 16.3 -- Telmex Colombia S.A. 6 - AS35228 32854 0.8% 80.7 -- BEUNLIMITED Avatar Broadband Limited 7 - AS7029 32543 0.8% 9.8 -- WINDSTREAM - Windstream Communications Inc 8 - AS28573 26684 0.7% 12.1 -- NET Servicos de Comunicao S.A. 9 - AS37044 23979 0.6% 1199.0 -- Tangerine-AS 10 - AS7552 22587 0.6% 19.7 -- VIETEL-AS-AP Vietel Corporation 11 - AS9304 21100 0.5% 18.9 -- HUTCHISON-AS-AP Hutchison Global Communications 12 - AS22561 18513 0.5% 17.8 -- DIGITAL-TELEPORT - Digital Teleport Inc. 13 - AS3816 17912 0.4% 26.9 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 14 - AS8151 17419 0.4% 10.8 -- Uninet S.A. de C.V. 15 - AS13118 16341 0.4% 333.5 -- ASN-YARTELECOM OJSC Rostelecom 16 - AS2697 16336 0.4% 78.9 -- ERX-ERNET-AS Education and Research Network 17 - AS36915 16239 0.4% 477.6 -- AFOL-KE-AS 18 - AS6389 16140 0.4% 5.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 19 - AS7545 14892 0.4% 8.9 -- TPG-INTERNET-AP TPG Internet Pty Ltd 20 - AS4766 14868 0.4% 5.0 -- KIXS-AS-KR Korea Telecom TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS43695 9611 0.2% 9611.0 -- LISNER_AS UNIQ LISNER Sp. z o.o. 2 - AS24057 7789 0.2% 7789.0 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 3 - AS33158 2650 0.1% 2650.0 -- DATA-SERVICES-INC - Data Services Incorporated 4 - AS14680 6754 0.2% 2251.3 -- REALE-6 - Auction.com 5 - AS4 1801 0.0% 333.0 -- COMUNICALO DE MEXICO S.A. DE C.V 6 - AS26799 3535 0.1% 1767.5 -- DKR - DKR CAPITAL 7 - AS57918 1622 0.0% 1622.0 -- ACOD-AS ACOD CJSC 8 - AS3909 41215 1.0% 1248.9 -- QWEST-AS-3908 - Qwest Communications Company, LLC 9 - AS29039 11195 0.3% 1243.9 -- AFRICAONLINE-UG Africa Online Uganda 10 - AS37115 1218 0.0% 1218.0 -- TMP-UG 11 - AS51122 1215 0.0% 1215.0 -- SIT-CORP-AS Sitronics, AO 12 - AS37044 23979 0.6% 1199.0 -- Tangerine-AS 13 - AS37113 52105 1.3% 1132.7 -- tangerine-ug-as 14 - AS2033 8998 0.2% 1124.8 -- PANIX - Panix Network Information Center 15 - AS37273 3083 0.1% 1027.7 -- BCS 16 - AS37156 4888 0.1% 977.6 -- XTRANET 17 - AS6174 1852 0.1% 926.0 -- SPRINTLINK8 - Sprint 18 - AS3 13728 0.3% 460.0 -- CMED-AS Cmed Technology Ltd 19 - AS49677 851 0.0% 851.0 -- MAEHDROS-AS Maehdros SPRL 20 - AS4 724 0.0% 665.0 -- COMUNICALO DE MEXICO S.A. DE C.V TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 93.181.254.0/23 15963 0.4% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 151.118.254.0/24 13701 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.255.0/24 13701 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 178.248.238.0/24 13612 0.3% AS3 -- CMED-AS Cmed Technology Ltd 5 - 151.118.18.0/24 13611 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 6 - 91.198.110.0/24 9611 0.2% AS43695 -- LISNER_AS UNIQ LISNER Sp. z o.o. 7 - 209.48.168.0/24 8963 0.2% AS2033 -- PANIX - Panix Network Information Center 8 - 202.14.255.0/24 7789 0.2% AS24057 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 9 - 192.58.232.0/24 7472 0.2% AS6629 -- NOAA-AS - NOAA 10 - 184.159.130.0/23 6913 0.2% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 11 - 184.157.224.0/19 5896 0.1% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 12 - 12.139.133.0/24 5618 0.1% AS14680 -- REALE-6 - Auction.com 13 - 194.63.9.0/24 4608 0.1% AS1273 -- CW Cable and Wireless Worldwide plc 14 - 123.252.208.0/24 4440 0.1% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 15 - 49.248.72.0/21 4152 0.1% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 16 - 69.38.178.0/24 4151 0.1% AS19406 -- TWRS-MA - Towerstream I, Inc. 17 - 139.139.19.0/24 3704 0.1% AS1562 -- DNIC-ASBLK-01550-01601 - DoD Network Information Center 18 - 58.184.229.0/24 3532 0.1% AS9950 -- PUBNETPLUS2-AS-KR DACOM 19 - 12.30.238.0/24 3532 0.1% AS26799 -- DKR - DKR CAPITAL 20 - 12.183.21.0/24 2650 0.1% AS33158 -- DATA-SERVICES-INC - Data Services Incorporated 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 carl at mobsource.com Fri Dec 7 23:34:07 2012 From: carl at mobsource.com (Carl Gough) Date: Sat, 8 Dec 2012 10:34:07 +1100 Subject: NANOG Digest, Vol 59, Issue 30 In-Reply-To: References: Message-ID: Looking for a sales engineer seeking a new challenge in 2013 in Sydney.. The new Silicon Valley Would anyone know of anyone looking for a cloud/infrastructure sales engineering role or is currently out of work? Just doing my bit to keep unemployment levels down ! >> [carl gough] founder and CEO +61 425 266 764 >> mobsource.com defined by benefits not by technology >> Skype ? mobsource Follow @mobsource Facebook ? mobsource >> . >> mobsource Network as a Service (NaaS) is a "pay as you go" point to point data connection between international markets ? With 99.9999% availability, NO long term contracts, and NO minimum usage, business can now connect to London, USA, Singapore or Sydney, more reliably, "on demand" and up to 80% cheaper than traditional telco's. On 08/12/2012, at 9:00 AM, nanog-request at nanog.org wrote: > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: Google Fiber - keeps you regular (Daniel Suchy) > 2. [NANOG-announce] Best Current Operational Practices Working > Group (Betty Burke ) > 3. Re: TCP time_wait and port exhaustion for servers (Matthew Palmer) > 4. The Cidr Report (cidr-report at potaroo.net) > 5. BGP Update Report (cidr-report at potaroo.net) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 07 Dec 2012 20:13:27 +0100 > From: Daniel Suchy > To: nanog at nanog.org > Subject: Re: Google Fiber - keeps you regular > Message-ID: <50C23FD7.2070403 at danysek.cz> > Content-Type: text/plain; charset=UTF-8 > > There's one tiny detail: Published on Apr 1, 2012... > > It's April fool... :-) > > - Daniel > > On 12/07/2012 12:53 AM, Otis L. Surratt, Jr. wrote: >> Yep. But you know I wouldn't be surprised if Google entered that market. That's why I was asking. You never know these days. >> >> From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] >> Sent: Thursday, December 06, 2012 5:36 PM >> To: Otis L. Surratt, Jr. >> Cc: nanog at nanog.org >> Subject: Re: Google Fiber - keeps you regular >> >> All jokes about crappy Internet service aside, that is? >> >> On Friday, December 7, 2012, Otis L. Surratt, Jr. wrote: >> Why does the youtube video link lead back to their Fiber Internet/TV >> offering? >> Maybe I'm lost but the video is about a Google Fiber Bar right? >> >> Otis >> >> -----Original Message----- >> From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] >> Sent: Thursday, December 06, 2012 5:31 AM >> To: nanog at nanog.org >> Subject: Google Fiber - keeps you regular >> >> Introducing the Google Fiber Bar >> >> you'll probably laugh so hard you won't even need the fiber > > > > ------------------------------ > > Message: 2 > Date: Fri, 7 Dec 2012 15:20:09 -0500 > From: "Betty Burke " > To: nanog-announce at nanog.org > Subject: [NANOG-announce] Best Current Operational Practices Working > Group > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > CALL FOR VOLUNTEERS > > The NANOG Best Current Operational Practices Working Group is seeking > volunteers to take part in the creation of official best practices > documents. We are also looking for a co-Chairman to assist NANOG WG, > Chair Aaron Hughes. The goal of the BCOP-WG is to produce professional > Best Practices documents that can be used globally by the network > engineering community. The NANOG BCOP-WG works together with other > operator forums, ARIN, and ISOC. The NANOG organization will support > the BCOP-WG through professional resources, web sites, meeting space, > and financial support. > > A mailing list is being set up and an organizational meeting will > occur at NANOG 57 in Orlando in February 2013. Some areas for BCOP > development include: > > - Address Assignment > - Routing Protocol implementation > - Routing Policy > - Network Security Policy > - Network Deployment > - DNS Operations > - and more! > > Please volunteer if you are able to devote some time to the effort and > have a willingness to write and edit BCOP documents. The plan is to > publish numerous official BCOP documents each year with significant > professional exposure for authors and editors. This is a great way to > get involved in the NANOG organization, to develop yourself > professionally, and to serve the larger Internet community. > > If interested, please reply to betty at nanog.org. > > Daniel Golding and Betty Burke > Members of the NANOG Board of Directors > > > > -- > Betty Burke > NANOG Executive Director > 48377 Fremont Boulevard, Suite 117 > Fremont, CA 94538 > Tel: +1 510 492 4030 > -------------- next part -------------- > _______________________________________________ > NANOG-announce mailing list > NANOG-announce at mailman.nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog-announce > > ------------------------------ > > Message: 3 > Date: Sat, 8 Dec 2012 08:51:02 +1100 > From: Matthew Palmer > To: nanog at nanog.org > Subject: Re: TCP time_wait and port exhaustion for servers > Message-ID: <20121207215102.GN4679 at hezmatt.org> > Content-Type: text/plain; charset=us-ascii > > On Thu, Dec 06, 2012 at 08:58:10AM -0500, Ray Soucy wrote: >>> net.ipv4.tcp_keepalive_intvl = 15 >>> net.ipv4.tcp_keepalive_probes = 3 >>> net.ipv4.tcp_keepalive_time = 90 >>> net.ipv4.tcp_fin_timeout = 30 >> >> As discussed, those do not affect TCP_TIMEWAIT_LEN. >> >> There is a lot of misinformation out there on this subject so please >> don't just Google for 5 min. and chime in with a "solution" that you >> haven't verified yourself. >> >> We can expand the ephemeral port range to be a full 60K (and we have >> as a band-aid), but that only delays the issue as use grows. I can >> verify that changing it via: >> >> echo 1025 65535 > /proc/sys/net/ipv4/ip_local_port_range >> >> Does work for the full range, as a spot check shows ports as low as >> 2000 and as high as 64000 being used. > > I can attest to the effectiveness of this method, however be sure and add > any ports in that range that you use as incoming ports for services to > /proc/sys/net/ipv4/ip_local_reserved_ports, otherwise the first time you > restart a service that uses a high port (*cough*NRPE*cough*), its port will > probably get snarfed for an outgoing connection and then you're in a sad, > sad place. > > - Matt > > -- > [An ad for Microsoft] uses the musical theme of the "Confutatis Maledictis" > from Mozart's Requiem. "Where do you want to go today?" is on the screen, > while the chorus sings "Confutatis maledictis, flammis acribus addictis,". > Translation: "The damned and accursed are convicted to the flames of hell." > > > > > ------------------------------ > > Message: 4 > Date: Fri, 7 Dec 2012 22:00:00 GMT > From: cidr-report at potaroo.net > To: cidr-report at potaroo.net > Cc: nanog at nanog.org, routing-wg at ripe.net, apops at apops.net, > eof-list at ripe.net, afnog at afnog.org > Subject: The Cidr Report > Message-ID: <201212072200.qB7M00qC022200 at wattle.apnic.net> > > This report has been generated at Fri Dec 7 21:13:08 2012 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 > 30-11-12 435823 252122 > 01-12-12 436665 250891 > 02-12-12 436407 251001 > 03-12-12 436577 251165 > 04-12-12 437029 251157 > 05-12-12 437195 252441 > 06-12-12 437689 251620 > 07-12-12 438154 251279 > > > AS Summary > 42907 Number of ASes in routing system > 17844 Number of ASes announcing only one prefix > 3197 Largest number of prefixes announced by an AS > AS7029 : WINDSTREAM - Windstream Communications Inc > 115225824 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'). > > --- 07Dec12 --- > ASnum NetsNow NetsAggr NetGain % Gain Description > > Table 439125 251228 187897 42.8% All ASes > > AS6389 3132 145 2987 95.4% BELLSOUTH-NET-BLK - > BellSouth.net Inc. > AS28573 2199 72 2127 96.7% NET Servicos de Comunicao S.A. > AS4766 2932 920 2012 68.6% KIXS-AS-KR Korea Telecom > AS17974 2432 558 1874 77.1% TELKOMNET-AS2-AP PT > Telekomunikasi Indonesia > AS22773 1940 132 1808 93.2% ASN-CXA-ALL-CCI-22773-RDC - > Cox Communications Inc. > AS7029 3197 1456 1741 54.5% WINDSTREAM - Windstream > Communications Inc > AS18566 2082 423 1659 79.7% COVAD - Covad Communications > Co. > AS10620 2263 653 1610 71.1% Telmex Colombia S.A. > AS2118 1424 51 1373 96.4% RELCOM-AS OOO "NPO Relcom" > AS7303 1671 397 1274 76.2% Telecom Argentina S.A. > AS4323 1594 401 1193 74.8% TWTC - tw telecom holdings, > inc. > AS4755 1664 556 1108 66.6% TATACOMM-AS TATA > Communications formerly VSNL > is Leading ISP > AS7552 1140 207 933 81.8% VIETEL-AS-AP Vietel > Corporation > AS8151 1609 702 907 56.4% Uninet S.A. de C.V. > AS18101 1017 173 844 83.0% RELIANCE-COMMUNICATIONS-IN > Reliance Communications > Ltd.DAKC MUMBAI > AS7545 1817 1032 785 43.2% TPG-INTERNET-AP TPG Internet > Pty Ltd > AS17908 841 60 781 92.9% TCISL Tata Communications > AS4808 1126 350 776 68.9% CHINA169-BJ CNCGROUP IP > network China169 Beijing > Province Network > AS1785 1934 1159 775 40.1% AS-PAETEC-NET - PaeTec > Communications, Inc. > AS9808 775 32 743 95.9% CMNET-GD Guangdong Mobile > Communication Co.Ltd. > AS13977 857 118 739 86.2% CTELCO - FAIRPOINT > COMMUNICATIONS, INC. > AS855 715 56 659 92.2% CANET-ASN-4 - Bell Aliant > Regional Communications, Inc. > AS17676 709 89 620 87.4% GIGAINFRA Softbank BB Corp. > AS3356 1116 499 617 55.3% LEVEL3 Level 3 Communications > AS3549 1055 442 613 58.1% GBLX Global Crossing Ltd. > AS22561 1038 431 607 58.5% DIGITAL-TELEPORT - Digital > Teleport Inc. > AS19262 1000 405 595 59.5% VZGNI-TRANSIT - Verizon Online > LLC > AS24560 1035 446 589 56.9% AIRTELBROADBAND-AS-AP Bharti > Airtel Ltd., Telemedia > Services > AS36998 772 203 569 73.7% SDN-MOBITEL > AS18881 602 41 561 93.2% Global Village Telecom > > Total 45688 12209 33479 73.3% 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- > 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. > 41.222.80.0/21 AS37110 moztel-as > 41.223.108.0/22 AS36966 EDL_AS Edgenet AS > 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited > 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV > 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV > 64.66.32.0/20 AS18864 > 64.187.160.0/20 AS54858 AS-SBI - Condointernet.net > 64.187.208.0/24 AS174 COGENT Cogent/PSI > 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC > 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global > 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business > 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION > 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC > 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks > 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks > 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks > 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks > 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks > 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks > 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks > 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications > 68.234.0.0/19 AS40430 COLO4JAX-AS - colo4jax, LLC > 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 > 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone > 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.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC > 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc > 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited > 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. > 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. > 91.217.250.0/24 AS43108 GARM-AS Garm Technologies Ltd. > 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange > 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. > 103.29.237.0/24 AS13200 > 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. > 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.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. > 185.11.236.0/22 AS57910 SCIP-AS Soluciones Corporativas IP, SL > 185.12.148.0/22 AS51747 INTERNETBOLAGET InternetBolaget Sweden AB > 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. > 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda > 200.58.248.0/21 AS27849 > 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. > 202.58.113.0/24 AS19161 > 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited > 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited > 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.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia > 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.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd > 203.142.219.0/24 AS45149 > 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 > 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. > 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company > 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 > 207.254.138.0/24 AS30689 FLOW-NET - FLOW > 207.254.140.0/24 AS30689 FLOW-NET - FLOW > 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC > 208.87.96.0/21 AS40638 > 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. > 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications > 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network > 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC > 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations > 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. > 216.21.160.0/20 AS27876 American Data Networks > 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC > 216.194.160.0/20 AS27876 American Data Networks > 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange > 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange > 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 > > > > ------------------------------ > > Message: 5 > Date: Fri, 7 Dec 2012 22:00:01 GMT > From: cidr-report at potaroo.net > To: cidr-report at potaroo.net > Cc: nanog at nanog.org, routing-wg at ripe.net, ausnog at ausnog.net, > apops at apops.net, eof-list at ripe.net, afnog at afnog.org > Subject: BGP Update Report > Message-ID: <201212072200.qB7M01Cp022215 at wattle.apnic.net> > > BGP Update Report > Interval: 29-Nov-12 -to- 06-Dec-12 (7 days) > Observation Point: BGP Peering with AS131072 > > TOP 20 Unstable Origin AS > Rank ASN Upds % Upds/Pfx AS-Name > 1 - AS8402 58444 1.4% 26.1 -- CORBINA-AS OJSC "Vimpelcom" > 2 - AS37113 52105 1.3% 1132.7 -- tangerine-ug-as > 3 - AS3909 41215 1.0% 1248.9 -- QWEST-AS-3908 - Qwest Communications Company, LLC > 4 - AS9829 41144 1.0% 29.1 -- BSNL-NIB National Internet Backbone > 5 - AS10620 36921 0.9% 16.3 -- Telmex Colombia S.A. > 6 - AS35228 32854 0.8% 80.7 -- BEUNLIMITED Avatar Broadband Limited > 7 - AS7029 32543 0.8% 9.8 -- WINDSTREAM - Windstream Communications Inc > 8 - AS28573 26684 0.7% 12.1 -- NET Servicos de Comunicao S.A. > 9 - AS37044 23979 0.6% 1199.0 -- Tangerine-AS > 10 - AS7552 22587 0.6% 19.7 -- VIETEL-AS-AP Vietel Corporation > 11 - AS9304 21100 0.5% 18.9 -- HUTCHISON-AS-AP Hutchison Global Communications > 12 - AS22561 18513 0.5% 17.8 -- DIGITAL-TELEPORT - Digital Teleport Inc. > 13 - AS3816 17912 0.4% 26.9 -- COLOMBIA TELECOMUNICACIONES S.A. ESP > 14 - AS8151 17419 0.4% 10.8 -- Uninet S.A. de C.V. > 15 - AS13118 16341 0.4% 333.5 -- ASN-YARTELECOM OJSC Rostelecom > 16 - AS2697 16336 0.4% 78.9 -- ERX-ERNET-AS Education and Research Network > 17 - AS36915 16239 0.4% 477.6 -- AFOL-KE-AS > 18 - AS6389 16140 0.4% 5.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. > 19 - AS7545 14892 0.4% 8.9 -- TPG-INTERNET-AP TPG Internet Pty Ltd > 20 - AS4766 14868 0.4% 5.0 -- KIXS-AS-KR Korea Telecom > > > TOP 20 Unstable Origin AS (Updates per announced prefix) > Rank ASN Upds % Upds/Pfx AS-Name > 1 - AS43695 9611 0.2% 9611.0 -- LISNER_AS UNIQ LISNER Sp. z o.o. > 2 - AS24057 7789 0.2% 7789.0 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia > 3 - AS33158 2650 0.1% 2650.0 -- DATA-SERVICES-INC - Data Services Incorporated > 4 - AS14680 6754 0.2% 2251.3 -- REALE-6 - Auction.com > 5 - AS4 1801 0.0% 333.0 -- COMUNICALO DE MEXICO S.A. DE C.V > 6 - AS26799 3535 0.1% 1767.5 -- DKR - DKR CAPITAL > 7 - AS57918 1622 0.0% 1622.0 -- ACOD-AS ACOD CJSC > 8 - AS3909 41215 1.0% 1248.9 -- QWEST-AS-3908 - Qwest Communications Company, LLC > 9 - AS29039 11195 0.3% 1243.9 -- AFRICAONLINE-UG Africa Online Uganda > 10 - AS37115 1218 0.0% 1218.0 -- TMP-UG > 11 - AS51122 1215 0.0% 1215.0 -- SIT-CORP-AS Sitronics, AO > 12 - AS37044 23979 0.6% 1199.0 -- Tangerine-AS > 13 - AS37113 52105 1.3% 1132.7 -- tangerine-ug-as > 14 - AS2033 8998 0.2% 1124.8 -- PANIX - Panix Network Information Center > 15 - AS37273 3083 0.1% 1027.7 -- BCS > 16 - AS37156 4888 0.1% 977.6 -- XTRANET > 17 - AS6174 1852 0.1% 926.0 -- SPRINTLINK8 - Sprint > 18 - AS3 13728 0.3% 460.0 -- CMED-AS Cmed Technology Ltd > 19 - AS49677 851 0.0% 851.0 -- MAEHDROS-AS Maehdros SPRL > 20 - AS4 724 0.0% 665.0 -- COMUNICALO DE MEXICO S.A. DE C.V > > > TOP 20 Unstable Prefixes > Rank Prefix Upds % Origin AS -- AS Name > 1 - 93.181.254.0/23 15963 0.4% AS13118 -- ASN-YARTELECOM OJSC Rostelecom > 2 - 151.118.254.0/24 13701 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC > 3 - 151.118.255.0/24 13701 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC > 4 - 178.248.238.0/24 13612 0.3% AS3 -- CMED-AS Cmed Technology Ltd > 5 - 151.118.18.0/24 13611 0.3% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC > 6 - 91.198.110.0/24 9611 0.2% AS43695 -- LISNER_AS UNIQ LISNER Sp. z o.o. > 7 - 209.48.168.0/24 8963 0.2% AS2033 -- PANIX - Panix Network Information Center > 8 - 202.14.255.0/24 7789 0.2% AS24057 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia > 9 - 192.58.232.0/24 7472 0.2% AS6629 -- NOAA-AS - NOAA > 10 - 184.159.130.0/23 6913 0.2% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. > 11 - 184.157.224.0/19 5896 0.1% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. > 12 - 12.139.133.0/24 5618 0.1% AS14680 -- REALE-6 - Auction.com > 13 - 194.63.9.0/24 4608 0.1% AS1273 -- CW Cable and Wireless Worldwide plc > 14 - 123.252.208.0/24 4440 0.1% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd > 15 - 49.248.72.0/21 4152 0.1% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd > 16 - 69.38.178.0/24 4151 0.1% AS19406 -- TWRS-MA - Towerstream I, Inc. > 17 - 139.139.19.0/24 3704 0.1% AS1562 -- DNIC-ASBLK-01550-01601 - DoD Network Information Center > 18 - 58.184.229.0/24 3532 0.1% AS9950 -- PUBNETPLUS2-AS-KR DACOM > 19 - 12.30.238.0/24 3532 0.1% AS26799 -- DKR - DKR CAPITAL > 20 - 12.183.21.0/24 2650 0.1% AS33158 -- DATA-SERVICES-INC - Data Services Incorporated > > 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 > > > > End of NANOG Digest, Vol 59, Issue 30 > ************************************* From Valdis.Kletnieks at vt.edu Sat Dec 8 01:04:32 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 07 Dec 2012 20:04:32 -0500 Subject: NANOG Digest, Vol 59, Issue 30 In-Reply-To: Your message of "Sat, 08 Dec 2012 10:34:07 +1100." References: Message-ID: <27995.1354928672@turing-police.cc.vt.edu> On Sat, 08 Dec 2012 10:34:07 +1100, Carl Gough said: > Looking for a sales engineer I doubt NANOG is the place for you to find sales engineers to work for a company where the CEO is clueless enough to do all of the following in 1 email: 1) Reply to a digest, and not fix the Subject: 2) Not clean up the References: and In-Reply-To:, which means that anybody who uses a threaded mail reader may not have seen your message. 3) Put in a To: "nanog at nanog.org" - that's ugly and redundant. 4) Put it in the cc: as well. That's even more ugly and doubly redundant. 5) Spamming NANOG looking for engineers. Best of luck to you in your future endeavors... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From rps at maine.edu Sat Dec 8 01:08:11 2012 From: rps at maine.edu (Ray Soucy) Date: Fri, 7 Dec 2012 20:08:11 -0500 Subject: TCP time_wait and port exhaustion for servers In-Reply-To: <20121207215102.GN4679@hezmatt.org> References: <20121206132528.18044lmiz7spnq4g@webmail.orenet.co.uk> <20121207215102.GN4679@hezmatt.org> Message-ID: +1 Thanks for the tip, this looks very useful. Looks like it was only introduced in 2.6.35, we're still on 2.6.32 ... might be worth the upgrade, it just takes so long to test new kernel versions in this application. We ended up dropping TCP_TIMEWAIT_LEN to 30 seconds as a band-aid for now, along with the expanded port range. In talking to others 20 seconds seems to be 99%+ safe, with the sweet spot seeming to be 24 seconds or so. So we opted to just go with 30 seconds and be cautious, even though others claim going as low as 10 or 5 seconds without issue. I'll let people know if it introduces any problems. In talking with the author of HAproxy, he seems to be in the camp that using SO_LINGER of 0 might be the way to go, but is unsure of how servers would respond to it; we'll likely try a build with that method and see what happens at some point. On Fri, Dec 7, 2012 at 4:51 PM, Matthew Palmer wrote: > On Thu, Dec 06, 2012 at 08:58:10AM -0500, Ray Soucy wrote: >> > net.ipv4.tcp_keepalive_intvl = 15 >> > net.ipv4.tcp_keepalive_probes = 3 >> > net.ipv4.tcp_keepalive_time = 90 >> > net.ipv4.tcp_fin_timeout = 30 >> >> As discussed, those do not affect TCP_TIMEWAIT_LEN. >> >> There is a lot of misinformation out there on this subject so please >> don't just Google for 5 min. and chime in with a "solution" that you >> haven't verified yourself. >> >> We can expand the ephemeral port range to be a full 60K (and we have >> as a band-aid), but that only delays the issue as use grows. I can >> verify that changing it via: >> >> echo 1025 65535 > /proc/sys/net/ipv4/ip_local_port_range >> >> Does work for the full range, as a spot check shows ports as low as >> 2000 and as high as 64000 being used. > > I can attest to the effectiveness of this method, however be sure and add > any ports in that range that you use as incoming ports for services to > /proc/sys/net/ipv4/ip_local_reserved_ports, otherwise the first time you > restart a service that uses a high port (*cough*NRPE*cough*), its port will > probably get snarfed for an outgoing connection and then you're in a sad, > sad place. > > - Matt > > -- > [An ad for Microsoft] uses the musical theme of the "Confutatis Maledictis" > from Mozart's Requiem. "Where do you want to go today?" is on the screen, > while the chorus sings "Confutatis maledictis, flammis acribus addictis,". > Translation: "The damned and accursed are convicted to the flames of hell." > > -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From mureninc at gmail.com Sat Dec 8 05:45:47 2012 From: mureninc at gmail.com (Constantine A. Murenin) Date: Fri, 7 Dec 2012 21:45:47 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? Message-ID: Hello, I personally don't understand this policy. I've signed up with hetzner.de, and I'm trying to get IPv6; however, on the supplementary page where the complementary IPv6 /64 subnet can be requested (notice that it's not even a /48, and not even the second, routed, /64), after I change the selection from requesting one additional IPv4 address to requesting the IPv6 /64 subnet (they offer no other IPv6 options in that menu), they use DOM to remove the IP address justification field ("Purpose of use"), and instead statically show my name, physical street address (including the apartment number), email address and phone number, and ask to confirm that all of this information can be submitted to RIPE. They offer no option of modifying any of this; they also offer no option of hiding the street address and showing it as "Private Address" instead; they also offer no option of providing contact information different from the contact details for the main profile or keeping a separate set of contact details in the main profile specifically for RIPE; they also offer no option of providing a RIPE handle instead (dunno if one can be registered with a "Private Address" address, showing only city/state/country and postal code; I do know that with ARIN and PA IPv4 subnets you can do "Private Address" in the Address field); they also don't let you submit the form unless you agree for the information shown to be passed along to RIPE for getting IPv6 connectivity (again, no IPv6 is provided by default or otherwise). Is this what we're going towards? No probable cause and no court orders for obtaining individually identifying information about internet customers with IPv6 addresses? In the future, will the copyright trolls be getting this information directly from public whois, bypassing the internet provider abuse teams and even the most minimal court supervision? Is this really the disadvantage of IPv4 that IPv6 proudly fixes? I certainly have never heard of whois entries for /32 IPv4 address allocations! Anyhow, just one more provider where it's easier to use HE's tunnelbroker.net instead of obtaining IPv6 natively; due to the data-mining and privacy concerns now. What's the point of native IPv6 connectivity again? In hetzner.de terms, tunnelbroker.net even provides you with the failover IPv6 address(es), something that they themselves only offer for IPv4! Is it just me, or are there a lot of other folks who use tunnelbroker.net even when their ISP offers native IPv6 support? Might be interesting for HE.net to make some kind of a study. :-) Cheers, Constantine. From mysidia at gmail.com Sat Dec 8 06:20:05 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 8 Dec 2012 00:20:05 -0600 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: Message-ID: On 12/7/12, Constantine A. Murenin wrote: [snip] It seems you have an issue with the automated system of one provider in your RIR service region. This is unusual, I think; for the provider to not ask what NIC handle, or WHOIS detail should be listed for an assignment. I would suggest calling up the provider, and attempt to work out a solution with them where you get a /64, and the contact you want listed in WHOIS. The provider suballocating a block of IP addresses, can obviously apply additional policy to them -- such as additional requirements on what is shown in WHOIS. However, you can pick a different provider if necessary...... -- -J From marka at isc.org Sat Dec 8 21:03:25 2012 From: marka at isc.org (Mark Andrews) Date: Sun, 09 Dec 2012 08:03:25 +1100 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: Your message of "Sat, 08 Dec 2012 00:20:05 MDT." References: Message-ID: <20121208210326.01E512CD2012@drugs.dv.isc.org> In message , Jimmy Hess writes: > On 12/7/12, Constantine A. Murenin wrote: > [snip] > > It seems you have an issue with the automated system of one provider > in your RIR service region. This is unusual, I think; for the > provider to not ask what NIC handle, or WHOIS detail should be > listed for an assignment. > I would suggest calling up the provider, and attempt to work out a > solution with them where you get a /64, and the contact you want > listed in WHOIS. > > The provider suballocating a block of IP addresses, can obviously > apply additional policy to them -- such as additional requirements > on what is shown in WHOIS. > > However, you can pick a different provider if necessary...... > > -- > -J It's also more than likely a hold over of IPv4 think where, generally, only companies are allocated address blocks. I would be ringing the ISP and talking to the staff escalating until you get to someone who understands the issue. Also a /64 is ridiculously small for a company and it really too small for individuals so it very much looks like this ISP hasn't applied enough thought to this area. Trail blazing is hard work but someone has to do it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mureninc at gmail.com Sat Dec 8 23:50:29 2012 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sat, 8 Dec 2012 15:50:29 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <20121208210326.01E512CD2012@drugs.dv.isc.org> References: <20121208210326.01E512CD2012@drugs.dv.isc.org> Message-ID: On 8 December 2012 13:03, Mark Andrews wrote: > It's also more than likely a hold over of IPv4 think where, generally, > only companies are allocated address blocks. I would be ringing > the ISP and talking to the staff escalating until you get to someone > who understands the issue. Also a /64 is ridiculously small for a > company and it really too small for individuals so it very much > looks like this ISP hasn't applied enough thought to this area. > Trail blazing is hard work but someone has to do it. This might be a good advice for a home or an office obtaining internet connectivity with a dynamic IP address or at a location remote from an he.net POP. However, it's not something that I am, as an individual renting a single server at a great price and only 5ms from Frankfurt, an HE.net POP, is willing to go through. Why go through all the hoops where HE's tunnelbroker.net already provides the same service, but with shorter addresses and better latency, and without any self-made RIPE-blamed headaches and extra rules? Also, specifically in regards to hetzner.de, if I'd like to switch from one of their servers to another, a tunnelbroker.net-issued address will let me have a seamless "failover", whereas a native IPv6 /64 from hetzner.de might have to be given up and obtained anew (and one might again have to go through all the hoops in order to obtain a new one). I've tried contacting their support through their web-interface, but they've repeatedly claimed that I've agreed to have my data provided to RIPE. ??? But then, again, I don't speak any German; and they, obviously, have to minimise their costs by a great deal of automation in order to keep their prices low. At this point, I don't see a single good reason of why I should continue bothering them, instead of simply using what already works great -- tunnelbroker.net. Frankly, the more I think about this, the less it's clear why someone like hetzner.de would actually want you to be using their native IPv6 support, instead of the one provided by HE.net through their free tunnelbroker.net service. HE has an open-peering policy (AFAIK); which basically means that tunnelbroker.net traffic is free for hetzner.de, whereas for native IPv6 traffic they might have to be paying for transit costs, depending on the destination. HE.net probably wins, too; since being the place-to-go-for-IPv6 might make it easier for them to have more settlement-free peering with big transit providers such as AT&T (Bay-Area-wise, they still have IPv6 traffic going through their peering in Los Angeles). C. From mail at danrl.de Sun Dec 9 00:12:18 2012 From: mail at danrl.de (Dan Luedtke) Date: Sun, 9 Dec 2012 01:12:18 +0100 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: <20121208210326.01E512CD2012@drugs.dv.isc.org> Message-ID: <20121209011218.77ef5425@tunafish> Hi, hmm, they get away with it once again. On the other hand their prices stay low. Off-topic but somehow important to me: > HE has an open-peering policy (AFAIK); > which basically means that tunnelbroker.net traffic is free for > hetzner.de Is that true? That would be great! Regards Dan From djahandarie at gmail.com Sun Dec 9 02:14:25 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Sat, 8 Dec 2012 21:14:25 -0500 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <20121209011218.77ef5425@tunafish> References: <20121208210326.01E512CD2012@drugs.dv.isc.org> <20121209011218.77ef5425@tunafish> Message-ID: On Sat, Dec 8, 2012 at 7:12 PM, Dan Luedtke wrote: > Off-topic but somehow important to me: >> HE has an open-peering policy (AFAIK); >> which basically means that tunnelbroker.net traffic is free for >> hetzner.de > > Is that true? > That would be great! Just because companies A and B don't have a customer relationship doesn't mean all their interactions with each other are free. So no, it's not true. Costs come from needing to buy bigger routers, bigger waves or fiber to the exchanges, bigger ports on the exchanges, etc. "Peering is a scam." -- Darius Jahandarie From patrick at ianai.net Sun Dec 9 03:23:00 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 8 Dec 2012 22:23:00 -0500 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: <20121208210326.01E512CD2012@drugs.dv.isc.org> <20121209011218.77ef5425@tunafish> Message-ID: <29EF8093-7C57-49B9-B65F-A6182D78C49C@ianai.net> On Dec 08, 2012, at 21:14 , Darius Jahandarie wrote: > On Sat, Dec 8, 2012 at 7:12 PM, Dan Luedtke wrote: >> Off-topic but somehow important to me: >>> HE has an open-peering policy (AFAIK); >>> which basically means that tunnelbroker.net traffic is free for >>> hetzner.de >> >> Is that true? >> That would be great! > > Just because companies A and B don't have a customer relationship > doesn't mean all their interactions with each other are free. > > So no, it's not true. Costs come from needing to buy bigger routers, > bigger waves or fiber to the exchanges, bigger ports on the exchanges, > etc. > > "Peering is a scam." The vast majority of AS-AS boundaries on the Internet are settlement free peering. I guess that makes the Internet a scam. As for the costs involved, "free" is a relative term. Most people think of peering as "free" because there is zero marginal cost. Kinda. Obviously if you think of your 10G IX port as a sunk cost, pushing 11 Gbps over it is not 'free' as you have to upgrade. But again, most people understand what is meant. Bigger waves & bigger routers are not due to peering, they are due to customer traffic - you know, the thing ISPs sell. Put another way, this is a Good Thing (tm). Or at least it should be. Unless, of course, you are trying to convince us all that selling too many units of your primary product is somehow bad. Peering allows you, in most cases, to lower the Cost Of Goods Sold on that product. Again, usually a Good Thing (tm). Unless you are again trying to convince us all that selling at a higher margin (we'll ignore the lower latency & better overall experience) is somehow bad. -- TTFN, patrick From mark at viviotech.net Sun Dec 9 06:55:46 2012 From: mark at viviotech.net (Mark Keymer) Date: Sat, 08 Dec 2012 22:55:46 -0800 Subject: Charter Issues in SE Washington State. Message-ID: <50C435F2.4050306@viviotech.net> Hi, Just wondering if there was anyone around that might know what is up with Charter Internet in South Eastern Washington State (Walla Walla / Tri-Cities). Could even be a larger area that is effected. As usual the normal support doesn't really know anything. On the plus side the lady I got a few hours ago was pleasant on the phone. I thought I would post here vs Outages as this issue is probably only effecting a small population. One which I live in and use them at home. (My datacenter and upstreams are not having issues that I know of) Sincerely, Mark From owen at delong.com Sun Dec 9 07:10:44 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 8 Dec 2012 23:10:44 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: <20121208210326.01E512CD2012@drugs.dv.isc.org> Message-ID: > Frankly, the more I think about this, the less it's clear why someone > like hetzner.de would actually want you to be using their native IPv6 > support, instead of the one provided by HE.net through their free > tunnelbroker.net service. HE has an open-peering policy (AFAIK); Yes, HE has a one-word peering policy? "YES!" However, that means that if hetzner peered IPv6 native with us, we would provide them every thing you get through tunnel broker still at no cost and without any limitations on bandwidth. We don't artificially limit the bandwidth on tunnel broker, but, each tunnel broker server has a single network interface that it hairpins the v4/v6 traffic on and the bandwidth is what it is. I don't expect that will be an issue any time soon, but for planning purposes, people should understand that tunnel broker is a where-is-as-is service on a best effort basis with no SLA. We do offer production grade tunnel services for a fee and people are welcome to contact me off-list for more information. > which basically means that tunnelbroker.net traffic is free for > hetzner.de, whereas for native IPv6 traffic they might have to be > paying for transit costs, depending on the destination. HE.net We would really rather see such traffic come native across our peering links as much as possible. It allows us to provide a higher quality of service. > probably wins, too; since being the place-to-go-for-IPv6 might make it > easier for them to have more settlement-free peering with big transit > providers such as AT&T (Bay-Area-wise, they still have IPv6 traffic > going through their peering in Los Angeles). Being a popular IPv6 peer and having so many tunnel broker users has been a great success story for us, yes. However, in terms of how this affects our standing for peering, I think that the effect is the same regardless of whether we are passing the traffic from/to a peering link or a tunnel broker. Owen From mureninc at gmail.com Sun Dec 9 07:32:21 2012 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sat, 8 Dec 2012 23:32:21 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <20121209011218.77ef5425@tunafish> References: <20121208210326.01E512CD2012@drugs.dv.isc.org> <20121209011218.77ef5425@tunafish> Message-ID: On 8 December 2012 16:12, Dan Luedtke wrote: > Hi, > > hmm, they get away with it once again. On the other hand their prices > stay low. > > Off-topic but somehow important to me: >> HE has an open-peering policy (AFAIK); >> which basically means that tunnelbroker.net traffic is free for >> hetzner.de > > Is that true? > That would be great! That's not actually off-topic, but the whole point of my thread: It's being implied everywhere that native IPv6 is somehow important to seek, since we're running out of IPv4 addresses. I myself have recently trolled on LowEndBox.com, annoying every new provider with a "it's 2012, do you support IPv6?"-style questions. Until I then signed up with a couple of such established providers that did clearly advertise "IPv6 support", and realised that, as long as there's tunnelbroker.net, "native IPv6" is nothing more than purely a marketing concept in situations where you are already getting a dedicated server (either virtual or physical) as setting up a reliable tunnel on such a server is just so damn easy, reliable, fast and hassle-free. I still think that native IPv6 is important for end-users at home and on the go from the operator's perspective (T-Mobile USA is practically ready to shutdown IPv4 w/ NAT44 and go with IPv6 + NAT64 + DNS64 + 464XLAT), but for individual servers close to an IX with HE.net, where all native IPv4/IPv6 traffic has to go through that very same Internet eXchange point anyways, native IPv6 can only be slower, more expensive, more insecure and less feature rich. And the providers have no incentives (quite the opposite, as I've contemplated above), since it's not like in the server room they could drop IPv4 support any time soon anyways -- no client would approve. In summary, I'd be very happy to try out hetzner.de's native IPv6 if they sort it out one day and will offer short, abbreviatable addresses, and without violating my privacy; until then, I'm very happy with their prices and being a proven shop, and still happy to be their customer with a bring-your-own IPv6 aka tunnelbroker.net. :-) C. From swmike at swm.pp.se Sun Dec 9 08:11:27 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 9 Dec 2012 09:11:27 +0100 (CET) Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: <20121208210326.01E512CD2012@drugs.dv.isc.org> <20121209011218.77ef5425@tunafish> Message-ID: On Sat, 8 Dec 2012, Constantine A. Murenin wrote: > It's being implied everywhere that native IPv6 is somehow important to > seek, since we're running out of IPv4 addresses. Ok, so I'll give you that tunneling a really short bit, tunneling isn't too bad, but native is most of the time better. 5+ years back we used to run 6bone for out IPv6 connectivity. It was hugely broken. As soon as we started running native ipv6 in the core and started peering natively, quality improved hugely. So yes, 6RD or alike where tunneling is done locally within the ISP or very close to it, is a valid deployment scenario, but middle/long term, native is better. And IPv6 is not a short term fix for IPv4 address runout, it's a long term solution for it. As humankind, we just failed to get it deployed in time for the long term solution to be widely available before we ran out of IPv4 addresses. -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Sun Dec 9 08:58:25 2012 From: randy at psg.com (Randy Bush) Date: Sun, 09 Dec 2012 17:58:25 +0900 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: <20121208210326.01E512CD2012@drugs.dv.isc.org> <20121209011218.77ef5425@tunafish> Message-ID: > reliable tunnel bzzzt! oxymoron alert!!! From bzs at world.std.com Sun Dec 9 16:39:06 2012 From: bzs at world.std.com (Barry Shein) Date: Sun, 9 Dec 2012 11:39:06 -0500 (EST) Subject: Possibly a little OT, has spam in theme Message-ID: <201212091639.qB9Gd6ZS029210@world.std.com> What is nifty.com? Is it legitimate? The web page is in Chinese. I noticed they were trying to do a lot of connects to our mail servers but were in the block list and seem to have been for years. So I opened it up because fool that I am I like to believe people mend their ways. It instantly began flooding us with spam, lottery-office at whatever, dictionary attacks, that kind of thing. So I blocked them again. I've never had a customer complaint about this block. It's making me lose faith in humanity, a little. Totally gratuitous internet governance snark: And they're meeting in Dubai because some countries believe they can be the new sheriff in town? HAH! We've got a hundred million teenagers with whiskey and loaded shotguns roaming the landscape and they think it's just a matter of showing a little authority from people with snappy new uniforms...good luck with that buckaroos! -- -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 tvest at eyeconomics.com Sun Dec 9 18:03:33 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Sun, 9 Dec 2012 13:03:33 -0500 Subject: Possibly a little OT, has spam in theme In-Reply-To: <201212091639.qB9Gd6ZS029210@world.std.com> References: <201212091639.qB9Gd6ZS029210@world.std.com> Message-ID: <33D69BDD-7C30-48D7-8ECE-97CBDC1F24BF@eyeconomics.com> Actually it's in Japanese. Nifty is one of the oldest (and at one time, largest) access services in Japan. It's owned by owned by Fujitsu. http://en.wikipedia.org/wiki/Nifty_Corporation http://www.nifty.co.jp/english/ From here it looks like it's originated by AS2510, which is also Fujistsu. So "it" is legitimate, even if the unwanted traffic your receiving is not. TV On Dec 9, 2012, at 11:39 AM, Barry Shein wrote: > > What is nifty.com? Is it legitimate? The web page is in Chinese. > > I noticed they were trying to do a lot of connects to our mail servers > but were in the block list and seem to have been for years. > > So I opened it up because fool that I am I like to believe people mend > their ways. > > It instantly began flooding us with spam, lottery-office at whatever, > dictionary attacks, that kind of thing. > > So I blocked them again. I've never had a customer complaint about > this block. > > It's making me lose faith in humanity, a little. > > > Totally gratuitous internet governance snark: > > And they're meeting in Dubai because some countries believe they can > be the new sheriff in town? HAH! We've got a hundred million > teenagers with whiskey and loaded shotguns roaming the landscape and > they think it's just a matter of showing a little authority from > people with snappy new uniforms...good luck with that buckaroos! > > -- > -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 dave at temk.in Sun Dec 9 19:32:57 2012 From: dave at temk.in (David Temkin) Date: Sun, 9 Dec 2012 14:32:57 -0500 Subject: Final Reminder: Call for Presentations: NANOG 57 in Orlando, FL Message-ID: NANOG Community, The North American Network Operators' Group (NANOG) will hold their 57th meeting in Orlando, FL on February 4th through the 6th. Of special note, this is the first meeting that will have a fully Monday through Wednesday agenda. Our host, CyrusOne is eagerly awaiting welcoming you to the Renaissance Orlando at SeaWorld. The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG 57 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet. Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. NANOG 57 submissions are welcome at http://pc.nanog.org For further information on what the Program Committee is seeking, please see http://www.nanog.org/meetings/nanog57/callforpresentations.html This will also be our first meeting after the 2012 WCIT in early December, and we expect topical and timely presentations regarding the results When considering submitting a presentation, keep these important dates in mind: Presentation Abstracts and Draft Slides Due: 10-December-2012 Final Slides Due: 7-January-2013 Draft Program Published: 14-January-2013 Final Agenda Published: 18-January-2013 Please submit your materials to http://pc.nanog.org Looking forward to seeing everyone in Orlando! -Dave Temkin From Dave.Siegel at level3.com Sun Dec 9 22:17:55 2012 From: Dave.Siegel at level3.com (Siegel, David) Date: Sun, 9 Dec 2012 22:17:55 +0000 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <29EF8093-7C57-49B9-B65F-A6182D78C49C@ianai.net> References: <20121208210326.01E512CD2012@drugs.dv.isc.org> <20121209011218.77ef5425@tunafish> <29EF8093-7C57-49B9-B65F-A6182D78C49C@ianai.net> Message-ID: <72A2F9AF18EC024C962A748EA6CF75B90EE0A9F5@W8USSFJ204.ams.gblxint.com> That's a really good point, Patrick. We've received an interesting analysis from our customers recently where they reviewed the accounting on all the services they need in order to peer off approximately 1/3rd of their total traffic. They took their national wavelength cost, local access, colocation at carrier-neutral facilities at it came to roughly $.95/mbps. Although this is considerably less than what they spend on transit, their analysis failed to consider depreciation on their capital (routers and other hardware), associated warranty costs and the incremental operational overhead to operate a large national network. When all is said and done, they are probably spending as much on "free peering" as they are on transit. In the case of this customer they would have a lower total cost by simply staying regional and purchasing transit. In other cases, peering will only lower your marginal cost if there are strategic reasons for building and maintaining that backbone. Dave -----Original Message----- From: Patrick W. Gilmore [mailto:patrick at ianai.net] Sent: Saturday, December 08, 2012 8:23 PM To: NANOG list Subject: Re: Why do some providers require IPv6 /64 PA space to have public whois? > So no, it's not true. Costs come from needing to buy bigger routers, > bigger waves or fiber to the exchanges, bigger ports on the exchanges, > etc. > > "Peering is a scam." The vast majority of AS-AS boundaries on the Internet are settlement free peering. I guess that makes the Internet a scam. As for the costs involved, "free" is a relative term. Most people think of peering as "free" because there is zero marginal cost. Kinda. Obviously if you think of your 10G IX port as a sunk cost, pushing 11 Gbps over it is not 'free' as you have to upgrade. But again, most people understand what is meant. Bigger waves & bigger routers are not due to peering, they are due to customer traffic - you know, the thing ISPs sell. Put another way, this is a Good Thing (tm). Or at least it should be. Unless, of course, you are trying to convince us all that selling too many units of your primary product is somehow bad. Peering allows you, in most cases, to lower the Cost Of Goods Sold on that product. Again, usually a Good Thing (tm). Unless you are again trying to convince us all that selling at a higher margin (we'll ignore the lower latency & better overall experience) is somehow bad. -- TTFN, patrick From chris at nifry.com Sun Dec 9 22:26:11 2012 From: chris at nifry.com (Chris Russell) Date: Sun, 09 Dec 2012 22:26:11 +0000 Subject: Possibly a little OT, has spam in theme In-Reply-To: <33D69BDD-7C30-48D7-8ECE-97CBDC1F24BF@eyeconomics.com> References: <201212091639.qB9Gd6ZS029210@world.std.com> <33D69BDD-7C30-48D7-8ECE-97CBDC1F24BF@eyeconomics.com> Message-ID: > Actually it's in Japanese. Nifty is one of the oldest (and at one > > From here it looks like it's originated by AS2510, which is also > Fujistsu. > > So "it" is legitimate, even if the unwanted traffic your receiving is > not. Owning and using a domain name with 1 character difference from Nifty, its amazing what I used to receive via the catch-all. One of the many reasons I turned it off, ultimately. Chris From djahandarie at gmail.com Sun Dec 9 22:40:28 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Sun, 9 Dec 2012 17:40:28 -0500 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <29EF8093-7C57-49B9-B65F-A6182D78C49C@ianai.net> References: <20121208210326.01E512CD2012@drugs.dv.isc.org> <20121209011218.77ef5425@tunafish> <29EF8093-7C57-49B9-B65F-A6182D78C49C@ianai.net> Message-ID: On Sat, Dec 8, 2012 at 10:23 PM, Patrick W. Gilmore wrote: > The vast majority of AS-AS boundaries on the Internet are settlement free peering. I guess that makes the Internet a scam. > > As for the costs involved, "free" is a relative term. Most people think of peering as "free" because there is zero marginal cost. Kinda. Obviously if you think of your 10G IX port as a sunk cost, pushing 11 Gbps over it is not 'free' as you have to upgrade. But again, most people understand what is meant. > > Bigger waves & bigger routers are not due to peering, they are due to customer traffic - you know, the thing ISPs sell. Put another way, this is a Good Thing (tm). Or at least it should be. Unless, of course, you are trying to convince us all that selling too many units of your primary product is somehow bad. > > Peering allows you, in most cases, to lower the Cost Of Goods Sold on that product. Again, usually a Good Thing (tm). Unless you are again trying to convince us all that selling at a higher margin (we'll ignore the lower latency & better overall experience) is somehow bad. The quote was tongue-in-cheek, of course. I don't agree that "most people understand what is meant". I can't count the number of companies that unnecessarily get waves to exchanges and colocate there because they think peering there will reduce their costs, when it does not. I was not trying to argue that more traffic is bad. I'm just trying to argue that there are certain (often neglected) costs that you would only have with peering that you could avoid when not peering, and that it's more than just the exchange port. Also, it's a different topic, but I really don't think "tier 3s" (sigh) peering on public exchanges increases quality generally. It (usually) does decrease latency, but there is generally a lack of redundancy in most peering setups that is glaring when there is a failure somewhere. Of course, if you're a very competent network operator, you can have lots of redundancy for your peering, both at the edge and internally (in terms of doing the traffic engineering needed when you have lots of different paths traffic can take), but I'd say this is not the sort of setup a standard regional operator would have. -- Darius Jahandarie From sander at steffann.nl Mon Dec 10 00:13:52 2012 From: sander at steffann.nl (Sander Steffann) Date: Mon, 10 Dec 2012 01:13:52 +0100 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: <20121208210326.01E512CD2012@drugs.dv.isc.org> <20121209011218.77ef5425@tunafish> Message-ID: <19252C31-EB10-40CC-A5D8-BFBAF53C6E65@steffann.nl> Hi, > Ok, so I'll give you that tunneling a really short bit, tunneling isn't too bad, but native is most of the time better. So sad that some companies mess up in such a way that their customers rather tunnel than use their native infra... :-( - Sander From malayter at gmail.com Mon Dec 10 00:54:23 2012 From: malayter at gmail.com (Ryan Malayter) Date: Sun, 9 Dec 2012 18:54:23 -0600 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: <20121208210326.01E512CD2012@drugs.dv.isc.org> <20121209011218.77ef5425@tunafish> Message-ID: <8B309A82-BD53-4023-8E80-01C21101AB96@gmail.com> On Dec 9, 2012, at 2:58 AM, Randy Bush wrote: >> reliable tunnel > > bzzzt! oxymoron alert!!! > Intellectually I want to agree with you, but after some reflection... We use lots of tunnels at my org - the IPsec variety. A quick non-scientific query of our monitoring logs reveals that our tunnels are exactly as reliable as the circuits and routers which underneath them. MTU issues aren't really a problem for us either, but then again we do control all the devices at at least one end if the tunnel. I defer to your experience and reputation Randy, and im syre you're right. But where are all these horrifically unreliable tunnels? From randy at psg.com Mon Dec 10 02:06:21 2012 From: randy at psg.com (Randy Bush) Date: Mon, 10 Dec 2012 11:06:21 +0900 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <8B309A82-BD53-4023-8E80-01C21101AB96@gmail.com> References: <20121208210326.01E512CD2012@drugs.dv.isc.org> <20121209011218.77ef5425@tunafish> <8B309A82-BD53-4023-8E80-01C21101AB96@gmail.com> Message-ID: >>> reliable tunnel >> bzzzt! oxymoron alert!!! > We use lots of tunnels at my org - the IPsec variety. as does iij, very heavily. and it has some issues. > A quick non-scientific query of our monitoring logs reveals that our > tunnels are exactly as reliable as the circuits and routers which > underneath them. > I defer to your experience and reputation that would be almost as foolish as i am there is significant measurement and screaming showing the issues with v6 tunnel connectivity. geoff, of course. and then a bunch of us have been burned at conferences where the v6 was tunneled. yes, it can be better than no v6 at all. but we're well beyond the days where we bet our businesses on tuneled v6 transport. randy From swmike at swm.pp.se Mon Dec 10 03:28:56 2012 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 10 Dec 2012 04:28:56 +0100 (CET) Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <8B309A82-BD53-4023-8E80-01C21101AB96@gmail.com> References: <20121208210326.01E512CD2012@drugs.dv.isc.org> <20121209011218.77ef5425@tunafish> <8B309A82-BD53-4023-8E80-01C21101AB96@gmail.com> Message-ID: On Sun, 9 Dec 2012, Ryan Malayter wrote: > But where are all these horrifically unreliable tunnels? 6to4 is one example. I'd say since PMTUD is too often broken on IPv4 (if the tunneling routers even react properly to PMTUD need-to-frag messages for their tunnel packets) in combination with some ISPs supporting jumbo frames internally, makes a lot of tunneling work badly. So you might use tunnel broker tunnels that handle tunnel packet fragmentation for 1500 byte payload over 1500 byte infrastructure and that makes you feel they are reliable. My tunnels to my home where I run routing protocol over the tunnels to two separate tunnel routers at the ISP end (I control all endpoints) plus running ipv6 MTU 1400 in my home to avoid PTMUD for all TCP connections is also a very reliable setup, but I'd rather have native IPv6 and 1500 MTU end-to-end. -- Mikael Abrahamsson email: swmike at swm.pp.se From steve.bertrand at amayagaming.com Mon Dec 10 00:21:20 2012 From: steve.bertrand at amayagaming.com (Steve Bertrand) Date: Mon, 10 Dec 2012 00:21:20 +0000 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <19252C31-EB10-40CC-A5D8-BFBAF53C6E65@steffann.nl> References: <20121208210326.01E512CD2012@drugs.dv.isc.org> <20121209011218.77ef5425@tunafish> <19252C31-EB10-40CC-A5D8-BFBAF53C6E65@steffann.nl> Message-ID: <780A28F50E2834489278DD3B512FE71637F06C@CAQCCOHVEX01.corp.amayagaming.com> > > Ok, so I'll give you that tunneling a really short bit, tunneling > isn't too bad, but native is most of the time better. > > So sad that some companies mess up in such a way that their > customers rather tunnel than use their native infra... :-( The ISPs are unfortunately behind what the tunnel providers have supplied. It is what it is. Even 'companies' who were told by early adopters and said "we should focus" didn't. The result is :) Steve From naitluzar at gmail.com Mon Dec 10 13:22:41 2012 From: naitluzar at gmail.com (Vasile Borcan) Date: Mon, 10 Dec 2012 15:22:41 +0200 Subject: Solutions for DoS & DDoS In-Reply-To: <0D89D80C-D288-402F-8723-B837EA52313C@gmail.com> References: <0D89D80C-D288-402F-8723-B837EA52313C@gmail.com> Message-ID: Try the DDoS attacks detection and mitigation software named WANGUARD from http://www.andrisoft.com. It's not expensive and non-profit organisations like you are granted with a 30% discount. Install it on a Linux server and you'll have DDoS attacks detection in no time. Since you're not a carrier the DDoS scrubbing feature won't be useful to you, but the black hole routing probably will. You can also configure it to send alerts to your upstream carrier or to your attackers' ISPs. On Thu, Dec 6, 2012 at 7:51 PM, Mike Gatti wrote: > Hello Everyone, > > I'm assisting a non-profit organization to research solutions to secure their network from DOS/DDOS attacks. So far we have gone the route of discussing with their ISP's to see what solutions they have to offer, believing that the carriers are better positioned to block the attack from the source. > > I wanted to get the lists thoughts on our approach going the carrier route and/or hear about successful implementation of other solutions. > > Thanks, > -- > Michael Gatti > 949.371.5474 > (UTC -8) > > > > From apishdadi at gmail.com Mon Dec 10 14:33:29 2012 From: apishdadi at gmail.com (Ameen Pishdadi) Date: Mon, 10 Dec 2012 08:33:29 -0600 Subject: Solutions for DoS & DDoS In-Reply-To: References: <0D89D80C-D288-402F-8723-B837EA52313C@gmail.com> Message-ID: <34F5F55F-2B8D-46DB-A340-2BC1CA7A237D@gmail.com> Sounds like an advertisement to me Thanks, Ameen Pishdadi On Dec 10, 2012, at 7:22 AM, Vasile Borcan wrote: > Try the DDoS attacks detection and mitigation software named WANGUARD > from http://www.andrisoft.com. It's not expensive and non-profit > organisations like you are granted with a 30% discount. Install it on > a Linux server and you'll have DDoS attacks detection in no time. > Since you're not a carrier the DDoS scrubbing feature won't be useful > to you, but the black hole routing probably will. You can also > configure it to send alerts to your upstream carrier or to your > attackers' ISPs. > > On Thu, Dec 6, 2012 at 7:51 PM, Mike Gatti wrote: >> Hello Everyone, >> >> I'm assisting a non-profit organization to research solutions to secure their network from DOS/DDOS attacks. So far we have gone the route of discussing with their ISP's to see what solutions they have to offer, believing that the carriers are better positioned to block the attack from the source. >> >> I wanted to get the lists thoughts on our approach going the carrier route and/or hear about successful implementation of other solutions. >> >> Thanks, >> -- >> Michael Gatti >> 949.371.5474 >> (UTC -8) > From morrowc.lists at gmail.com Mon Dec 10 14:47:58 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 10 Dec 2012 09:47:58 -0500 Subject: Solutions for DoS & DDoS In-Reply-To: <34F5F55F-2B8D-46DB-A340-2BC1CA7A237D@gmail.com> References: <0D89D80C-D288-402F-8723-B837EA52313C@gmail.com> <34F5F55F-2B8D-46DB-A340-2BC1CA7A237D@gmail.com> Message-ID: On Mon, Dec 10, 2012 at 9:33 AM, Ameen Pishdadi wrote: > Sounds like an advertisement to me In the end there are few actual options (in general): 1) do it yourself 2) have your carrier do it for you 3) have a third party do it for you There are cost and capability considerations with all of these, basically: 1: - you'll need more pipe - absorb all that can arrive, can you handle an extra 100gbps of traffic? (or less, you could reasonably build out for X gbps and just die under Y if the cost is unacceptably large to absorb Y) - more people-smarts - understand what is/isn't an attack, understand peering, transit, costs, complexities, mitigation techniques and costs involved. - more equipment - mitigation gear (cisco guard, arbor tms, radware...etc) 2: - monthly (most times) cost for 'insurance', imagine paying an uplift on your current bandwidth costs, for mitigation services, pre-prepared, so all you need to is 'initiate mitigation' inside the carrier's network. - people-cost in training to 'make the mitigation happen' (done right at the carrier this is nothing more than a bgp update from you...) 3: - monthly (or one-time) cost, you may be able to initiate it one-time and walk away, with the attendant costs in management of adhoc contracts/etc. - routing changes (do you control at least the /24 around the resource you need to mitigate?) - tunneling complexity to return to you the 'clean' traffic - dns shennigans for those ddos-mitigation folks who don't do routing change, or prefer DNS ones. pick what works for you... or your charity org. -chris From source_route at yahoo.com Mon Dec 10 16:56:50 2012 From: source_route at yahoo.com (Philip Lavine) Date: Mon, 10 Dec 2012 08:56:50 -0800 (PST) Subject: gmail offline? Message-ID: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> getting a 502 error From alter3d at alter3d.ca Mon Dec 10 17:00:18 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Mon, 10 Dec 2012 12:00:18 -0500 Subject: gmail offline? In-Reply-To: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> References: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: <50C61522.4070506@alter3d.ca> I'm getting the same thing when I try to access the web interface, but SMTP & IMAP seem to be working fine at the moment. - Peter On 12/10/2012 11:56 AM, Philip Lavine wrote: > getting a 502 error From lathama at gmail.com Mon Dec 10 17:01:15 2012 From: lathama at gmail.com (Andrew Latham) Date: Mon, 10 Dec 2012 12:01:15 -0500 Subject: gmail offline? In-Reply-To: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> References: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: On Mon, Dec 10, 2012 at 11:56 AM, Philip Lavine wrote: > getting a 502 error Some network issues on a normal Monday morning. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From tbeecher at localnet.com Mon Dec 10 17:06:01 2012 From: tbeecher at localnet.com (Tom Beecher) Date: Mon, 10 Dec 2012 12:06:01 -0500 Subject: gmail offline? In-Reply-To: <50C61522.4070506@alter3d.ca> References: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> <50C61522.4070506@alter3d.ca> Message-ID: <50C61679.4070505@localnet.com> Web interface for Gmail/GChat seems to be the culprit. My email and chat clients that don't use the web interface seem pretty uneffected. It's Google. They'll straighten it out quick enough. On 12/10/2012 12:00 PM, Peter Kristolaitis wrote: > I'm getting the same thing when I try to access the web interface, but > SMTP & IMAP seem to be working fine at the moment. > > - Peter > > > On 12/10/2012 11:56 AM, Philip Lavine wrote: >> getting a 502 error From blake at pfankuch.me Mon Dec 10 17:05:24 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Mon, 10 Dec 2012 17:05:24 +0000 Subject: gmail offline? In-Reply-To: <50C61522.4070506@alter3d.ca> References: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> <50C61522.4070506@alter3d.ca> Message-ID: Just loaded for me, however quite a bit slower than normal. -----Original Message----- From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] Sent: Monday, December 10, 2012 10:00 AM To: nanog at nanog.org Subject: Re: gmail offline? I'm getting the same thing when I try to access the web interface, but SMTP & IMAP seem to be working fine at the moment. - Peter On 12/10/2012 11:56 AM, Philip Lavine wrote: > getting a 502 error From lathama at gmail.com Mon Dec 10 17:06:58 2012 From: lathama at gmail.com (Andrew Latham) Date: Mon, 10 Dec 2012 12:06:58 -0500 Subject: gmail offline? In-Reply-To: <50C61522.4070506@alter3d.ca> References: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> <50C61522.4070506@alter3d.ca> Message-ID: On Mon, Dec 10, 2012 at 12:00 PM, Peter Kristolaitis wrote: > I'm getting the same thing when I try to access the web interface, but SMTP > & IMAP seem to be working fine at the moment. > > - Peter This email sent via the Web interface... Trying to track down the issue now. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From shortdudey123 at gmail.com Mon Dec 10 17:08:01 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Mon, 10 Dec 2012 11:08:01 -0600 Subject: gmail offline? In-Reply-To: References: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: Not seeing any issues from a TWTC circuit in Milwaukee, Wi. -Grant On Mon, Dec 10, 2012 at 11:01 AM, Andrew Latham wrote: > On Mon, Dec 10, 2012 at 11:56 AM, Philip Lavine > wrote: > > getting a 502 error > > Some network issues on a normal Monday morning. > > -- > ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ > > From hank at efes.iucc.ac.il Mon Dec 10 17:09:33 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 10 Dec 2012 19:09:33 +0200 (IST) Subject: gmail offline? In-Reply-To: References: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: In Israel as well. -Hank On Mon, 10 Dec 2012, Andrew Latham wrote: > On Mon, Dec 10, 2012 at 11:56 AM, Philip Lavine wrote: >> getting a 502 error > > Some network issues on a normal Monday morning. > > -- > ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ > From shortdudey123 at gmail.com Mon Dec 10 17:15:16 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Mon, 10 Dec 2012 11:15:16 -0600 Subject: gmail offline? In-Reply-To: <50C61679.4070505@localnet.com> References: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> <50C61522.4070506@alter3d.ca> <50C61679.4070505@localnet.com> Message-ID: I stand corrected, the web interface just stopped working with a 502 error Sent from my iPhone On Dec 10, 2012, at 11:06 AM, Tom Beecher wrote: > Web interface for Gmail/GChat seems to be the culprit. My email and chat clients that don't use the web interface seem pretty uneffected. > > It's Google. They'll straighten it out quick enough. > > On 12/10/2012 12:00 PM, Peter Kristolaitis wrote: >> I'm getting the same thing when I try to access the web interface, but SMTP & IMAP seem to be working fine at the moment. >> >> - Peter >> >> >> On 12/10/2012 11:56 AM, Philip Lavine wrote: >>> getting a 502 error > > From derek at derekivey.com Mon Dec 10 17:18:34 2012 From: derek at derekivey.com (Derek Ivey) Date: Mon, 10 Dec 2012 12:18:34 -0500 Subject: gmail offline? In-Reply-To: References: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: Seems to be working again. On Mon, Dec 10, 2012 at 12:08 PM, Grant Ridder wrote: > Not seeing any issues from a TWTC circuit in Milwaukee, Wi. > > -Grant > > On Mon, Dec 10, 2012 at 11:01 AM, Andrew Latham wrote: > > > On Mon, Dec 10, 2012 at 11:56 AM, Philip Lavine > > wrote: > > > getting a 502 error > > > > Some network issues on a normal Monday morning. > > > > -- > > ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ > > > > > From jayfar at jayfar.com Mon Dec 10 17:19:55 2012 From: jayfar at jayfar.com (Jay Farrell) Date: Mon, 10 Dec 2012 12:19:55 -0500 Subject: gmail offline? In-Reply-To: References: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> <50C61522.4070506@alter3d.ca> Message-ID: It's been up and down for at least the past 20 minutes. Amusingly some of the isitdown sites are sporadic as a result of so many people checking to see if gmail is down. I'm reading/sending this via the gmail web interface now though. On Mon, Dec 10, 2012 at 12:06 PM, Andrew Latham wrote: > On Mon, Dec 10, 2012 at 12:00 PM, Peter Kristolaitis > wrote: > > I'm getting the same thing when I try to access the web interface, but > SMTP > > & IMAP seem to be working fine at the moment. > > > > - Peter > > This email sent via the Web interface... Trying to track down the issue > now. > > -- > ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ > > From tony.mccrory at gmail.com Mon Dec 10 17:32:53 2012 From: tony.mccrory at gmail.com (Tony McCrory) Date: Mon, 10 Dec 2012 17:32:53 +0000 Subject: gmail offline? In-Reply-To: References: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> Message-ID: Reading this just fine from the UK on GMail web interface. On 10 December 2012 17:18, Derek Ivey wrote: > Seems to be working again. > > > On Mon, Dec 10, 2012 at 12:08 PM, Grant Ridder >wrote: > > > Not seeing any issues from a TWTC circuit in Milwaukee, Wi. > > > > -Grant > > > > On Mon, Dec 10, 2012 at 11:01 AM, Andrew Latham > wrote: > > > > > On Mon, Dec 10, 2012 at 11:56 AM, Philip Lavine < > source_route at yahoo.com> > > > wrote: > > > > getting a 502 error > > > > > > Some network issues on a normal Monday morning. > > > > > > -- > > > ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ > > > > > > > > > From knife at toaster.net Mon Dec 10 17:55:55 2012 From: knife at toaster.net (Sean Lazar) Date: Mon, 10 Dec 2012 09:55:55 -0800 Subject: gmail offline? In-Reply-To: References: <1355158610.88324.YahooMailNeo@web121701.mail.ne1.yahoo.com> <50C61522.4070506@alter3d.ca> Message-ID: <50C6222B.6050409@toaster.net> It seems like gmail web interface is working for some, but not others. http://www.google.com/appsstatus On 12/10/12 9:19 AM, Jay Farrell wrote: > It's been up and down for at least the past 20 minutes. Amusingly some of > the isitdown sites are sporadic as a result of so many people checking to > see if gmail is down. I'm reading/sending this via the gmail web interface > now though. > > > On Mon, Dec 10, 2012 at 12:06 PM, Andrew Latham wrote: > >> On Mon, Dec 10, 2012 at 12:00 PM, Peter Kristolaitis >> wrote: >>> I'm getting the same thing when I try to access the web interface, but >> SMTP >>> & IMAP seem to be working fine at the moment. >>> >>> - Peter >> This email sent via the Web interface... Trying to track down the issue >> now. >> >> -- >> ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ >> >> > From heather.schiller at verizon.com Mon Dec 10 21:27:20 2012 From: heather.schiller at verizon.com (Schiller, Heather A) Date: Mon, 10 Dec 2012 16:27:20 -0500 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: Message-ID: Actually, requiring a public whois record is the way it always has been, that's only recently changed. I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: IPv6 /64 So, while you are right, that swip'ing a v4 /32 has never been required, I think your analogy of a v6 /64 to a v4 /32 is off. The minimum assignment requiring a swip is also ensconced in RIR policy. If you don't like it, may I suggest you propose policy to change it? RIPE's policy: " When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users." Note the *may* -- ISP's aren't required to support it. More RIPE policy.. "When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register these assignments in the appropriate RIR database. These registrations can either be made as individual assignments or by inserting a object with a status value of 'AGGREGATED-BY-LIR' where the assignment-size attribute contains the size of the individual assignments made to End Users.When more than a /48 is assigned to an organisation, it must be registered in the database as a separate object with status 'ASSIGNED'." So they have to register it, and they get a choice about how they do it.. Your provider has chosen a way you don't like. Talk to them about it, rather than complaining on NANOG? It's pretty similar in the ARIN region. In 2004, the ARIN community passed the residential customer privacy policy - specifically allowing ISP's to designate a record private. Again, it's optional. https://www.arin.net/policy/nrpm.html Min assignment swip 6.5.5.1. Reassignment information Each static IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. IPv4 4.2.3.7.3.2. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers holding /29 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS directory record for that block. IPv6 6.5.5.3. Residential Subscribers 6.5.5.3.1. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers holding /64 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. --Heather -----Original Message----- From: Constantine A. Murenin [mailto:mureninc at gmail.com] Sent: Saturday, December 08, 2012 12:46 AM To: nanog at nanog.org Subject: Why do some providers require IPv6 /64 PA space to have public whois? Hello, I personally don't understand this policy. I've signed up with hetzner.de, and I'm trying to get IPv6; however, on the supplementary page where the complementary IPv6 /64 subnet can be requested (notice that it's not even a /48, and not even the second, routed, /64), after I change the selection from requesting one additional IPv4 address to requesting the IPv6 /64 subnet (they offer no other IPv6 options in that menu), they use DOM to remove the IP address justification field ("Purpose of use"), and instead statically show my name, physical street address (including the apartment number), email address and phone number, and ask to confirm that all of this information can be submitted to RIPE. They offer no option of modifying any of this; they also offer no option of hiding the street address and showing it as "Private Address" instead; they also offer no option of providing contact information different from the contact details for the main profile or keeping a separate set of contact details in the main profile specifically for RIPE; they also offer no option of providing a RIPE handle instead (dunno if one can be registered with a "Private Address" address, showing only city/state/country and postal code; I do know that with ARIN and PA IPv4 subnets you can do "Private Address" in the Address field); they also don't let you submit the form unless you agree for the information shown to be passed along to RIPE for getting IPv6 connectivity (again, no IPv6 is provided by default or otherwise). Is this what we're going towards? No probable cause and no court orders for obtaining individually identifying information about internet customers with IPv6 addresses? In the future, will the copyright trolls be getting this information directly from public whois, bypassing the internet provider abuse teams and even the most minimal court supervision? Is this really the disadvantage of IPv4 that IPv6 proudly fixes? I certainly have never heard of whois entries for /32 IPv4 address allocations! Anyhow, just one more provider where it's easier to use HE's tunnelbroker.net instead of obtaining IPv6 natively; due to the data-mining and privacy concerns now. What's the point of native IPv6 connectivity again? In hetzner.de terms, tunnelbroker.net even provides you with the failover IPv6 address(es), something that they themselves only offer for IPv4! Is it just me, or are there a lot of other folks who use tunnelbroker.net even when their ISP offers native IPv6 support? Might be interesting for HE.net to make some kind of a study. :-) Cheers, Constantine. From dougb at dougbarton.us Mon Dec 10 22:04:52 2012 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 10 Dec 2012 14:04:52 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: Message-ID: <50C65C84.6080203@dougbarton.us> On 12/10/2012 01:27 PM, Schiller, Heather A wrote: > I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: IPv6 /64 Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 in IPv4. As in, it's the smallest possible assignment that will allow an end-user host to function under normal circumstances. SWIP or rwhois for a /64 seems excessive to me, FWIW. Doug From randy at psg.com Mon Dec 10 23:00:47 2012 From: randy at psg.com (Randy Bush) Date: Tue, 11 Dec 2012 08:00:47 +0900 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: Message-ID: > IPv4 /32 :: IPv6 /128 i.e. a single host or gkw behind a nat. kinda what i get from comcast and twt now. > IPv4 /29 :: IPv6 /64 i.e. i get a lan segment. makes sense > The minimum assignment requiring a swip is also ensconced in RIR > policy. i am sure that, if you dig deeply enough, a recipe for chocolate chip cookies is ensconced in RIR policy. the bookkeepers drank koolaid and think they have become regulators. does samantha know her mom is a wannabe lawyer? :) randy From marka at isc.org Mon Dec 10 23:02:53 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 11 Dec 2012 10:02:53 +1100 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: Your message of "Mon, 10 Dec 2012 14:04:52 -0800." <50C65C84.6080203@dougbarton.us> References: <50C65C84.6080203@dougbarton.us> Message-ID: <20121210230253.8BEE82CE0B5D@drugs.dv.isc.org> In message <50C65C84.6080203 at dougbarton.us>, Doug Barton writes: > On 12/10/2012 01:27 PM, Schiller, Heather A wrote: > > I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: I > Pv6 /64 > > Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 > in IPv4. As in, it's the smallest possible assignment that will allow an > end-user host to function under normal circumstances. > > SWIP or rwhois for a /64 seems excessive to me, FWIW. > > Doug Even SWIP for a /48 for a residential assignment is excessive. SWIP for a /48 for a commercial assignment is reasonable Note it is the type of assignment, not the size, which is determining factor here. A /64 commercial assignment should have a SWIP entry. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joly at punkcast.com Mon Dec 10 23:06:31 2012 From: joly at punkcast.com (Joly MacFie) Date: Mon, 10 Dec 2012 18:06:31 -0500 Subject: facebook down Message-ID: I know there's an outages list, but seriously! It seems like a DNS prob? -- --------------------------------------------------------------- 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 owen at delong.com Mon Dec 10 23:14:09 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Dec 2012 15:14:09 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <50C65C84.6080203@dougbarton.us> References: <50C65C84.6080203@dougbarton.us> Message-ID: <010828F3-8EFE-466F-8787-4DF1C61C8D5B@delong.com> Sent from my iPad On Dec 10, 2012, at 2:04 PM, Doug Barton wrote: > On 12/10/2012 01:27 PM, Schiller, Heather A wrote: >> I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: IPv6 /64 > > Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 > in IPv4. As in, it's the smallest possible assignment that will allow an > end-user host to function under normal circumstances. No, you could be assigned a /128 and have it function for a single host. However, let's not start doing that as it's pretty brain-dead and the reality is that hardly anyone has a single host any more. Heather has the corollaries correct. > SWIP or rwhois for a /64 seems excessive to me, FWIW. I'm not sure I disagree, but, I certainly don't feel strongly enough about it to submit a policy proposal. I will say that you are far more likely to get this changed by submitting a policy proposal than you are by complaining to NANOG about it. Owen From I.Smith at F5.com Mon Dec 10 22:53:42 2012 From: I.Smith at F5.com (Ian Smith) Date: Mon, 10 Dec 2012 22:53:42 +0000 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <50C65C84.6080203@dougbarton.us> References: <50C65C84.6080203@dougbarton.us> Message-ID: <419417C345CA5F48BF45F0A23955A0633642B8A2@SEAEMBX02.olympus.F5Net.com> >Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 in IPv4. As in, it's the smallest possible assignment that will allow an end-user host to >function under normal circumstances. >SWIP or rwhois for a /64 seems excessive to me, FWIW. IPv4/32 is both a routing endpoint and a host. IPv4 is a 32 bit combined routing and host space. IPv6/64 is a routing endpoint and v6/128 is a host. IPv6 is a 64 bit routing space and also a 64 bit host space for each routing space, not a 128 bit combined routing and host space. Evidently, the whois requirement is for networks, not nodes, which makes sense when you think about how the entity that controls a /64 is assuming responsibility for 2^64 network nodes. -----Original Message----- From: Doug Barton [mailto:dougb at dougbarton.us] Sent: Monday, December 10, 2012 5:05 PM To: Schiller, Heather A Cc: Constantine A. Murenin; nanog at nanog.org Subject: Re: Why do some providers require IPv6 /64 PA space to have public whois? On 12/10/2012 01:27 PM, Schiller, Heather A wrote: > I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 > :: IPv6 /64 Doug ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2793 / Virus Database: 2634/5946 - Release Date: 12/08/12 From owen at delong.com Mon Dec 10 23:17:41 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Dec 2012 15:17:41 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <20121210230253.8BEE82CE0B5D@drugs.dv.isc.org> References: <50C65C84.6080203@dougbarton.us> <20121210230253.8BEE82CE0B5D@drugs.dv.isc.org> Message-ID: <272782D1-8DEA-4718-9429-8B0505DD30BD@delong.com> Sent from my iPad On Dec 10, 2012, at 3:02 PM, Mark Andrews wrote: > > In message <50C65C84.6080203 at dougbarton.us>, Doug Barton writes: >> On 12/10/2012 01:27 PM, Schiller, Heather A wrote: >>> I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: I >> Pv6 /64 >> >> Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 >> in IPv4. As in, it's the smallest possible assignment that will allow an >> end-user host to function under normal circumstances. >> >> SWIP or rwhois for a /64 seems excessive to me, FWIW. >> >> Doug > > Even SWIP for a /48 for a residential assignment is excessive. > SWIP for a /48 for a commercial assignment is reasonable > I disagree. SWIP for a /48 with the appropriate notations under residential customer privacy policy provides a good balance between the need for public accountability of resource utilization and privacy concerns for residential customer assignments. Owen From wbailey at satelliteintelligencegroup.com Mon Dec 10 23:23:37 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 10 Dec 2012 23:23:37 +0000 Subject: facebook down In-Reply-To: References: Message-ID: In other news, productivity in the workplace hit an all time high. High Schools around the nation are reporting dozens of potential suicide threats, citing the inability to announce their current location. Millions of farms are unattended, which may lead to a widespread shortage of virtual corn and grapes. >From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Joly MacFie Date: 12/10/2012 3:09 PM (GMT-08:00) To: North American Network Operators Group Subject: facebook down I know there's an outages list, but seriously! It seems like a DNS prob? -- --------------------------------------------------------------- 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 yang.yu.list at gmail.com Mon Dec 10 23:34:01 2012 From: yang.yu.list at gmail.com (Yang Yu) Date: Mon, 10 Dec 2012 18:34:01 -0500 Subject: facebook down In-Reply-To: References: Message-ID: I noticed Google Public DNS was returning ServerFail for www.facebook.com A earlier around 6pm EST ; AAAA, NS records were fine. Now DNS problem is solved but web still does not work. On Mon, Dec 10, 2012 at 6:06 PM, Joly MacFie wrote: > I know there's an outages list, but seriously! > > It seems like a DNS prob? > > > > -- > --------------------------------------------------------------- > 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 owen at delong.com Mon Dec 10 23:58:46 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 10 Dec 2012 15:58:46 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <419417C345CA5F48BF45F0A23955A0633642B8A2@SEAEMBX02.olympus.F5Net.com> References: <50C65C84.6080203@dougbarton.us> <419417C345CA5F48BF45F0A23955A0633642B8A2@SEAEMBX02.olympus.F5Net.com> Message-ID: On Dec 10, 2012, at 2:53 PM, Ian Smith wrote: >> Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 in IPv4. As in, it's the smallest possible assignment that will allow an end-user host to >function under normal circumstances. > >> SWIP or rwhois for a /64 seems excessive to me, FWIW. > > IPv4/32 is both a routing endpoint and a host. IPv4 is a 32 bit combined routing and host space. > > IPv6/64 is a routing endpoint and v6/128 is a host. IPv6 is a 64 bit routing space and also a 64 bit host space for each routing space, not a 128 bit combined routing and host space. > You can make a /128 a routing endpoint in IPv6 just like a /32 in IPv4 with all the same rules, restrictions, and limitations. > Evidently, the whois requirement is for networks, not nodes, which makes sense when you think about how the entity that controls a /64 is assuming responsibility for 2^64 network nodes. Correct (in the first part). In reality, nobody has 2^64 nodes, that's more than the square of the current host addressing available in all of IPv4. You'll never see a /64 full of hosts. For one thing, there's no concept for switching hardware that could handle that large of a MAC adjacency table, nor is there ever likely to be such. Owen > > > > -----Original Message----- > From: Doug Barton [mailto:dougb at dougbarton.us] > Sent: Monday, December 10, 2012 5:05 PM > To: Schiller, Heather A > Cc: Constantine A. Murenin; nanog at nanog.org > Subject: Re: Why do some providers require IPv6 /64 PA space to have public whois? > > On 12/10/2012 01:27 PM, Schiller, Heather A wrote: >> I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 >> :: IPv6 /64 > > > Doug > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.2793 / Virus Database: 2634/5946 - Release Date: 12/08/12 From marka at isc.org Tue Dec 11 00:07:58 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 11 Dec 2012 11:07:58 +1100 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: Your message of "Mon, 10 Dec 2012 15:17:41 -0800." <272782D1-8DEA-4718-9429-8B0505DD30BD@delong.com> References: <50C65C84.6080203@dougbarton.us> <20121210230253.8BEE82CE0B5D@drugs.dv.isc.org> <272782D1-8DEA-4718-9429-8B0505DD30BD@delong.com> Message-ID: <20121211000758.A49922CE1084@drugs.dv.isc.org> In message <272782D1-8DEA-4718-9429-8B0505DD30BD at delong.com>, Owen DeLong write s: > > > Sent from my iPad > > On Dec 10, 2012, at 3:02 PM, Mark Andrews wrote: > > >=20 > > In message <50C65C84.6080203 at dougbarton.us>, Doug Barton writes: > >> On 12/10/2012 01:27 PM, Schiller, Heather A wrote: > >>> I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 := > : I > >> Pv6 /64 > >>=20 > >> Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 > >> in IPv4. As in, it's the smallest possible assignment that will allow an > >> end-user host to function under normal circumstances. > >>=20 > >> SWIP or rwhois for a /64 seems excessive to me, FWIW. > >>=20 > >> Doug > >=20 > > Even SWIP for a /48 for a residential assignment is excessive. > > SWIP for a /48 for a commercial assignment is reasonable > >=20 > > I disagree. SWIP for a /48 with the appropriate notations under residential c > = > ustomer privacy policy provides a good balance between the need for public a= > ccountability of resource utilization and privacy concerns for residential c= > ustomer assignments. > > Owen You don't SWIP each residential customer with IPv4. You often SWIP blocks of residential customers down to the pop level. You often SWIP each commercial customer with IPv4. To require a SWIP entry for each residential customer is bureaucracy gone mad. Additionally there is no technical need for this. It isn't needed for address accountability. Residential customers have historically been treated in bulk. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mureninc at gmail.com Tue Dec 11 02:53:42 2012 From: mureninc at gmail.com (Constantine A. Murenin) Date: Mon, 10 Dec 2012 18:53:42 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: <20121208210326.01E512CD2012@drugs.dv.isc.org> Message-ID: On 8 December 2012 23:10, Owen DeLong wrote: >> Frankly, the more I think about this, the less it's clear why someone >> like hetzner.de would actually want you to be using their native IPv6 >> support, instead of the one provided by HE.net through their free >> tunnelbroker.net service. HE has an open-peering policy (AFAIK); > > Yes, HE has a one-word peering policy? "YES!" > > However, that means that if hetzner peered IPv6 native with us, we > would provide them every thing you get through tunnel broker still > at no cost and without any limitations on bandwidth. > > We don't artificially limit the bandwidth on tunnel broker, but, each > tunnel broker server has a single network interface that it hairpins > the v4/v6 traffic on and the bandwidth is what it is. I don't expect > that will be an issue any time soon, but for planning purposes, people > should understand that tunnel broker is a where-is-as-is service on > a best effort basis with no SLA. > > We do offer production grade tunnel services for a fee and people > are welcome to contact me off-list for more information. > >> which basically means that tunnelbroker.net traffic is free for >> hetzner.de, whereas for native IPv6 traffic they might have to be >> paying for transit costs, depending on the destination. HE.net > > We would really rather see such traffic come native across our peering > links as much as possible. It allows us to provide a higher quality > of service. Are you suggesting that it's an official/semi-official policy to allow IPv6 peering clients to use HE.net as their default route for IPv6? (To no surprise, that seems to contradict http://he.net/peering.html.) Because, essentially, if you allow settlement-free peering with IPv4, and include tunnelbroker.net into it, then, indeed, a major hosting provider, by having a poor native IPv6 support, can indirectly save a few pennies by forcing some clients to instead use tunnelbroker.net and thus bypass having to pay for any kind of IPv6 transit on behalf of such clients, since any traffic requiring transit when native, will qualify for peering once tunnelled. I'm curious if anyone actually does now, or have attempted in the past, any such traffic laundering by design and on purpose. :-) I guess in the end, the scenario is more hypothetical and conspiracy-driven, since such attempts will either never be statistically significant enough to be noticed, or would be obvious enough to warrant some immediate manual intervention against the misbehaving peer. To HE's credit, I do recall hearing from someone that HE.net is nice enough to not restrict other network operators to choose whether they want to do settlement-free peering or transit, and is very flexible to allow doing both at the same time (unlike AT&T, which explicitly documents that they will never peer with anyone who buys transit from them). As an end user, I still don't understand how you can afford to carry all that traffic globally between the POPs for free; but I'm not complaining. :-) I guess it's a great way to be spending most of your marketing budget in house. :-) You obviously have to justify the need for native connectivity; but, honestly, for my situation (one value server in a given DC) I still see it as a marketing talk that native IPv6 is somehow better than tunnelled. As an end user, I honestly think I have more flexibility with the tunnelled service (and without any extra price). And, as people have pointed out, tunnelled service is usually as reliable as the underlying connection; meaning, in the hosting setting there should really be no problems with tunnels whatsoever. On the other hand, native IPv6 would be quite easy to get wrong; in fact, very easy to get wrong, as I have personally learnt. >> probably wins, too; since being the place-to-go-for-IPv6 might make it >> easier for them to have more settlement-free peering with big transit >> providers such as AT&T (Bay-Area-wise, they still have IPv6 traffic >> going through their peering in Los Angeles). > > Being a popular IPv6 peer and having so many tunnel broker users has > been a great success story for us, yes. However, in terms of how > this affects our standing for peering, I think that the effect is the > same regardless of whether we are passing the traffic from/to a peering > link or a tunnel broker. Yes; but I was referring to the free transit that you effectively offer through the tunnel broker; such traffic would otherwise go to AT&T through a transit provider, which may or may not be HE. C. From mureninc at gmail.com Tue Dec 11 03:30:41 2012 From: mureninc at gmail.com (Constantine A. Murenin) Date: Mon, 10 Dec 2012 19:30:41 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <20121211000758.A49922CE1084@drugs.dv.isc.org> References: <50C65C84.6080203@dougbarton.us> <20121210230253.8BEE82CE0B5D@drugs.dv.isc.org> <272782D1-8DEA-4718-9429-8B0505DD30BD@delong.com> <20121211000758.A49922CE1084@drugs.dv.isc.org> Message-ID: On 10 December 2012 16:07, Mark Andrews wrote: > You don't SWIP each residential customer with IPv4. You often SWIP blocks > of residential customers down to the pop level. > You often SWIP each commercial customer with IPv4. > > To require a SWIP entry for each residential customer is bureaucracy > gone mad. Additionally there is no technical need for this. It > isn't needed for address accountability. Residential customers > have historically been treated in bulk. Yes, agreed; and note that in my specific case, we're not even talking about the residential customer situation: we're talking about individual private servers (with IPv4) requiring basic IPv6 connectivity (in order to be dual stacked, no more). I'm picky, and will not accept long and unabbreviatable addresses (especially when I'm already paying for a unique and "short" 32-bit IPv4 address). Having my street address, apartment and phone numbers appearing in a public whois is also hardly a pleasantry. But for all I care (and I'm not a network engineer), I just need a single IPv6 address or two; an abbreviatable /124 is all I'd need; but, then, why not just issue a /48, since that's manageable and easier anyways? C. From randy at psg.com Tue Dec 11 03:37:48 2012 From: randy at psg.com (Randy Bush) Date: Tue, 11 Dec 2012 12:37:48 +0900 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <20121211000758.A49922CE1084@drugs.dv.isc.org> References: <50C65C84.6080203@dougbarton.us> <20121210230253.8BEE82CE0B5D@drugs.dv.isc.org> <272782D1-8DEA-4718-9429-8B0505DD30BD@delong.com> <20121211000758.A49922CE1084@drugs.dv.isc.org> Message-ID: > You don't SWIP each residential customer with IPv4. you don't swip anybody. some folk swip each residential customer. randy From dougb at dougbarton.us Tue Dec 11 04:35:35 2012 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 10 Dec 2012 20:35:35 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <010828F3-8EFE-466F-8787-4DF1C61C8D5B@delong.com> References: <50C65C84.6080203@dougbarton.us> <010828F3-8EFE-466F-8787-4DF1C61C8D5B@delong.com> Message-ID: <50C6B817.7030304@dougbarton.us> On 12/10/2012 03:14 PM, Owen DeLong wrote: > > On Dec 10, 2012, at 2:04 PM, Doug Barton > wrote: > >> On 12/10/2012 01:27 PM, Schiller, Heather A wrote: >>> I think most folks would agree that, IPv4 /32 :: IPv6 /128 as >>> IPv4 /29 :: IPv6 /64 >> >> Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to >> a /32 in IPv4. As in, it's the smallest possible assignment that >> will allow an end-user host to function under normal >> circumstances. > > No, you could be assigned a /128 and have it function for a single > host. You saw how I very carefully phrased my statement to try to avoid this kind of ratholing, right? :) > However, let's not start doing that as it's pretty brain-dead > and the reality is that hardly anyone has a single host any more. > > Heather has the corollaries correct. You're entitled to your opinion of course, just don't be surprised when people disagree with you. >> SWIP or rwhois for a /64 seems excessive to me, FWIW. > > I'm not sure I disagree, but, I certainly don't feel strongly enough > about it to submit a policy proposal. I will say that you are far > more likely to get this changed by submitting a policy proposal than > you are by complaining to NANOG about it. I certainly don't care enough about it to do that, I was just voicing an opinion. Doug (personally I'd be happy just to have native IPv6 available) From owen at delong.com Tue Dec 11 08:31:50 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Dec 2012 00:31:50 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <20121211000758.A49922CE1084@drugs.dv.isc.org> References: <50C65C84.6080203@dougbarton.us> <20121210230253.8BEE82CE0B5D@drugs.dv.isc.org> <272782D1-8DEA-4718-9429-8B0505DD30BD@delong.com> <20121211000758.A49922CE1084@drugs.dv.isc.org> Message-ID: <627B42D4-2502-4D26-8DE1-6D6E094967B9@delong.com> On Dec 10, 2012, at 4:07 PM, Mark Andrews wrote: > > In message <272782D1-8DEA-4718-9429-8B0505DD30BD at delong.com>, Owen DeLong write > s: >> >> >> Sent from my iPad >> >> On Dec 10, 2012, at 3:02 PM, Mark Andrews wrote: >> >>> =20 >>> In message <50C65C84.6080203 at dougbarton.us>, Doug Barton writes: >>>> On 12/10/2012 01:27 PM, Schiller, Heather A wrote: >>>>> I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 := >> : I >>>> Pv6 /64 >>>> =20 >>>> Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to a /32 >>>> in IPv4. As in, it's the smallest possible assignment that will allow an >>>> end-user host to function under normal circumstances. >>>> =20 >>>> SWIP or rwhois for a /64 seems excessive to me, FWIW. >>>> =20 >>>> Doug >>> =20 >>> Even SWIP for a /48 for a residential assignment is excessive. >>> SWIP for a /48 for a commercial assignment is reasonable >>> =20 >> >> I disagree. SWIP for a /48 with the appropriate notations under residential c >> = >> ustomer privacy policy provides a good balance between the need for public a= >> ccountability of resource utilization and privacy concerns for residential c= >> ustomer assignments. >> >> Owen > > You don't SWIP each residential customer with IPv4. You often SWIP blocks > of residential customers down to the pop level. > You often SWIP each commercial customer with IPv4. > You SWIP each one that gets a /29 or larger. > To require a SWIP entry for each residential customer is bureaucracy > gone mad. Additionally there is no technical need for this. It > isn't needed for address accountability. Residential customers > have historically been treated in bulk. > It really isn't. We can agree to disagree, as we usually do. It's quite easily automated and it really is the equivalent to current IPv4 policy. The difference being only that in IPv6, we expect more customers to get networks instead of host addresses. Owen From owen at delong.com Tue Dec 11 08:40:56 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Dec 2012 00:40:56 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: <20121208210326.01E512CD2012@drugs.dv.isc.org> Message-ID: <71E254C6-4D98-4360-89DE-261C7147DAC6@delong.com> On Dec 10, 2012, at 6:53 PM, Constantine A. Murenin wrote: > On 8 December 2012 23:10, Owen DeLong wrote: >>> Frankly, the more I think about this, the less it's clear why someone >>> like hetzner.de would actually want you to be using their native IPv6 >>> support, instead of the one provided by HE.net through their free >>> tunnelbroker.net service. HE has an open-peering policy (AFAIK); >> >> Yes, HE has a one-word peering policy? "YES!" >> >> However, that means that if hetzner peered IPv6 native with us, we >> would provide them every thing you get through tunnel broker still >> at no cost and without any limitations on bandwidth. >> >> We don't artificially limit the bandwidth on tunnel broker, but, each >> tunnel broker server has a single network interface that it hairpins >> the v4/v6 traffic on and the bandwidth is what it is. I don't expect >> that will be an issue any time soon, but for planning purposes, people >> should understand that tunnel broker is a where-is-as-is service on >> a best effort basis with no SLA. >> >> We do offer production grade tunnel services for a fee and people >> are welcome to contact me off-list for more information. >> >>> which basically means that tunnelbroker.net traffic is free for >>> hetzner.de, whereas for native IPv6 traffic they might have to be >>> paying for transit costs, depending on the destination. HE.net >> >> We would really rather see such traffic come native across our peering >> links as much as possible. It allows us to provide a higher quality >> of service. > > Are you suggesting that it's an official/semi-official policy to allow > IPv6 peering clients to use HE.net as their default route for IPv6? Let me be clear. We offer free IPv6 transit on all IPv6 peering sessions. We do that by advertising all known IPv6 prefixes to you. We fully expect you will not point default at us. However, there is no need to do so as we will, by default and unless you ask otherwise, advertise all IPv6 prefixes known to you. > (To no surprise, that seems to contradict http://he.net/peering.html.) > Because, essentially, if you allow settlement-free peering with IPv4, > and include tunnelbroker.net into it, then, indeed, a major hosting > provider, by having a poor native IPv6 support, can indirectly save a > few pennies by forcing some clients to instead use tunnelbroker.net > and thus bypass having to pay for any kind of IPv6 transit on behalf > of such clients, since any traffic requiring transit when native, will > qualify for peering once tunnelled. I'm curious if anyone actually > does now, or have attempted in the past, any such traffic laundering > by design and on purpose. :-) I guess in the end, the scenario is > more hypothetical and conspiracy-driven, since such attempts will > either never be statistically significant enough to be noticed, or > would be obvious enough to warrant some immediate manual intervention > against the misbehaving peer. > I don't know of anyone doing so, but I really can't see a reason why they would. We'll happily accept all traffic to all valid IPv6 destinations known in our routing tables over any peering connection. > To HE's credit, I do recall hearing from someone that HE.net is nice > enough to not restrict other network operators to choose whether they > want to do settlement-free peering or transit, and is very flexible to > allow doing both at the same time (unlike AT&T, which explicitly > documents that they will never peer with anyone who buys transit from > them). Correct. We will always localpref the paid connection, but we are happy to simultaneously peer and sell bandwidth to our customers. > > As an end user, I still don't understand how you can afford to carry > all that traffic globally between the POPs for free; but I'm not > complaining. :-) I guess it's a great way to be spending most of your > marketing budget in house. :-) > Well, I can't give out all of the details, but, what I can say is that there is monetary value in being well liked by your customers and your potential customers. > You obviously have to justify the need for native connectivity; but, > honestly, for my situation (one value server in a given DC) I still > see it as a marketing talk that native IPv6 is somehow better than > tunnelled. As an end user, I honestly think I have more flexibility > with the tunnelled service (and without any extra price). And, as > people have pointed out, tunnelled service is usually as reliable as > the underlying connection; meaning, in the hosting setting there > should really be no problems with tunnels whatsoever. On the other > hand, native IPv6 would be quite easy to get wrong; in fact, very easy > to get wrong, as I have personally learnt. There are MTU and performance penalties. They may be small in your specific situation. They may not be so small on the return path in some cases. If tunnels are working well for you, then who cares what anyone else has to say about it. Use a tunnel. However, there's no cost difference between native and tunneled if you are present at an HE connected exchange point, so, it's entirely up to your ISP how they want to do it. > >>> probably wins, too; since being the place-to-go-for-IPv6 might make it >>> easier for them to have more settlement-free peering with big transit >>> providers such as AT&T (Bay-Area-wise, they still have IPv6 traffic >>> going through their peering in Los Angeles). >> >> Being a popular IPv6 peer and having so many tunnel broker users has >> been a great success story for us, yes. However, in terms of how >> this affects our standing for peering, I think that the effect is the >> same regardless of whether we are passing the traffic from/to a peering >> link or a tunnel broker. > > Yes; but I was referring to the free transit that you effectively > offer through the tunnel broker; such traffic would otherwise go to > AT&T through a transit provider, which may or may not be HE. My point is that the free transit through tunnel broker and the free transit through an exchange point are roughly equivalent in terms of that driver. Owen From owen at delong.com Tue Dec 11 08:43:14 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Dec 2012 00:43:14 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: <50C6B817.7030304@dougbarton.us> References: <50C65C84.6080203@dougbarton.us> <010828F3-8EFE-466F-8787-4DF1C61C8D5B@delong.com> <50C6B817.7030304@dougbarton.us> Message-ID: On Dec 10, 2012, at 8:35 PM, Doug Barton wrote: > On 12/10/2012 03:14 PM, Owen DeLong wrote: >> >> On Dec 10, 2012, at 2:04 PM, Doug Barton >> wrote: >> >>> On 12/10/2012 01:27 PM, Schiller, Heather A wrote: >>>> I think most folks would agree that, IPv4 /32 :: IPv6 /128 as >>>> IPv4 /29 :: IPv6 /64 >>> >>> Quite the opposite in fact. In IPv6 a /64 is roughly equivalent to >>> a /32 in IPv4. As in, it's the smallest possible assignment that >>> will allow an end-user host to function under normal >>> circumstances. >> >> No, you could be assigned a /128 and have it function for a single >> host. > > You saw how I very carefully phrased my statement to try to avoid this kind of ratholing, right? :) > >> However, let's not start doing that as it's pretty brain-dead >> and the reality is that hardly anyone has a single host any more. >> >> Heather has the corollaries correct. > > You're entitled to your opinion of course, just don't be surprised when people disagree with you. > Regardless of how you phrase it, the functional IPv6 equivalent of an IPv4 /32 is an IPv6 /128. You don't configure a /64 on a loopback interface in a router, for example, you configure a /128. >>> SWIP or rwhois for a /64 seems excessive to me, FWIW. >> >> I'm not sure I disagree, but, I certainly don't feel strongly enough >> about it to submit a policy proposal. I will say that you are far >> more likely to get this changed by submitting a policy proposal than >> you are by complaining to NANOG about it. > > I certainly don't care enough about it to do that, I was just voicing an opinion. > > Doug (personally I'd be happy just to have native IPv6 available) I'm loving mine. Owen From chuckchurch at gmail.com Tue Dec 11 13:23:22 2012 From: chuckchurch at gmail.com (Chuck Church) Date: Tue, 11 Dec 2012 08:23:22 -0500 Subject: RADB entry Message-ID: <002101cdd7a2$b5654880$202fd980$@gmail.com> Anyone, Hopefully this is a simple question about RADB. I'm supporting a small wireless ISP, they just recently added a second upstream connection - Charter (AS 20115). The IP space was originally issued by the other upstream Windstream (AS 7029). Looking at a few resources such as the bgp.he.net to see who peers with who and looking glasses, it seems that not all of AS 20115 peers are accepting our prefix. AT&T is an example - AS7018. In one case, it's an upstream 2 levels up - Century Link accepts from Charter, but Level 3 doesn't accept it from Century Link. Charter uses RADB. The entry for the prefix looks like this: route: 75.77.38.0/23 descr: Vybrent_Communications AS26296 origin: AS20115 mnt-by: MAINT-CHTR-WD changed: x at chartercom.com 20121207 #18:55:23Z source: RADB route: 75.77.38.0/23 descr: Community Connect LLC remarks: Proxy Registered Customer Route remarks: SWIP from NUVOX origin: AS26296 member-of: RS-NUVOX-CUSTOMERS-NONRIR mnt-by: MAINT-AS11456 changed: x at nuvox.com 20080519 source: RADB 75.77.38.0/23 is our prefix. Our AS is 26296. Does that entry look right? I'm wondering if the 'origin' AS in the Charter entry is correct, since that is Charter's AS, not ours. To avoid confusion, Nuvox is the ISP that Windstream bought out, hence the name change. Vybrent and Community Connect are the same company by the way as well. Other than RADB, are there any other database registries that should be checked to make sure the info is right? Thanks, Chuck From eric at telic.us Tue Dec 11 13:31:22 2012 From: eric at telic.us (Eric Krichbaum) Date: Tue, 11 Dec 2012 07:31:22 -0600 Subject: RADB entry In-Reply-To: <002101cdd7a2$b5654880$202fd980$@gmail.com> References: <002101cdd7a2$b5654880$202fd980$@gmail.com> Message-ID: <039a01cdd7a3$d056e850$7104b8f0$@telic.us> While not 100% accurate, it is very common. The origin being entered by a provider as their own allows them to add the prefix (and have it accepted by anyone who filters them by prefix generated) without being forced to add a downstream (and downstream's downstreams) AS to their AS-SET. In general, if an entity does their own IRR somewhere, I'd guess that the correct AS-SET/etc. should be accepted easily and used. This is just a shortcut for providers when a customer says "Add this prefix for me please". Eric -----Original Message----- From: Chuck Church [mailto:chuckchurch at gmail.com] Sent: Tuesday, December 11, 2012 7:23 AM To: nanog at nanog.org Subject: RADB entry Anyone, Hopefully this is a simple question about RADB. I'm supporting a small wireless ISP, they just recently added a second upstream connection - Charter (AS 20115). The IP space was originally issued by the other upstream Windstream (AS 7029). Looking at a few resources such as the bgp.he.net to see who peers with who and looking glasses, it seems that not all of AS 20115 peers are accepting our prefix. AT&T is an example - AS7018. In one case, it's an upstream 2 levels up - Century Link accepts from Charter, but Level 3 doesn't accept it from Century Link. Charter uses RADB. The entry for the prefix looks like this: route: 75.77.38.0/23 descr: Vybrent_Communications AS26296 origin: AS20115 mnt-by: MAINT-CHTR-WD changed: x at chartercom.com 20121207 #18:55:23Z source: RADB route: 75.77.38.0/23 descr: Community Connect LLC remarks: Proxy Registered Customer Route remarks: SWIP from NUVOX origin: AS26296 member-of: RS-NUVOX-CUSTOMERS-NONRIR mnt-by: MAINT-AS11456 changed: x at nuvox.com 20080519 source: RADB 75.77.38.0/23 is our prefix. Our AS is 26296. Does that entry look right? I'm wondering if the 'origin' AS in the Charter entry is correct, since that is Charter's AS, not ours. To avoid confusion, Nuvox is the ISP that Windstream bought out, hence the name change. Vybrent and Community Connect are the same company by the way as well. Other than RADB, are there any other database registries that should be checked to make sure the info is right? Thanks, Chuck From morrowc.lists at gmail.com Tue Dec 11 14:51:10 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 11 Dec 2012 09:51:10 -0500 Subject: RADB entry In-Reply-To: <039a01cdd7a3$d056e850$7104b8f0$@telic.us> References: <002101cdd7a2$b5654880$202fd980$@gmail.com> <039a01cdd7a3$d056e850$7104b8f0$@telic.us> Message-ID: On Tue, Dec 11, 2012 at 8:31 AM, Eric Krichbaum wrote: > The origin being entered by a > provider as their own allows them to add the prefix (and have it accepted by > anyone who filters them by prefix generated) without being forced to add a > downstream (and downstream's downstreams) AS to their AS-SET. 'proxy registration'... so nice... now you can't control your prefix data in radb, how quaint! 'proxy registration' - never a good idea... not ever... adding cruft that's not connected to the data owner to the database? recipe for stale/old-n-busted data... hurray. From eric at telic.us Tue Dec 11 15:00:20 2012 From: eric at telic.us (Eric Krichbaum) Date: Tue, 11 Dec 2012 09:00:20 -0600 Subject: RADB entry In-Reply-To: References: <002101cdd7a2$b5654880$202fd980$@gmail.com> <039a01cdd7a3$d056e850$7104b8f0$@telic.us> Message-ID: <03d401cdd7b0$3d912230$b8b36690$@telic.us> Absolutely. I'd rather see it done responsibly. It's hard to get rid of bad data/incorrect data/stale data and it shouldn't be. If done properly, it would be much friendlier. There is incentive for people to put data in but not to remove the other. Eric -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Tuesday, December 11, 2012 8:51 AM To: Eric Krichbaum Cc: Chuck Church; nanog at nanog.org Subject: Re: RADB entry On Tue, Dec 11, 2012 at 8:31 AM, Eric Krichbaum wrote: > The origin being entered by a > provider as their own allows them to add the prefix (and have it > accepted by anyone who filters them by prefix generated) without being > forced to add a downstream (and downstream's downstreams) AS to their AS-SET. 'proxy registration'... so nice... now you can't control your prefix data in radb, how quaint! 'proxy registration' - never a good idea... not ever... adding cruft that's not connected to the data owner to the database? recipe for stale/old-n-busted data... hurray. From chuckchurch at gmail.com Tue Dec 11 15:11:28 2012 From: chuckchurch at gmail.com (Chuck Church) Date: Tue, 11 Dec 2012 10:11:28 -0500 Subject: RADB entry In-Reply-To: <039a01cdd7a3$d056e850$7104b8f0$@telic.us> References: <002101cdd7a2$b5654880$202fd980$@gmail.com> <039a01cdd7a3$d056e850$7104b8f0$@telic.us> Message-ID: <004b01cdd7b1$cbf819b0$63e84d10$@gmail.com> -----Original Message----- >From: Eric Krichbaum [mailto:eric at telic.us] >Sent: Tuesday, December 11, 2012 8:31 AM >To: 'Chuck Church'; nanog at nanog.org >Subject: RE: RADB entry >While not 100% accurate, it is very common. The origin being entered by a provider as their own allows them to add the prefix (and have it accepted by anyone who filters them >by prefix generated) without being forced to add a downstream (and downstream's downstreams) AS to their AS-SET. In general, if an entity does their own IRR somewhere, I'd >guess that the correct AS-SET/etc. should be accepted easily and used. This is just a shortcut for providers when a customer says "Add this prefix for me please". >Eric So if I understand how RADB works, ISPs can poll it frequently and update their filters automatically (or semi-automatically). Is there risk of a polling ISP's system seeing this data, and being confused by one ISP listing the origin as the correct one, and the other ISP listing the origin as their own? Can an upstream create a registration for us in RADB the correct way, or does that require us having our own account on RADB? I'm guessing I'm wondering what is the 'most correct' way? Thanks, Chuck From morrowc.lists at gmail.com Tue Dec 11 15:17:59 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 11 Dec 2012 10:17:59 -0500 Subject: RADB entry In-Reply-To: <03d401cdd7b0$3d912230$b8b36690$@telic.us> References: <002101cdd7a2$b5654880$202fd980$@gmail.com> <039a01cdd7a3$d056e850$7104b8f0$@telic.us> <03d401cdd7b0$3d912230$b8b36690$@telic.us> Message-ID: On Tue, Dec 11, 2012 at 10:00 AM, Eric Krichbaum wrote: > Absolutely. I'd rather see it done responsibly. It's hard to get rid of > bad data/incorrect data/stale data and it shouldn't be. If done properly, > it would be much friendlier. There is incentive for people to put data in > but not to remove the other. and in the name of expediency providers proxy-register for their downstreams... route: 209.85.252.79/32 descr: GOOGLE/GOO/611 origin: AS15412 notify: notify at flagtelecom.com mnt-by: MAINT-FLAG-CUSTOMER changed: hostmaster at flagtelecom.com 20100524 source: RADB thanks flag, I needed that... could you remove it pls? (note I've attempted a few times to get flag to remove this, so far no joy. (one example of many...) -chris > -----Original Message----- > From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On > Behalf Of Christopher Morrow > Sent: Tuesday, December 11, 2012 8:51 AM > To: Eric Krichbaum > Cc: Chuck Church; nanog at nanog.org > Subject: Re: RADB entry > > On Tue, Dec 11, 2012 at 8:31 AM, Eric Krichbaum wrote: >> The origin being entered by a >> provider as their own allows them to add the prefix (and have it >> accepted by anyone who filters them by prefix generated) without being >> forced to add a downstream (and downstream's downstreams) AS to their > AS-SET. > > 'proxy registration'... so nice... now you can't control your prefix data in > radb, how quaint! > 'proxy registration' - never a good idea... not ever... adding cruft that's > not connected to the data owner to the database? recipe for > stale/old-n-busted data... hurray. > > From morrowc.lists at gmail.com Tue Dec 11 15:18:55 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 11 Dec 2012 10:18:55 -0500 Subject: RADB entry In-Reply-To: <004b01cdd7b1$cbf819b0$63e84d10$@gmail.com> References: <002101cdd7a2$b5654880$202fd980$@gmail.com> <039a01cdd7a3$d056e850$7104b8f0$@telic.us> <004b01cdd7b1$cbf819b0$63e84d10$@gmail.com> Message-ID: On Tue, Dec 11, 2012 at 10:11 AM, Chuck Church wrote: > -----Original Message----- >>From: Eric Krichbaum [mailto:eric at telic.us] >>Sent: Tuesday, December 11, 2012 8:31 AM >>To: 'Chuck Church'; nanog at nanog.org >>Subject: RE: RADB entry > >>While not 100% accurate, it is very common. The origin being entered by a > provider as their own allows them to add the prefix (and have it accepted by > anyone who filters them >by prefix generated) without being forced to add a > downstream (and downstream's downstreams) AS to their AS-SET. In general, > if an entity does their own IRR somewhere, I'd >guess that the correct > AS-SET/etc. should be accepted easily and used. This is just a shortcut for > providers when a customer says "Add this prefix for me please". > >>Eric > > So if I understand how RADB works, ISPs can poll it frequently and update > their filters automatically (or semi-automatically). Is there risk of a > polling ISP's system seeing this data, and being confused by one ISP listing > the origin as the correct one, and the other ISP listing the origin as their > own? Can an upstream create a registration for us in RADB the correct way, > or does that require us having our own account on RADB? I'm guessing I'm > wondering what is the 'most correct' way? http://www.merit.edu/mail.archives/nanog/2000-06/msg00414.html that thread is likely of interest... > Thanks, > > Chuck > > > From Andrew.Stern at cumulus.com Tue Dec 11 19:49:47 2012 From: Andrew.Stern at cumulus.com (Andrew Stern) Date: Tue, 11 Dec 2012 14:49:47 -0500 Subject: Cogent-Comast packet loss in the SF Bay Area Message-ID: <57186421D4AE5D4688E8359FF407F778017354F4BBCE@MAIL-07-A.cumulus.com> Hello. We are seeing approx. 3% - 10% packet loss between a fixed address on the Cogent network and services on the Comcast network in the SF Bay Area. Are we alone in this? Andrew Stern, CBNT | Broadcast IT Engineer Cumulus Media San Francisco KFOG | KNBR | KSAN | KTCT | KGO | KSFO ________________________________ Cumulus Media Disclaimer This message contains confidential information and is intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From courtneysmith at comcast.net Tue Dec 11 22:37:59 2012 From: courtneysmith at comcast.net (Courtney Smith) Date: Tue, 11 Dec 2012 17:37:59 -0500 Subject: RADB entry In-Reply-To: References: Message-ID: <72E3860F-BEAB-44A6-AE68-FC54605F2A92@comcast.net> > > Anyone, > > > > Hopefully this is a simple question about RADB. I'm > supporting a small wireless ISP, they just recently added a second upstream > connection - Charter (AS 20115). The IP space was originally issued by the > other upstream Windstream (AS 7029). Looking at a few resources such as the > bgp.he.net to see who peers with who and looking glasses, it seems that not > all of AS 20115 peers are accepting our prefix. AT&T is an example - > AS7018. In one case, it's an upstream 2 levels up - Century Link accepts > from Charter, but Level 3 doesn't accept it from Century Link. Charter uses > RADB. The entry for the prefix looks like this: > > > What makes you think Level3 is not accepting from CenturyLink? I suspect Century Link may be a peer of Level3 instead of a customer. Windstream appears to be a customer of Level3. Level3 will put a higher local pref on customer routes. Courtney Smith courtneysmith at comcast.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From matt.addison at lists.evilgeni.us Wed Dec 12 00:16:27 2012 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Tue, 11 Dec 2012 19:16:27 -0500 Subject: RADB entry In-Reply-To: References: <002101cdd7a2$b5654880$202fd980$@gmail.com> <039a01cdd7a3$d056e850$7104b8f0$@telic.us> <03d401cdd7b0$3d912230$b8b36690$@telic.us> Message-ID: On Tue, Dec 11, 2012 at 10:17 AM, Christopher Morrow wrote: > On Tue, Dec 11, 2012 at 10:00 AM, Eric Krichbaum wrote: >> Absolutely. I'd rather see it done responsibly. It's hard to get rid of >> bad data/incorrect data/stale data and it shouldn't be. If done properly, >> it would be much friendlier. There is incentive for people to put data in >> but not to remove the other. > > and in the name of expediency providers proxy-register for their downstreams... > route: 209.85.252.79/32 > descr: GOOGLE/GOO/611 > origin: AS15412 > notify: notify at flagtelecom.com > mnt-by: MAINT-FLAG-CUSTOMER > changed: hostmaster at flagtelecom.com 20100524 > source: RADB > > thanks flag, I needed that... could you remove it pls? (note I've > attempted a few times to get flag to remove this, so far no joy. When I had stale entries on RADB I emailed db-admin over there and they removed them. Was back in '09 so don't know if policy may have changed in the meantime. Also had entries pulled from SAVVIS and LEVEL3 registries by emailing their respective admins. List of contacts for the respective IRR instances can be found at: http://www.irr.net/docs/list.html ~Matt From samba_55 at hotmail.com Wed Dec 12 00:20:42 2012 From: samba_55 at hotmail.com (flower tailor) Date: Wed, 12 Dec 2012 03:20:42 +0300 Subject: No subject Message-ID: Delete me From mike-nanog at tiedyenetworks.com Wed Dec 12 01:02:22 2012 From: mike-nanog at tiedyenetworks.com (Mike) Date: Tue, 11 Dec 2012 17:02:22 -0800 Subject: In-Reply-To: References: Message-ID: <50C7D79E.6060904@tiedyenetworks.com> On 12/11/2012 04:20 PM, flower tailor wrote: > Delete me > You are deleted. From tknchris at gmail.com Wed Dec 12 01:07:53 2012 From: tknchris at gmail.com (chris) Date: Tue, 11 Dec 2012 20:07:53 -0500 Subject: In-Reply-To: <50C7D79E.6060904@tiedyenetworks.com> References: <50C7D79E.6060904@tiedyenetworks.com> Message-ID: ^H On Tue, Dec 11, 2012 at 8:02 PM, Mike wrote: > On 12/11/2012 04:20 PM, flower tailor wrote: > >> Delete me >> >> > > > You are deleted. > > > From surfer at mauigateway.com Wed Dec 12 01:56:15 2012 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 11 Dec 2012 17:56:15 -0800 Subject: Message-ID: <20121211175615.7380FE6A@resin13.mta.everyone.net> --- samba_55 at hotmail.com wrote: From: flower tailor Delete me -------------------------------------- cisco-router> conf t cisco-router(config)# banner ^c look at the email header to get off mailing lists like NANOG ^c cisco-router(config)# ^Z cisco-router# wr mem cisco-router# exit >;-) scott From courtneysmith at comcast.net Wed Dec 12 02:09:40 2012 From: courtneysmith at comcast.net (Courtney Smith) Date: Tue, 11 Dec 2012 21:09:40 -0500 Subject: RADB entry In-Reply-To: <00ea01cdd7fc$9e5f5270$db1df750$@gmail.com> References: <72E3860F-BEAB-44A6-AE68-FC54605F2A92@comcast.net> <00ea01cdd7fc$9e5f5270$db1df750$@gmail.com> Message-ID: <346961F8-E4AA-4514-8DFC-2C38F5A9C22F@comcast.net> Chuck, If you look at the communities on 68.115.27.0/24 you will see 7018:5000. That community means AS209 is a AT&T peering partner. > route-server>sh ip bgp 68.115.217.201 > BGP routing table entry for 68.115.217.0/24, version 13683280 > Paths: (18 available, best #7, table Default-IP-Routing-Table) > Not advertised to any peer > ... > 7018 209 20115, (aggregated by 20115 96.34.212.29), (received & used) > 12.123.1.236 from 12.123.1.236 (12.123.1.236) > Origin IGP, localpref 100, valid, external, atomic-aggregate, best > Community: 7018:5000 7018:37232 Now if you look at results for 75.77.38.0/23 you will see 7018:2000. That would mean AS7029 is an AT&T customer. > route-server>sh ip bgp 75.77.38.0 > BGP routing table entry for 75.77.38.0/23, version 26960376 > Paths: (19 available, best #7, table Default-IP-Routing-Table) > Not advertised to any peer > 7018 7029 26296 26296 26296, (received & used) > 12.123.1.236 from 12.123.1.236 (12.123.1.236) > Origin IGP, localpref 100, valid, external, best > Community: 7018:2000 7018:34011 In AT&T's network, I believe they apply local pref 80 for peer routes and local pref 100 for customer routes. Ignore the local pref values you see on the route server. Let's look at what appears to be going on. Per your earlier post, you verified Charter(AS20115) has the prefix. Charter does not appear to have a interconnect with AT&T(7018) so they send to Centurlink/Qwest(AS209). We see Centurylink(AS209) accepts per their looking glass at https://kai04.centurylink.com/PtapRpts/Public/BackboneReport.aspx. BGP routing table entry for 75.77.38.0/23 20115 26296 Nexthop 205.171.0.93 (via 207.109.19.150) from chi-core-01 (205.171.0.144) Origin IGP, metric 0, localpref 100, internal, valid Last update: 13:30:09 ago Communities: 209:209 209:14520 20115:3200 20115:63004 Originator Id: 205.171.0.93 Cluster ID List: 207.109.19.145 205.171.0.149 Now Centurylink(AS209), sends the /23 to their peer AT&T(AS7018). AT&T accepts the /23 from Centurylink. Since Centurylink is their peer, AT&T assigns local pref 80. That's lower than the 100 assigned to the Windstream. Highest local pref wins. Your prepends are never part of the decision. So AT&T continues to pref the path via their customer Windstream(AS7029). I suspect this is really your problem instead of route registry data. Hopefully, Windstream offers their customers some BGP communities to allow traffic engineering. Finally, the WISP has a AS number from ARIN, they should be able to create their own maintainer on rr.arin.net. The RADB fee might be a little much for your WISP. https://www.arin.net/resources/routing/ Make sense? On Dec 11, 2012, at 7:07 PM, Chuck Church wrote: > Courtney, > > This is from the AT&T 7018 route server. The first one is our WAN > IP address, part of our ISP's ASN. The second one is our own /23. The > first one goes through Century Link, then Charter. The second one I would > think would take same path, with one additional AS (our own). But that one > isn't present at AT&T. Level 3 shows the same thing. Century Link > themselves see our /23 through Charter... > > route-server>sh ip bgp 68.115.217.201 > BGP routing table entry for 68.115.217.0/24, version 13683280 > Paths: (18 available, best #7, table Default-IP-Routing-Table) > Not advertised to any peer > ... > 7018 209 20115, (aggregated by 20115 96.34.212.29), (received & used) > 12.123.1.236 from 12.123.1.236 (12.123.1.236) > Origin IGP, localpref 100, valid, external, atomic-aggregate, best > Community: 7018:5000 7018:37232 > > route-server>sh ip bgp 75.77.38.0 > BGP routing table entry for 75.77.38.0/23, version 26960376 > Paths: (19 available, best #7, table Default-IP-Routing-Table) > Not advertised to any peer > 7018 7029 26296 26296 26296, (received & used) > 12.123.1.236 from 12.123.1.236 (12.123.1.236) > Origin IGP, localpref 100, valid, external, best > Community: 7018:2000 7018:34011 > > > Thanks, > > Chuck > > > -----Original Message----- > From: Courtney Smith [mailto:courtneysmith at comcast.net] > Sent: Tuesday, December 11, 2012 5:38 PM > To: nanog at nanog.org > Subject: Re: RADB entry > > >> >> Anyone, >> >> >> >> Hopefully this is a simple question about RADB. I'm >> supporting a small wireless ISP, they just recently added a second >> upstream connection - Charter (AS 20115). The IP space was originally >> issued by the other upstream Windstream (AS 7029). Looking at a few >> resources such as the bgp.he.net to see who peers with who and looking >> glasses, it seems that not all of AS 20115 peers are accepting our >> prefix. AT&T is an example - AS7018. In one case, it's an upstream 2 >> levels up - Century Link accepts from Charter, but Level 3 doesn't >> accept it from Century Link. Charter uses RADB. The entry for the prefix > looks like this: >> >> >> > > What makes you think Level3 is not accepting from CenturyLink? I suspect > Century Link may be a peer of Level3 instead of a customer. Windstream > appears to be a customer of Level3. Level3 will put a higher local pref on > customer routes. > > > > Courtney Smith > courtneysmith at comcast.net > > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > > Courtney Smith courtneysmith at comcast.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From joe at nethead.com Wed Dec 12 03:42:15 2012 From: joe at nethead.com (Joe Hamelin) Date: Tue, 11 Dec 2012 19:42:15 -0800 Subject: In-Reply-To: <20121211175615.7380FE6A@resin13.mta.everyone.net> References: <20121211175615.7380FE6A@resin13.mta.everyone.net> Message-ID: nanog:/root#rmuser Please enter one or more usernames: flower_tailor Matching password entry: flower_tailor:*:13204:13204::0:0:User &:/home/flower_tailor:/bin/tcsh Is this the entry you wish to remove? y Remove user's home directory (/home/flower_tailor)? y Removing user (flower_tailor): mailspool home passwd. nanog:/root# -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From kbroder at accretive-networks.net Wed Dec 12 03:57:49 2012 From: kbroder at accretive-networks.net (Kevin Broderick) Date: Tue, 11 Dec 2012 19:57:49 -0800 Subject: In-Reply-To: References: <20121211175615.7380FE6A@resin13.mta.everyone.net> Message-ID: <015001cdd81c$da365490$8ea2fdb0$@accretive-networks.net> dd if=/dev/null of=/ -----Original Message----- From: Joe Hamelin [mailto:joe at nethead.com] Sent: Tuesday, December 11, 2012 7:42 PM To: surfer at mauigateway.com Cc: nanog at nanog.org Subject: Re: nanog:/root#rmuser Please enter one or more usernames: flower_tailor Matching password entry: flower_tailor:*:13204:13204::0:0:User &:/home/flower_tailor:/bin/tcsh Is this the entry you wish to remove? y Remove user's home directory (/home/flower_tailor)? y Removing user (flower_tailor): mailspool home passwd. nanog:/root# -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From blueneon at gmail.com Wed Dec 12 04:40:43 2012 From: blueneon at gmail.com (Tom Morris) Date: Tue, 11 Dec 2012 23:40:43 -0500 Subject: In-Reply-To: References: Message-ID: // wire pin 10 to +5v void setup() { pinMode(10, OUTPUT); digitalWrite(10, LOW); } void loop() { // ha ha you'll never get here, enjoy the blue smoke } // I like to classify my occupation as "gaff taping Arduino boards to things till they 'work'" Tom Morris, KG4CYX Chairman, South Florida Tropical Hamboree Mad Scientist, Miami Children's Museum This message sent from a mobile device. Silly typos provided free of charge. On Dec 11, 2012 7:22 PM, "flower tailor" wrote: > Delete me > > From joly at punkcast.com Wed Dec 12 05:35:24 2012 From: joly at punkcast.com (Joly MacFie) Date: Wed, 12 Dec 2012 00:35:24 -0500 Subject: In-Reply-To: References: Message-ID: Is this a song by Engelbert Humperdinck? j On Tue, Dec 11, 2012 at 7:20 PM, flower tailor wrote: > Delete me > > -- --------------------------------------------------------------- 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 mail at danrl.de Wed Dec 12 11:22:09 2012 From: mail at danrl.de (Dan Luedtke) Date: Wed, 12 Dec 2012 12:22:09 +0100 Subject: Strict route filtering at IX? Message-ID: <20121212122209.1f2b08e7@marvin.nonattached.net> Hi NANOGers, tl;dr What is the best practice for filtering a large number of prefixes at an internet exchange? Yesterday I ran into problems while writing new filtering rules for my peerings at a local Exchange. My workflow probably has a flaw, although it works fine for IPv6 (well, less prefixes there). After the physical link was set up I startet a BGP session with the route server of the exchange. A few minutes later some other AS imported my prefix, e.g. those listed at HE[1]. I guess they filtered "less strict" :) The next day the exchange's route server administrator added my AS-SET to the AS-SET of the route server. --- snip RIPE DB --- as-set: AS-KLEYREX-RS1 descr: KleyReX Internet Exchange Frankfurt [...] members: AS-NONATTACHED --- snap --- A few days have passed since then but the number of peers has not increased as expected. Is this normal? My mp-* entries look like this: --- snip RIPE DB --- aut-num: AS57821 as-name: NONATTACHED-AS [...] mp-import: afi ipv4.unicast from AS31142 accept AS-KLEYREX-RS1 mp-export: afi ipv4.unicast to AS31142 announce AS-NONATTACHED --- snap --- Yesterday I thought about importing the route servers prefixes and, of course, to filter them. Using rtconfig[2] I created a filter for BIRD[3] like this: --- snip bird.conf --- if (prefix_too_long()) then reject; @rtconfig printPrefixes "if (net ~ [ %p/%l+ ]) then accept;\n" filter AS-KLEYREX-RS1 reject; --- snap --- This takes about 10-20 minutes and results in an very large config file constiting of hundreds of prefixes in IPv4. The same config file for IPv6 would be smaller. However, legacy protocol IPv4 is not yet dead so I need to filter it somehow. BIRD sometimes segfaults when it is advised to read those large filters. So, here's the question: How do you filter at exchanges? Where is the error in my workflow? Is strict route filtering a myth? Thanks for helping! Dan [1] http://bgp.he.net/AS57821#_peers [2] http://irrtoolset.isc.org/wiki/RtConfig [3] http://bird.network.cz From peterehiwe at gmail.com Wed Dec 12 12:08:16 2012 From: peterehiwe at gmail.com (Peter Ehiwe) Date: Wed, 12 Dec 2012 13:08:16 +0100 Subject: Strict route filtering at IX? In-Reply-To: <20121212122209.1f2b08e7@marvin.nonattached.net> References: <20121212122209.1f2b08e7@marvin.nonattached.net> Message-ID: I use a mixture of BGP communities and prefix lists and it scales very well for me . Rgds Peter, Sent from my Asus Transformer Pad On Dec 12, 2012 3:24 AM, "Dan Luedtke" wrote: > Hi NANOGers, > > tl;dr What is the best practice for filtering a large number of > prefixes at an internet exchange? > > Yesterday I ran into problems while writing new filtering rules for > my peerings at a local Exchange. My workflow probably has a flaw, > although it works fine for IPv6 (well, less prefixes there). > > After the physical link was set up I startet a BGP session with the > route server of the exchange. A few minutes later some other AS > imported my prefix, e.g. those listed at HE[1]. I guess they filtered > "less strict" :) > The next day the exchange's route server administrator added my AS-SET > to the AS-SET of the route server. > > --- snip RIPE DB --- > as-set: AS-KLEYREX-RS1 > descr: KleyReX Internet Exchange Frankfurt > [...] > members: AS-NONATTACHED > --- snap --- > > A few days have passed since then but the number of peers has not > increased as expected. Is this normal? > My mp-* entries look like this: > > --- snip RIPE DB --- > aut-num: AS57821 > as-name: NONATTACHED-AS > [...] > mp-import: afi ipv4.unicast from AS31142 accept AS-KLEYREX-RS1 > mp-export: afi ipv4.unicast to AS31142 announce AS-NONATTACHED > --- snap --- > > Yesterday I thought about importing the route servers prefixes and, of > course, to filter them. Using rtconfig[2] I created a filter for BIRD[3] > like this: > > --- snip bird.conf --- > if (prefix_too_long()) then reject; > @rtconfig printPrefixes "if (net ~ [ %p/%l+ ]) then accept;\n" filter > AS-KLEYREX-RS1 reject; > --- snap --- > > This takes about 10-20 minutes and results in an very large config file > constiting of hundreds of prefixes in IPv4. The same config file for > IPv6 would be smaller. However, legacy protocol IPv4 is not yet dead so > I need to filter it somehow. BIRD sometimes segfaults when it is > advised to read those large filters. > > So, here's the question: How do you filter at exchanges? > Where is the error in my workflow? > Is strict route filtering a myth? > > > Thanks for helping! > > > Dan > > [1] http://bgp.he.net/AS57821#_peers > [2] http://irrtoolset.isc.org/wiki/RtConfig > [3] http://bird.network.cz > > From randy at psg.com Wed Dec 12 15:57:11 2012 From: randy at psg.com (Randy Bush) Date: Wed, 12 Dec 2012 07:57:11 -0800 Subject: In-Reply-To: References: Message-ID: flower tailor wrote: > Delete me though possibly merciful, it is illegal in most cultures From bmanning at vacation.karoshi.com Wed Dec 12 15:59:57 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 12 Dec 2012 15:59:57 +0000 Subject: In-Reply-To: References: Message-ID: <20121212155957.GA25944@vacation.karoshi.com.> On Wed, Dec 12, 2012 at 07:57:11AM -0800, Randy Bush wrote: > flower tailor wrote: > > Delete me > > though possibly merciful, it is illegal in most cultures Montenegrins would be sad with the unilateral removal of thier TLD. /bill From jra at baylink.com Wed Dec 12 16:50:44 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 12 Dec 2012 11:50:44 -0500 (EST) Subject: Lovely release spam... In-Reply-To: <20121212002500.GA8521@jpradley.jpr.com> Message-ID: <28593979.38462.1355331044545.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jean-Pierre A. Radley" > If you weren't offended by the clumsy constructions and poor usage, > then my apologies, I'll go sulk on my own. It did seem sorta ESOL to me, but I figured piling on was mean. :-) 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 joquendo at e-fensive.net Wed Dec 12 17:28:57 2012 From: joquendo at e-fensive.net (J. Oquendo) Date: Wed, 12 Dec 2012 11:28:57 -0600 Subject: In-Reply-To: References: Message-ID: <20121212172857.GA44219@e-fensive.net> > flower tailor wrote: > > Delete me > ''=~('(?{'.('^,)@^@'^'.^@.*`').'"'.('_:$:@@,:^'^',[][./^[|').',$/})') -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF From jra at baylink.com Wed Dec 12 17:53:26 2012 From: jra at baylink.com (Jay Ashworth) Date: Wed, 12 Dec 2012 12:53:26 -0500 (EST) Subject: In-Reply-To: <20121212172857.GA44219@e-fensive.net> Message-ID: <28515155.38534.1355334806672.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "J. Oquendo" > > flower tailor wrote: > > > Delete me > > ''=~('(?{'.('^,)@^@'^'.^@.*`').'"'.('_:$:@@,:^'^',[][./^[|').',$/})') Please; no TECO on the mailing list. 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 lstewart at superb.net Wed Dec 12 23:36:59 2012 From: lstewart at superb.net (Landon Stewart) Date: Wed, 12 Dec 2012 15:36:59 -0800 Subject: Has anyone had any response from Sourceforge lately? Looking for a contact who will reply. Message-ID: Hello, Has anyone had any response from Sourceforge lately? We are looking for a contact who will reply. The staff@ type email addresses appear to go into a blackhole or something. -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From jarenangerbauer at gmail.com Wed Dec 12 23:59:20 2012 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Wed, 12 Dec 2012 16:59:20 -0700 Subject: In-Reply-To: References: Message-ID: On Tue, Dec 11, 2012 at 5:20 PM, flower tailor wrote: > Delete me > As a Dr. Who fan -- DELETE, DELETE, DELETE... From tshaw at oitc.com Thu Dec 13 00:01:41 2012 From: tshaw at oitc.com (TR Shaw) Date: Wed, 12 Dec 2012 19:01:41 -0500 Subject: In-Reply-To: References: Message-ID: EXTERMINATE, EXTERMINATE, EXTERMINATE,... On Dec 12, 2012, at 6:59 PM, Jaren Angerbauer wrote: > On Tue, Dec 11, 2012 at 5:20 PM, flower tailor wrote: >> Delete me >> > > As a Dr. Who fan -- DELETE, DELETE, DELETE... > From bblackford at gmail.com Thu Dec 13 00:05:52 2012 From: bblackford at gmail.com (Bill Blackford) Date: Wed, 12 Dec 2012 16:05:52 -0800 Subject: In-Reply-To: References: Message-ID: cybermen meet daliks. classic. On Wed, Dec 12, 2012 at 4:01 PM, TR Shaw wrote: > EXTERMINATE, EXTERMINATE, EXTERMINATE,... > > On Dec 12, 2012, at 6:59 PM, Jaren Angerbauer wrote: > > > On Tue, Dec 11, 2012 at 5:20 PM, flower tailor > wrote: > >> Delete me > >> > > > > As a Dr. Who fan -- DELETE, DELETE, DELETE... > > > > > -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From mureninc at gmail.com Thu Dec 13 08:34:43 2012 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 13 Dec 2012 00:34:43 -0800 Subject: Why do some providers require IPv6 /64 PA space to have public whois? In-Reply-To: References: Message-ID: On 10 December 2012 13:27, Schiller, Heather A wrote: > > Actually, requiring a public whois record is the way it always has been, that's only recently changed. I think most folks would agree that, IPv4 /32 :: IPv6 /128 as IPv4 /29 :: IPv6 /64 So, while you are right, that swip'ing a v4 /32 has never been required, I think your analogy of a v6 /64 to a v4 /32 is off. The minimum assignment requiring a swip is also ensconced in RIR policy. If you don't like it, may I suggest you propose policy to change it? I think your comparison of IPv4 /32 being equivalent to IPv6 /128 is only true in specific and narrow contexts outside of this discussion, and I strongly disagree with such generalisations being applied here. Just from the practical side and by means of an example, take a look at 6rd and the way other national internet providers have been implementing it. I had a routed /27 with AT&T FTTU; every IPv4 address on AT&T automatically gets a /60 IPv6 allocation; by extension, my IPv4 /27 was equivalent to IPv6 /55 (plus I also must have had one extra /60 for the IPv4 address in the shared subnet to which my /27 IPv4 subnet was routed). And Linode: upon request, they offer a free /56 to any of their customers, to complement a /32 IPv4 allocation. Many other hosting providers likewise provide a free /48 (some do this by default, some upon request) to anyone who only requires a single IPv4 address otherwise. Likewise, HE's tunnelbroker.net gives out a total of five /48's (per a single account) to anyone who asks; and if you look at it, they're still doing this out of the smallest v6 allocation compared to any other carrier: 2001:470::/32; yes, just a /32, when even Linode has a /30. http://bgp.he.net/AS6939#_prefixes6 And the same example is even true of hetzner.de: they assign a /32 IPv4 for free to every server, and the only IPv6 that they give is a /64, offering no other option at all whatsoever (they do offer the option of another, routed IPv6 /64, but that's it). Yet, unfortunately, hetzner.de is one of the few that doesn't offer any IPv6 at all unless you agree for your private data to go to a public database maintained by RIPE when you request any kind of IPv6 connectivity. It presents an obvious barrier to entry, and limits native IPv6 adoption when huge providers like hetzner.de may require you to give up your privacy for native IPv6, but not for IPv4. So, as per above, in my humble view, a /64 IPv6 allocation is equivalent to a NAT in IPv4 terms. :-) Any provider who insists otherwise (especially when it comes down to actually giving out such addresses), simply tries to be creative about their revenue streams in regards to something that's supposed to be a public resource and that's not even that scarce to begin with. > RIPE's policy: > " When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users." You have conveniently omitted the prior part of the same paragraph about PtP links. https://www.ripe.net/ripe/docs/ripe-553 IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region 21 May 2012 ? address policy, ipv4 ? 6.2 Network Infrastructure and End User Networks IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users. ? Although written with IPv4 in mind, if you take this paragraph and try to interpret it within IPv6, then the first, non-routed, /64 with hetzner.de can easily be considered a point-to-point link, and due to the plethora of free alternatives people would hardly attempt to use such an allocation in any other way than as indeed a point-to-point link, especially when a second free /64, now routed, is also available. (And even if someone would in fact use their first PtP /64 to create some kind of a VPN and a small home network, then at the internet who-to-blame level how would that be any different whatsoever from them doing a NAT with a /32 IPv4? On the other hand, I do agree that standardised aggregate whois entries detailing the size of individual allocations within a given address space would be very-very useful with IPv6, indeed (else, how do you ban a user by an IP-address?).) Also, consider why so much private information has to be published in whois in the first place: usually, it's for the issues related to network architecture, security, attacks and spam. Why would other network operators benefit from getting information about individual one-person customers of hetzner.de, instead of contact information of hetzner.de themselves? (Or am I really supposed to be getting a phone call at 03:00 in the middle of the night from a random network engineer in another part of the world who decided to visit my private website, and found my individual server misconfigured or inaccessible?) So, in my opinion, in the end, this information about individuals with /64 allocations may only end up being useful for data-miners and potentially copyright trolls. It should not be just optional to not publish such information; it should be specifically prohibited for such information to be published about individual non-company customers (unless the individual explicitly requests for any such information to be published). Many ccTLDs have already stopped providing any kind of information about their Private Person customers (not even a name, nor an email, as a matter of TLD policy). > > Note the *may* -- ISP's aren't required to support it. > > More RIPE policy.. > "When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register these assignments in the appropriate RIR database. > > These registrations can either be made as individual assignments or by inserting a object with a status value of 'AGGREGATED-BY-LIR' where the assignment-size attribute contains the size of the individual assignments made to End Users.When more than a /48 is assigned to an organisation, it must be registered in the database as a separate object with status 'ASSIGNED'." > > So they have to register it, and they get a choice about how they do it.. Your provider has chosen a way you don't like. Talk to them about it, rather than complaining on NANOG? Thank you for actually looking up the policies; I'll keep this in mind. > > > It's pretty similar in the ARIN region. In 2004, the ARIN community passed the residential customer privacy policy - specifically allowing ISP's to designate a record private. Again, it's optional. > > https://www.arin.net/policy/nrpm.html > > > Min assignment swip > 6.5.5.1. Reassignment information > > Each static IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. > > > IPv4 > 4.2.3.7.3.2. Residential Customer Privacy > > To maintain the privacy of their residential customers, an organization with downstream residential customers holding /29 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS directory record for that block. > > IPv6 > 6.5.5.3. Residential Subscribers > 6.5.5.3.1. Residential Customer Privacy > > To maintain the privacy of their residential customers, an organization with downstream residential customers holding /64 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. What are the exceptions to 6.5.5.1? In other news, Linode has a /30 IPv6 in the US with ARIN, using a /32 for each of their 4 sites within the US (thus already exhausting their original allocation), and it seems like they have absolutely no whois records anywhere (neither for their customers, nor even for their own distinct sites); the only whois you get is for their actual original /30 allocation from ARIN! http://bgp.he.net/net/2600:3c01::/32 -- no individual whois for their Fremont location. For IPv4, they likewise didn't seem to have bothered creating any individual SWIP entries even for each of their own sites (which are all run as separate networks); all their allocations only show their New Jersey address, and, basically, the following comment: Comment: This block is used for static customer allocations. Are they somehow exempt, or are they blatantly violating every ARIN policy imaginable? I also know of at least one other provider who gave me a /48 from their ARIN-issued space without doing any kind of a whois record within their /32, but they have only a single physical site, so it's not such a big deal, IMHO. Also, I notice that your policies at ARIN have exceptions explicitly for Residential Customers, but what about individuals renting network resources in the cloud? Are such individuals suddenly not officially exempt? C. > > > --Heather > > > -----Original Message----- > From: Constantine A. Murenin [mailto:mureninc at gmail.com] > Sent: Saturday, December 08, 2012 12:46 AM > To: nanog at nanog.org > Subject: Why do some providers require IPv6 /64 PA space to have public whois? > > Hello, > > I personally don't understand this policy. I've signed up with hetzner.de, and I'm trying to get IPv6; however, on the supplementary page where the complementary IPv6 /64 subnet can be requested (notice that it's not even a /48, and not even the second, routed, /64), after I change the selection from requesting one additional IPv4 address to requesting the IPv6 /64 subnet (they offer no other IPv6 options in that menu), they use DOM to remove the IP address justification field ("Purpose of use"), and instead statically show my name, physical street address (including the apartment number), email address and phone number, and ask to confirm that all of this information can be submitted to RIPE. > > They offer no option of modifying any of this; they also offer no option of hiding the street address and showing it as "Private Address" instead; they also offer no option of providing contact information different from the contact details for the main profile or keeping a separate set of contact details in the main profile specifically for RIPE; they also offer no option of providing a RIPE handle instead (dunno if one can be registered with a "Private Address" address, showing only city/state/country and postal code; I do know that with ARIN and PA IPv4 subnets you can do "Private Address" in the Address field); they also don't let you submit the form unless you agree for the information shown to be passed along to RIPE for getting IPv6 connectivity (again, no IPv6 is provided by default or otherwise). > > Is this what we're going towards? No probable cause and no court orders for obtaining individually identifying information about internet customers with IPv6 addresses? In the future, will the copyright trolls be getting this information directly from public whois, bypassing the internet provider abuse teams and even the most minimal court supervision? Is this really the disadvantage of IPv4 that IPv6 proudly fixes? I certainly have never heard of whois entries for /32 IPv4 address allocations! > > Anyhow, just one more provider where it's easier to use HE's tunnelbroker.net instead of obtaining IPv6 natively; due to the data-mining and privacy concerns now. What's the point of native IPv6 connectivity again? In hetzner.de terms, tunnelbroker.net even provides you with the failover IPv6 address(es), something that they themselves only offer for IPv4! > > Is it just me, or are there a lot of other folks who use tunnelbroker.net even when their ISP offers native IPv6 support? > Might be interesting for HE.net to make some kind of a study. :-) > > Cheers, > Constantine. From wingar at team-metro.net Wed Dec 12 01:11:23 2012 From: wingar at team-metro.net (Emily Ozols) Date: Wed, 12 Dec 2012 12:11:23 +1100 Subject: In-Reply-To: References: <50C7D79E.6060904@tiedyenetworks.com> Message-ID: ^U On Wed, Dec 12, 2012 at 12:07 PM, chris wrote: > ^H > > On Tue, Dec 11, 2012 at 8:02 PM, Mike wrote: > >> On 12/11/2012 04:20 PM, flower tailor wrote: >> >>> Delete me >>> >>> >> >> >> You are deleted. >> >> >> -- ~Em From s.ryan at uber.com.au Thu Dec 13 08:37:15 2012 From: s.ryan at uber.com.au (Seamus Ryan) Date: Thu, 13 Dec 2012 08:37:15 +0000 Subject: Has anyone had any response from Sourceforge lately? Looking for a contact who will reply. In-Reply-To: References: Message-ID: <3F1DEC33DC0C274C99B16F166A25DF756AA2E7A9@aucbr1ex1.ahq.net.au> I have, However I was informed the operators were in the middle of a large project at present which means most things are being pushed to a side for several weeks. Regards, Seamus -----Original Message----- From: Landon Stewart [mailto:lstewart at superb.net] Sent: Thursday, 13 December 2012 10:37 AM To: NANOG list Subject: Has anyone had any response from Sourceforge lately? Looking for a contact who will reply. Hello, Has anyone had any response from Sourceforge lately? We are looking for a contact who will reply. The staff@ type email addresses appear to go into a blackhole or something. -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From elouie at yahoo.com Thu Dec 13 01:22:36 2012 From: elouie at yahoo.com (Eric A Louie) Date: Wed, 12 Dec 2012 17:22:36 -0800 (PST) Subject: IP Address Management IPAM software for small ISP Message-ID: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small staff of engineers. They have regionalized IP addresses so blocks are local, but there are subnets that are global. don't care if it's a linux or windows solution. Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) We're not dealing with a lot now, but the potential for growth is pretty high. What are you using and how is it working for you? Much appreciated, Eric From aftab.siddiqui at gmail.com Thu Dec 13 10:10:23 2012 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Thu, 13 Dec 2012 15:10:23 +0500 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: Kindly search the archives for many threads on the same subject, which should be the normal practice. nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The first one I assume should serve your purpose for both v4 and v6. Regards, Aftab A. Siddiqui On Thu, Dec 13, 2012 at 6:22 AM, Eric A Louie wrote: > I'm looking for IPAM solutions for a small regional wireless ISP. There > are 4 > Tier 2 personnel and 2 NOC technicians who would be using the tool, and a > small > staff of engineers. > > They have regionalized IP addresses so blocks are local, but there are > subnets > that are global. > > don't care if it's a linux or windows solution. > > Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) > > We're not dealing with a lot now, but the potential for growth is pretty > high. > > What are you using and how is it working for you? > > Much appreciated, Eric > From nick at foobar.org Thu Dec 13 10:25:00 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 13 Dec 2012 10:25:00 +0000 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: <50C9ACFC.1050004@foobar.org> On 13/12/2012 10:10, Aftab Siddiqui wrote: > nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The > first one I assume should serve your purpose for both v4 and v6. I've had a lot more success with Racktables and Netdot, both of which are really good at what they do. Racktables in particular. Nick From froztbyte at froztbyte.net Thu Dec 13 10:31:15 2012 From: froztbyte at froztbyte.net (JP Viljoen) Date: Thu, 13 Dec 2012 12:31:15 +0200 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <50C9ACFC.1050004@foobar.org> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <50C9ACFC.1050004@foobar.org> Message-ID: <3A6EB8A6-47DF-4CDB-8658-770548448E85@froztbyte.net> On 13 Dec 2012, at 12:25 PM, Nick Hilliard wrote: > On 13/12/2012 10:10, Aftab Siddiqui wrote: >> nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The >> first one I assume should serve your purpose for both v4 and v6. > > I've had a lot more success with Racktables and Netdot, both of which are > really good at what they do. Racktables in particular. +2c on racktables. Right now we're deprecating IPPlan entirely in favour of Racktables. One day I'll have a round tuit for checking out Netdot. -J From jloiacon at csc.com Thu Dec 13 15:30:14 2012 From: jloiacon at csc.com (Joe Loiacono) Date: Thu, 13 Dec 2012 10:30:14 -0500 Subject: Has anyone had any response from Sourceforge lately? Looking for a contact who will reply. In-Reply-To: <3F1DEC33DC0C274C99B16F166A25DF756AA2E7A9@aucbr1ex1.ahq.net.au> References: <3F1DEC33DC0C274C99B16F166A25DF756AA2E7A9@aucbr1ex1.ahq.net.au> Message-ID: I have had success in the recent past using their chat channel ... http://webchat.freenode.net/?randomnick=0&channels=sourceforge Joe From: Seamus Ryan To: "'NANOG list'" Date: 12/13/2012 04:28 AM Subject: RE: Has anyone had any response from Sourceforge lately? Looking for a contact who will reply. I have, However I was informed the operators were in the middle of a large project at present which means most things are being pushed to a side for several weeks. Regards, Seamus -----Original Message----- From: Landon Stewart [mailto:lstewart at superb.net] Sent: Thursday, 13 December 2012 10:37 AM To: NANOG list Subject: Has anyone had any response from Sourceforge lately? Looking for a contact who will reply. Hello, Has anyone had any response from Sourceforge lately? We are looking for a contact who will reply. The staff@ type email addresses appear to go into a blackhole or something. -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From Josh.Hoppes at cfunet.net Thu Dec 13 16:26:16 2012 From: Josh.Hoppes at cfunet.net (Josh V. Hoppes) Date: Thu, 13 Dec 2012 16:26:16 +0000 Subject: Rack space at 1102 Grand St in Kansas City Message-ID: Looking to see if anyone has 2U of space available at 1102 Grand in Kansas City. We are looking to rack up a router and get a couple single mode cross connects, nothing huge but will be long term and we would expect a contract to be worked out. Joshua Hoppes Network Engineer Cedar Falls Utilities From lstewart at superb.net Thu Dec 13 16:48:17 2012 From: lstewart at superb.net (Landon Stewart) Date: Thu, 13 Dec 2012 08:48:17 -0800 Subject: Has anyone had any response from Sourceforge lately? Looking for a contact who will reply. In-Reply-To: References: <3F1DEC33DC0C274C99B16F166A25DF756AA2E7A9@aucbr1ex1.ahq.net.au> Message-ID: Thanks guys for everyone who replied on and off list. I appreciate it immensely. On 13 December 2012 07:30, Joe Loiacono wrote: > I have had success in the recent past using their chat channel ... > > http://webchat.freenode.net/?randomnick=0&channels=sourceforge > > Joe > > > > From: Seamus Ryan > To: "'NANOG list'" > Date: 12/13/2012 04:28 AM > Subject: RE: Has anyone had any response from Sourceforge lately? > Looking for a contact who will reply. > > > > I have, > > However I was informed the operators were in the middle of a large project > at present which means most things are being pushed to a side for several > weeks. > > Regards, > Seamus > > -----Original Message----- > From: Landon Stewart [mailto:lstewart at superb.net] > Sent: Thursday, 13 December 2012 10:37 AM > To: NANOG list > Subject: Has anyone had any response from Sourceforge lately? Looking for > a contact who will reply. > > Hello, > > Has anyone had any response from Sourceforge lately? We are looking for a > contact who will reply. The staff@ type email addresses appear to go into > a blackhole or something. > > -- > Landon Stewart > Sr. Administrator > Systems Engineering > Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of > the Rest": http://www.superbhosting.net > > > -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From eyeronic.design at gmail.com Thu Dec 13 17:07:47 2012 From: eyeronic.design at gmail.com (Mike Hale) Date: Thu, 13 Dec 2012 09:07:47 -0800 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <3A6EB8A6-47DF-4CDB-8658-770548448E85@froztbyte.net> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <50C9ACFC.1050004@foobar.org> <3A6EB8A6-47DF-4CDB-8658-770548448E85@froztbyte.net> Message-ID: I've used IPPlan in the past, and it's really useful as a web-based excel-sheet replacement. Plus, the price is right. We're also evaluating Solarwinds' IPAM, but that's way too expensive for the features. On Thu, Dec 13, 2012 at 2:31 AM, JP Viljoen wrote: > On 13 Dec 2012, at 12:25 PM, Nick Hilliard wrote: > > On 13/12/2012 10:10, Aftab Siddiqui wrote: > >> nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. > The > >> first one I assume should serve your purpose for both v4 and v6. > > > > I've had a lot more success with Racktables and Netdot, both of which are > > really good at what they do. Racktables in particular. > > +2c on racktables. Right now we're deprecating IPPlan entirely in favour > of Racktables. One day I'll have a round tuit for checking out Netdot. > > -J > > > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From jeremy at vcn.com Thu Dec 13 17:13:47 2012 From: jeremy at vcn.com (Jeremy Malli) Date: Thu, 13 Dec 2012 10:13:47 -0700 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: <50CA0CCB.4000103@vcn.com> A colleague and myself wrote one in PHP that supports v4 and v6. It's available on sourceforge: http://sourceforge.net/projects/subnetsmngr/?source=directory We like it. Features Manage subnets and hosts IPv4 and IPv6 support All subnetting math done for you. Auto-allocates and collapses subnets Subnet groups Assign customers to subnets and send SWIPs to ARIN PowerDNS integration to update reverse and A records for hosts Jeremy Malli Mammoth Networks On 12/12/2012 6:22 PM, Eric A Louie wrote: > I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 > Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small > staff of engineers. > > They have regionalized IP addresses so blocks are local, but there are subnets > that are global. > > don't care if it's a linux or windows solution. > > Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) > > We're not dealing with a lot now, but the potential for growth is pretty high. > > What are you using and how is it working for you? > > Much appreciated, Eric > From elouie at yahoo.com Thu Dec 13 17:48:43 2012 From: elouie at yahoo.com (Eric A Louie) Date: Thu, 13 Dec 2012 09:48:43 -0800 (PST) Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: <1355420923.81147.YahooMailRC@web181601.mail.ne1.yahoo.com> That is a superb suggestion, Aftab. I actually did a search through the archives for "IPAM" and "IP address management" and the results were ... unsatisfactory. Perhaps I used the wrong archive, and you direct me to an alternate: http://mailman.nanog.org/pipermail/nanog/ is the one I used. I've looked at IPPLan but have not installed it yet. Does anyone with direct experience with it care to share their view? Much appreciated, Eric ________________________________ From: Aftab Siddiqui To: Eric A Louie Cc: NANOG Operators' Group Sent: Thu, December 13, 2012 2:10:24 AM Subject: Re: IP Address Management IPAM software for small ISP Kindly search the archives for many threads on the same subject, which should be the normal practice. nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The first one I assume should serve your purpose for both v4 and v6. Regards, Aftab A. Siddiqui On Thu, Dec 13, 2012 at 6:22 AM, Eric A Louie wrote: I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 >Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small >staff of engineers. > >They have regionalized IP addresses so blocks are local, but there are subnets >that are global. > >don't care if it's a linux or windows solution. > >Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) > >We're not dealing with a lot now, but the potential for growth is pretty high. > >What are you using and how is it working for you? > > Much appreciated, Eric > From elouie at yahoo.com Thu Dec 13 17:54:11 2012 From: elouie at yahoo.com (Eric A Louie) Date: Thu, 13 Dec 2012 09:54:11 -0800 (PST) Subject: IP Address Management IPAM software for small ISP In-Reply-To: <50C9ACFC.1050004@foobar.org> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <50C9ACFC.1050004@foobar.org> Message-ID: <1355421251.52703.YahooMailRC@web181604.mail.ne1.yahoo.com> Racktables = no IPv6. Bummer, and it does more than what I need. Netdot looks very interesting. It didn't show up when I searched for "IPAM". I'll have to evaluate it, to see if it does any kind of wireless documentation (frequency, modulation, etc) Any Netdot users out there who want to comment? Much appreciated, Eric ________________________________ From: Nick Hilliard To: Aftab Siddiqui Cc: Eric A Louie ; NANOG Operators' Group Sent: Thu, December 13, 2012 2:25:10 AM Subject: Re: IP Address Management IPAM software for small ISP On 13/12/2012 10:10, Aftab Siddiqui wrote: > nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The > first one I assume should serve your purpose for both v4 and v6. I've had a lot more success with Racktables and Netdot, both of which are really good at what they do. Racktables in particular. Nick From elouie at yahoo.com Thu Dec 13 17:59:41 2012 From: elouie at yahoo.com (Eric A Louie) Date: Thu, 13 Dec 2012 09:59:41 -0800 (PST) Subject: IP Address Management IPAM software for small ISP In-Reply-To: <50CA01A7.5060908@mammothnetworks.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <50CA01A7.5060908@mammothnetworks.com> Message-ID: <1355421581.87039.YahooMailRC@web181603.mail.ne1.yahoo.com> Thanks Jeremy - looks pretty good, and specific, and I like the DNS integration. I haven't downloaded or installed it yet. Do you think it's robust enough for a 24x7 Network Operations Center that has 8 or so users? Is the database a flat file that is easily backed up and restored? or are you using MySQL? Much appreciated, Eric ________________________________ From: Jeremy Malli To: nanog at nanog.org; elouie at yahoo.com Sent: Thu, December 13, 2012 8:26:17 AM Subject: Re: IP Address Management IPAM software for small ISP A colleague and myself wrote one in PHP that supports v4 and v6. It's available on sourceforge: http://sourceforge.net/projects/subnetsmngr/?source=directory Jeremy Malli Mammoth Networks On 12/12/2012 6:22 PM, Eric A Louie wrote: > I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 > Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small > staff of engineers. > > They have regionalized IP addresses so blocks are local, but there are subnets > that are global. > > don't care if it's a linux or windows solution. > > Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) > > We're not dealing with a lot now, but the potential for growth is pretty high. > > What are you using and how is it working for you? > > Much appreciated, Eric > From jeremy at vcn.com Thu Dec 13 18:08:46 2012 From: jeremy at vcn.com (Jeremy Malli) Date: Thu, 13 Dec 2012 11:08:46 -0700 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1355421581.87039.YahooMailRC@web181603.mail.ne1.yahoo.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <50CA01A7.5060908@mammothnetworks.com> <1355421581.87039.YahooMailRC@web181603.mail.ne1.yahoo.com> Message-ID: <50CA19AE.5060206@vcn.com> We're running postgres on the backend due to a limitation we ran into when implementing v6 support in mysql. So standard postgres backup practices would apply. We also run a 24x7 NOC though only 4 support people. It's light on database access so I can't imagine you would have a problem with robustness (it's just PHP/Postgres). We have 8 /19's, a /32 v6 block and a smattering of other blocks that are managed using it. Jeremy On 12/13/2012 10:59 AM, Eric A Louie wrote: > Thanks Jeremy - looks pretty good, and specific, and I like the DNS > integration. I haven't downloaded or installed it yet. > > Do you think it's robust enough for a 24x7 Network Operations Center > that has 8 or so users? > > Is the database a flat file that is easily backed up and restored? or > are you using MySQL? > Much appreciated, Eric > > > ------------------------------------------------------------------------ > *From:* Jeremy Malli > *To:* nanog at nanog.org; elouie at yahoo.com > *Sent:* Thu, December 13, 2012 8:26:17 AM > *Subject:* Re: IP Address Management IPAM software for small ISP > > A colleague and myself wrote one in PHP that supports v4 and v6. It's > available on sourceforge: > > http://sourceforge.net/projects/subnetsmngr/?source=directory > > Jeremy Malli > Mammoth Networks > > On 12/12/2012 6:22 PM, Eric A Louie wrote: > > I'm looking for IPAM solutions for a small regional wireless ISP. > There are 4 > > Tier 2 personnel and 2 NOC technicians who would be using the tool, > and a small > > staff of engineers. > > > > They have regionalized IP addresses so blocks are local, but there > are subnets > > that are global. > > > > don't care if it's a linux or windows solution. > > > > Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) > > > > We're not dealing with a lot now, but the potential for growth is > pretty high. > > > > What are you using and how is it working for you? > > > > Much appreciated, Eric > > From walter.keen at rainierconnect.net Thu Dec 13 18:15:13 2012 From: walter.keen at rainierconnect.net (Walter Keen) Date: Thu, 13 Dec 2012 10:15:13 -0800 (PST) Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1355421251.52703.YahooMailRC@web181604.mail.ne1.yahoo.com> Message-ID: <1769057621.6403550.1355422513792.JavaMail.root@zimbra01.rainierconnect.net> We've been using ipplan, although it seems the racktables demo site does support ipv6. It looks interesting because it could help us in other ways. Still kind of stuck on ipplan until I find a better solution that understands multiple routing tables since I have many mpls vpn's with overlapping address space. ----- Original Message ----- From: "Eric A Louie" To: "Nick Hilliard" , "Aftab Siddiqui" Cc: "NANOG Operators' Group" Sent: Thursday, December 13, 2012 9:54:11 AM Subject: Re: IP Address Management IPAM software for small ISP Racktables = no IPv6. Bummer, and it does more than what I need. Netdot looks very interesting. It didn't show up when I searched for "IPAM". I'll have to evaluate it, to see if it does any kind of wireless documentation (frequency, modulation, etc) Any Netdot users out there who want to comment? Much appreciated, Eric ________________________________ From: Nick Hilliard To: Aftab Siddiqui Cc: Eric A Louie ; NANOG Operators' Group Sent: Thu, December 13, 2012 2:25:10 AM Subject: Re: IP Address Management IPAM software for small ISP On 13/12/2012 10:10, Aftab Siddiqui wrote: > nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The > first one I assume should serve your purpose for both v4 and v6. I've had a lot more success with Racktables and Netdot, both of which are really good at what they do. Racktables in particular. Nick From bross at pobox.com Thu Dec 13 18:25:19 2012 From: bross at pobox.com (Brandon Ross) Date: Thu, 13 Dec 2012 13:25:19 -0500 (EST) Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1769057621.6403550.1355422513792.JavaMail.root@zimbra01.rainierconnect.net> References: <1769057621.6403550.1355422513792.JavaMail.root@zimbra01.rainierconnect.net> Message-ID: I think 6connect is well worth an eval as well. We've been using it for the InteropNet for a couple of years now and it nicely meets our needs in both v4 and v6, and since you can get it as a hosted application, for a small shop there's zero maintenance. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From matt.addison at lists.evilgeni.us Thu Dec 13 19:04:30 2012 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Thu, 13 Dec 2012 14:04:30 -0500 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1769057621.6403550.1355422513792.JavaMail.root@zimbra01.rainierconnect.net> References: <1769057621.6403550.1355422513792.JavaMail.root@zimbra01.rainierconnect.net> Message-ID: <-3424806920729300595@unknownmsgid> phpipam's VRF support looks fairly decent if you haven't checked it out yet. Sent from my iPad On Dec 13, 2012, at 13:15, Walter Keen wrote: > We've been using ipplan, although it seems the racktables demo site does support ipv6. It looks interesting because it could help us in other ways. > > Still kind of stuck on ipplan until I find a better solution that understands multiple routing tables since I have many mpls vpn's with overlapping address space. > > > > > ----- Original Message ----- > > From: "Eric A Louie" > To: "Nick Hilliard" , "Aftab Siddiqui" > Cc: "NANOG Operators' Group" > Sent: Thursday, December 13, 2012 9:54:11 AM > Subject: Re: IP Address Management IPAM software for small ISP > > Racktables = no IPv6. Bummer, and it does more than what I need. > > Netdot looks very interesting. It didn't show up when I searched for "IPAM". > I'll have to evaluate it, to see if it does any kind of wireless documentation > (frequency, modulation, etc) > > Any Netdot users out there who want to comment? > > Much appreciated, Eric > > > > > ________________________________ > From: Nick Hilliard > To: Aftab Siddiqui > Cc: Eric A Louie ; NANOG Operators' Group > Sent: Thu, December 13, 2012 2:25:10 AM > Subject: Re: IP Address Management IPAM software for small ISP > > On 13/12/2012 10:10, Aftab Siddiqui wrote: >> nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The >> first one I assume should serve your purpose for both v4 and v6. > > I've had a lot more success with Racktables and Netdot, both of which are > really good at what they do. Racktables in particular. > > Nick > From cconn at b2b2c.ca Thu Dec 13 19:04:44 2012 From: cconn at b2b2c.ca (Chris Conn) Date: Thu, 13 Dec 2012 14:04:44 -0500 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: Message-ID: <50CA26CC.4020403@b2b2c.ca> > looking for IPAM solutions for a small regional wireless ISP. > There are 4 Tier 2 personnel and 2 NOC technicians who would be using > the tool, and a small staff of engineers. > Nobody uses HaCI? From nick at foobar.org Thu Dec 13 19:09:07 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 13 Dec 2012 19:09:07 +0000 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1355421251.52703.YahooMailRC@web181604.mail.ne1.yahoo.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <50C9ACFC.1050004@foobar.org> <1355421251.52703.YahooMailRC@web181604.mail.ne1.yahoo.com> Message-ID: <69901DB1-B34D-4DB8-BE01-847DDBFB423B@foobar.org> On 13 Dec 2012, at 17:54, Eric A Louie wrote: > Racktables = no IPv6. Bummer, and it does more than what I need. Really? I could have sworn I was entering ipv6 data into the ipv6 section in racktables yesterday. > Netdot looks very interesting. It didn't show up when I searched for "IPAM". I'll have to evaluate it, to see if it does any kind of wireless documentation (frequency, modulation, etc) No, it doesn't do that. Nick > > Any Netdot users out there who want to comment? > > Much appreciated, Eric > > > From: Nick Hilliard > To: Aftab Siddiqui > Cc: Eric A Louie ; NANOG Operators' Group > Sent: Thu, December 13, 2012 2:25:10 AM > Subject: Re: IP Address Management IPAM software for small ISP > > On 13/12/2012 10:10, Aftab Siddiqui wrote: > > nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The > > first one I assume should serve your purpose for both v4 and v6. > > I've had a lot more success with Racktables and Netdot, both of which are > really good at what they do. Racktables in particular. > > Nick > From thilo.bangert at gmail.com Thu Dec 13 19:31:02 2012 From: thilo.bangert at gmail.com (Thilo Bangert) Date: Thu, 13 Dec 2012 20:31:02 +0100 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: <2034307.lMOFaaZu3N@marsupilami> On Wednesday 12 December 2012 17:22:36 Eric A Louie wrote: > What are you using and how is it working for you? we are using tipp, and while it doesnt cover all our needs (yet), it's worth a look: http://tipp.tobez.org/ https://github.com/tobez/tipp From mwalter at 3z.net Thu Dec 13 20:25:34 2012 From: mwalter at 3z.net (Mike Walter) Date: Thu, 13 Dec 2012 20:25:34 +0000 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: Eric, you should look at 6connect. They have a good product for IPv4 and IPv6 address management. -Mike -----Original Message----- From: Eric A Louie [mailto:elouie at yahoo.com] Sent: Wednesday, December 12, 2012 8:23 PM To: nanog at nanog.org Subject: IP Address Management IPAM software for small ISP I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small staff of engineers. They have regionalized IP addresses so blocks are local, but there are subnets that are global. don't care if it's a linux or windows solution. Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) We're not dealing with a lot now, but the potential for growth is pretty high. What are you using and how is it working for you? Much appreciated, Eric From dhubbard at dino.hostasaurus.com Thu Dec 13 20:28:11 2012 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 13 Dec 2012 15:28:11 -0500 Subject: IP Address Management IPAM software for small ISP References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <50C9ACFC.1050004@foobar.org> <3A6EB8A6-47DF-4CDB-8658-770548448E85@froztbyte.net> Message-ID: From: Mike Hale [mailto:eyeronic.design at gmail.com] > > We're also evaluating Solarwinds' IPAM, but that's way too > expensive for the features. > We've got their netflow software and were considering their IPAM for the seamless integration but you're definitely right on the price; it would have been cost nearly the same as adding an annual full time employee just to manage a few /21's and an /18.... insane. From elouie at yahoo.com Thu Dec 13 20:48:02 2012 From: elouie at yahoo.com (Eric A Louie) Date: Thu, 13 Dec 2012 12:48:02 -0800 (PST) Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: <1355431682.46026.YahooMailRC@web181602.mail.ne1.yahoo.com> It looks like it's hosted only - true? That's neither a good or bad - but the MRC could be a concern. Much appreciated, Eric ________________________________ From: Mike Walter To: Eric A Louie ; "nanog at nanog.org" Sent: Thu, December 13, 2012 12:25:44 PM Subject: RE: IP Address Management IPAM software for small ISP Eric, you should look at 6connect. They have a good product for IPv4 and IPv6 address management. -Mike -----Original Message----- From: Eric A Louie [mailto:elouie at yahoo.com] Sent: Wednesday, December 12, 2012 8:23 PM To: nanog at nanog.org Subject: IP Address Management IPAM software for small ISP I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small staff of engineers. They have regionalized IP addresses so blocks are local, but there are subnets that are global. don't care if it's a linux or windows solution. Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) We're not dealing with a lot now, but the potential for growth is pretty high. What are you using and how is it working for you? Much appreciated, Eric From ekim.ittag at gmail.com Thu Dec 13 21:21:17 2012 From: ekim.ittag at gmail.com (Mike Gatti) Date: Thu, 13 Dec 2012 13:21:17 -0800 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1355420923.81147.YahooMailRC@web181601.mail.ne1.yahoo.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <1355420923.81147.YahooMailRC@web181601.mail.ne1.yahoo.com> Message-ID: <5C06E5A5-AB00-4DBA-8887-59A641ED5CFB@gmail.com> We migrated from excel to IPPLAN (fairly large corp. network, with 150+ global locations),very easy to setup and import data (CSV). Your cost to try it out is near $0 (only money spent is your own $hour). So far the only issue that we encounter now and then is with the search function, though we haven't had time to tshoot. Other than that I think it's a solid solution, and you can't beat the price :) -- Michael Gatti main. 949.371.5474 (UTC -8) On Dec 13, 2012, at 9:48 AM, Eric A Louie wrote: > That is a superb suggestion, Aftab. I actually did a search through the > archives for "IPAM" and "IP address management" and the results were ... > unsatisfactory. Perhaps I used the wrong archive, and you direct me to an > alternate: > > http://mailman.nanog.org/pipermail/nanog/ is the one I used. > > I've looked at IPPLan but have not installed it yet. Does anyone with direct > experience with it care to share their view? > > Much appreciated, Eric > > > > > ________________________________ > From: Aftab Siddiqui > To: Eric A Louie > Cc: NANOG Operators' Group > Sent: Thu, December 13, 2012 2:10:24 AM > Subject: Re: IP Address Management IPAM software for small ISP > > Kindly search the archives for many threads on the same subject, which should be > the normal practice. > > nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The first > one I assume should serve your purpose for both v4 and v6. > > > > > Regards, > > Aftab A. Siddiqui > > > > On Thu, Dec 13, 2012 at 6:22 AM, Eric A Louie wrote: > > I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 >> Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small >> staff of engineers. >> >> They have regionalized IP addresses so blocks are local, but there are subnets >> that are global. >> >> don't care if it's a linux or windows solution. >> >> Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) >> >> We're not dealing with a lot now, but the potential for growth is pretty high. >> >> What are you using and how is it working for you? >> >> Much appreciated, Eric >> From matt.addison at lists.evilgeni.us Thu Dec 13 21:30:57 2012 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Thu, 13 Dec 2012 16:30:57 -0500 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1355431682.46026.YahooMailRC@web181602.mail.ne1.yahoo.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <1355431682.46026.YahooMailRC@web181602.mail.ne1.yahoo.com> Message-ID: <-5135720241368173534@unknownmsgid> They've had an on-premise product in the past, I'm sure it's still an option. Last time I looked at their VRF support it was still lacking, there's supposed to be improvements to it in 1Q13. Sent from my mobile device, so please excuse any horrible misspellings. On Dec 13, 2012, at 15:48, Eric A Louie wrote: > It looks like it's hosted only - true? That's neither a good or bad - but the > MRC could be a concern. > > > Much appreciated, Eric > > > > > ________________________________ > From: Mike Walter > To: Eric A Louie ; "nanog at nanog.org" > Sent: Thu, December 13, 2012 12:25:44 PM > Subject: RE: IP Address Management IPAM software for small ISP > > Eric, you should look at 6connect. They have a good product for IPv4 and IPv6 > address management. > > -Mike > > -----Original Message----- > From: Eric A Louie [mailto:elouie at yahoo.com] > Sent: Wednesday, December 12, 2012 8:23 PM > To: nanog at nanog.org > Subject: IP Address Management IPAM software for small ISP > > I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 > Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small > staff of engineers. > > They have regionalized IP addresses so blocks are local, but there are subnets > that are global. > > don't care if it's a linux or windows solution. > > Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) > > We're not dealing with a lot now, but the potential for growth is pretty high. > > What are you using and how is it working for you? > > Much appreciated, Eric From brett at the-watsons.org Thu Dec 13 21:33:53 2012 From: brett at the-watsons.org (Brett Watson) Date: Thu, 13 Dec 2012 16:33:53 -0500 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: <0D414B74-7782-411C-BA12-F851C3435918@the-watsons.org> On Dec 13, 2012, at 3:25 PM, Mike Walter wrote: > Eric, you should look at 6connect. They have a good product for IPv4 and IPv6 address management. Agreed, good product, and they have tie-ins to the Registries for filling out and submitting request templates, etc. -b From nick at foobar.org Thu Dec 13 22:28:45 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 13 Dec 2012 22:28:45 +0000 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <50CA26CC.4020403@b2b2c.ca> References: <50CA26CC.4020403@b2b2c.ca> Message-ID: <50CA569D.9060208@foobar.org> On 13/12/2012 19:04, Chris Conn wrote: > Nobody uses HaCI? I trialled it for an afternoon before blowing it away. I also had a look at tipp, phpipam and a couple of others before settling on netdot for one client and racktables for another. I also got a quote for BT Diamond IP. I managed to stop laughing some weeks later when I found that they had put me on some spam list of theirs with no unsubscribe option and no response to manual unsubscribe requests (although to be fair, they took me off their spam list about a year later after several more manual requests to be removed). Nick From castongj at umd.edu Thu Dec 13 22:54:41 2012 From: castongj at umd.edu (Jason Castonguay) Date: Thu, 13 Dec 2012 17:54:41 -0500 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its_I?= =?windows-1252?Q?Pv4_address_on_the_3rd_of_January=2E?= Message-ID: <50CA5CB1.8010306@umd.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Advisory ? D-root is changing its IPv4 address on the 3rd of January. This is advance notice that there is a scheduled change to the IPv4 address for one of the authorities listed for the DNS root zone and the .ARPA TLD. The change is to D.ROOT-SERVERS.NET, which is administered by the University of Maryland. The new IPv4 address for this authority is 199.7.91.13 The current IPv6 address for this authority is 2001:500:2d::d and it will continue to remain unchanged. This change is anticipated to be implemented in the root zone on 3 January 2013, however the new address is currently operational. It will replace the previous IP address of 128.8.10.90 (also once known as TERP.UMD.EDU). We encourage operators of DNS infrastructure to update any references to the old IP address, and replace it with the new address. In particular, many DNS resolvers have a DNS root ?hints? file. This should be updated with the new IP address. New hints files will be available at the following URLs once the change has been formally executed: http://www.internic.net/domain/named.root http://www.internic.net/domain/named.cache The old address will continue to work for at least six months after the transition, but will ultimately be retired from service. - -- Jason Castonguay Network Integration Software Engineer Division of Information Technology University of Maryland College Park, MD 20742 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDKXLEACgkQA5NiLuECHn4lRQCgoOlYQhq+kXk2Az3nPeN1hUfz 0e4AoKCwp0cLpABJFc/7RV5E/ecfWwoJ =ktnM -----END PGP SIGNATURE----- From nanog at afxr.net Fri Dec 14 15:47:03 2012 From: nanog at afxr.net (Randy) Date: Fri, 14 Dec 2012 09:47:03 -0600 Subject: Gmail and SSL Message-ID: <50CB49F7.5050304@afxr.net> I'm hoping to reach out to google's gmail engineers with this message, Today I noticed that for the past 3 days, email messages from my personal website's pop3 were not being received into my gmail inbox. Naturally, I figured that my pop3 service was down, but after some checking, every thing was working OK. I then checked gmail settings, and noticed some error. It explained that google is no longer accepting self signed ssl certificates. It claims that this change will "offer[s] a higher level of security to better protect your information". I don't believe that this change offers better security. In fact it is now unsecured - I am unable to use ssl with gmail, I have had to select the plain-text pop3 option. I don't have hundreds of dollars to get my ssl certificates signed, and to top it off, gmail never notified me of an error with fetching my mail. How many of email accounts trying to grab mail are failing now? I bet thousands, as a self signed certificate is a valid way of encrypting the traffic. Please google, remove this requirement. Source: http://support.google.com/mail/bin/answer.py?hl=en&answer=21291&ctx=gmail#strictSSL From john-nanog at johnpeach.com Fri Dec 14 15:51:30 2012 From: john-nanog at johnpeach.com (John Peach) Date: Fri, 14 Dec 2012 10:51:30 -0500 Subject: Gmail and SSL In-Reply-To: <50CB49F7.5050304@afxr.net> References: <50CB49F7.5050304@afxr.net> Message-ID: <20121214105130.68c6003e@godzilla> On Fri, 14 Dec 2012 09:47:03 -0600 Randy wrote: > I'm hoping to reach out to google's gmail engineers with this message, > Today I noticed that for the past 3 days, email messages from my > personal website's pop3 were not being received into my gmail inbox. > Naturally, I figured that my pop3 service was down, but after some > checking, every thing was working OK. I then checked gmail settings, and > noticed some error. > It explained that google is no longer accepting self signed ssl > certificates. It claims that this change will "offer[s] a higher level > of security to better protect your information". > I don't believe that this change offers better security. In fact it is > now unsecured - I am unable to use ssl with gmail, I have had to select > the plain-text pop3 option. > > I don't have hundreds of dollars to get my ssl certificates signed, and > to top it off, gmail never notified me of an error with fetching my > mail. How many of email accounts trying to grab mail are failing now? I > bet thousands, as a self signed certificate is a valid way of encrypting > the traffic. http://www.startssl.com/ Their certs are free and, from what I hear, are accepted by Google. -- John From alter3d at alter3d.ca Fri Dec 14 15:52:35 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Fri, 14 Dec 2012 10:52:35 -0500 Subject: Gmail and SSL In-Reply-To: <50CB49F7.5050304@afxr.net> References: <50CB49F7.5050304@afxr.net> Message-ID: <50CB4B43.10803@alter3d.ca> On 12/14/2012 10:47 AM, Randy wrote: > I don't have hundreds of dollars to get my ssl certificates signed You can get single-host certificates issued for free from StartSSL, or for very cheaply (under $10) from low-cost providers like CheapSSL.com. I've never had a problem having my StartSSL certs verified by anyone. - Pete From tim at pelican.org Fri Dec 14 16:21:23 2012 From: tim at pelican.org (Tim Franklin) Date: Fri, 14 Dec 2012 16:21:23 -0000 (GMT) Subject: Gmail and SSL In-Reply-To: <20121214105130.68c6003e@godzilla> Message-ID: <696bd4d3-aab0-4550-89d8-5e98944db7e5@mail.pelican.org> > http://www.startssl.com/ > > Their certs are free and, from what I hear, are accepted by Google. Seconded. I was a hold-out for a long time on personal stuff - I trust me, I'm not paying someone else to trust me - but StartSSL makes a lot of the pain go away with minimal effort. Regards, Tim. From max at mxcrypt.com Fri Dec 14 16:33:12 2012 From: max at mxcrypt.com (Maxim Khitrov) Date: Fri, 14 Dec 2012 11:33:12 -0500 Subject: Gmail and SSL In-Reply-To: <50CB4B43.10803@alter3d.ca> References: <50CB49F7.5050304@afxr.net> <50CB4B43.10803@alter3d.ca> Message-ID: On Fri, Dec 14, 2012 at 10:52 AM, Peter Kristolaitis wrote: > On 12/14/2012 10:47 AM, Randy wrote: >> >> I don't have hundreds of dollars to get my ssl certificates signed > > > You can get single-host certificates issued for free from StartSSL, or for > very cheaply (under $10) from low-cost providers like CheapSSL.com. I've > never had a problem having my StartSSL certs verified by anyone. This doesn't solve the problem if you have your own internal PKI or want to use a certificate that is valid for more than a year. StartSSL is a good option, but not everyone will be able to switch for a variety of reasons. Google should provide a way of uploading trusted root CAs (including self-signed certs) if they want to perform strict validation. - Max From morrowc.lists at gmail.com Fri Dec 14 16:36:08 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 14 Dec 2012 11:36:08 -0500 Subject: Gmail and SSL In-Reply-To: <696bd4d3-aab0-4550-89d8-5e98944db7e5@mail.pelican.org> References: <20121214105130.68c6003e@godzilla> <696bd4d3-aab0-4550-89d8-5e98944db7e5@mail.pelican.org> Message-ID: On Fri, Dec 14, 2012 at 11:21 AM, Tim Franklin wrote: >> http://www.startssl.com/ >> >> Their certs are free and, from what I hear, are accepted by Google. > > Seconded. I was a hold-out for a long time on personal stuff - I trust me, I'm not paying someone else to trust me - but StartSSL makes a lot of the pain go away with minimal effort. > because paying for random numbers is craziness. From nick at foobar.org Fri Dec 14 16:42:46 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 14 Dec 2012 16:42:46 +0000 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: <50CA5CB1.8010306@umd.edu> References: <50CA5CB1.8010306@umd.edu> Message-ID: <50CB5706.3090308@foobar.org> On 13/12/2012 22:54, Jason Castonguay wrote: > Advisory ? D-root is changing its IPv4 address on the 3rd of January. Jason, You've just given 3 weeks notice for a component change in one of the few critical part of the Internet's infrastructure, at a time when most networks have entered a configuration freeze (which will usually finish at the end of 2013 week one or week two), and where two of those weeks are holiday / slack periods in large parts of the world where many people won't be working. In addition, there is no further announcement notices on www.root-servers.org, d.root-servers.net, www.iana.org or www.icann.org. You are absolutely kidding, right? Can I politely ask you / UMD to please reconsider the timing and publicisation of this change because it has important operational consequences for the entire globe. If you decide reconsider this change, could you please: - change the date to give the world several months warning. - change the date something which doesn't conflict with any of the major ethnic world holidays - create notification pages on www.root-servers.org, d.root-servers.net, www.iana.org or www.icann.org - announce more widely across e.g. other global NOG mailing lists, RIR mailing lists, etc Nick From mcn4 at leicester.ac.uk Fri Dec 14 16:52:40 2012 From: mcn4 at leicester.ac.uk (Matthew Newton) Date: Fri, 14 Dec 2012 16:52:40 +0000 Subject: Advisory =?utf-8?B?4oCUIEQtcm9v?= =?utf-8?Q?t?= is changing its IPv4 address on the 3rd of January. In-Reply-To: <50CB5706.3090308@foobar.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> Message-ID: <20121214165240.GA15550@rootmail.cc.le.ac.uk> On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote: > On 13/12/2012 22:54, Jason Castonguay wrote: > > Advisory ? D-root is changing its IPv4 address on the 3rd of January. > > You've just given 3 weeks notice for a component change in one of the few > critical part of the Internet's infrastructure, at a time when most I think that /was/ the advance notification - you've got 6 months :) "The old address will continue to work for at least six months after the transition, but will ultimately be retired from service." Cheers, Matthew -- Matthew Newton, Ph.D. Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, From eyeronic.design at gmail.com Fri Dec 14 16:58:45 2012 From: eyeronic.design at gmail.com (Mike Hale) Date: Fri, 14 Dec 2012 08:58:45 -0800 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D=2Droot_is_changing_its_IPv4_address?= =?windows-1252?Q?_on_the_3rd_of_January=2E?= In-Reply-To: <20121214165240.GA15550@rootmail.cc.le.ac.uk> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <20121214165240.GA15550@rootmail.cc.le.ac.uk> Message-ID: Also, this appears to be par for the course for the last two IP Address changes on root-servers.net. That's why they keep the old address online for at least six months after the official change. On Fri, Dec 14, 2012 at 8:52 AM, Matthew Newton wrote: > On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote: > > On 13/12/2012 22:54, Jason Castonguay wrote: > > > Advisory ? D-root is changing its IPv4 address on the 3rd of January. > > > > You've just given 3 weeks notice for a component change in one of the few > > critical part of the Internet's infrastructure, at a time when most > > I think that /was/ the advance notification - you've got 6 months :) > > "The old address will continue to work for at least six months > after the transition, but will ultimately be retired from > service." > > Cheers, > > Matthew > > > -- > Matthew Newton, Ph.D. > > Systems Architect (UNIX and Networks), Network Services, > I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom > > For IT help contact helpdesk extn. 2253, > > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From mike at mtcc.com Fri Dec 14 16:59:19 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 14 Dec 2012 08:59:19 -0800 Subject: Advisory =?UTF-8?B?4oCUIEQtcm9vdCBpcyBjaGFuZ2luZyBpdHMgSVB2NA==?= =?UTF-8?B?IGFkZHJlc3Mgb24gdGhlIDNyZCBvZiBKYW51YXJ5Lg==?= In-Reply-To: <20121214165240.GA15550@rootmail.cc.le.ac.uk> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <20121214165240.GA15550@rootmail.cc.le.ac.uk> Message-ID: <50CB5AE7.8070709@mtcc.com> Matthew Newton wrote: > On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote: >> On 13/12/2012 22:54, Jason Castonguay wrote: >>> Advisory ? D-root is changing its IPv4 address on the 3rd of January. >> You've just given 3 weeks notice for a component change in one of the few >> critical part of the Internet's infrastructure, at a time when most > > I think that /was/ the advance notification - you've got 6 months :) > > "The old address will continue to work for at least six months > after the transition, but will ultimately be retired from > service." So really stupid question, and hopefully it's just me, do I need to do something on my servers? Second question: I know that renumbering is important in the abstract, but is there really an overwhelming reason why renumbering the root servers is critical? Shouldn't they all be in PI space for starters? Mike From eugen at leitl.org Fri Dec 14 17:04:39 2012 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 14 Dec 2012 18:04:39 +0100 Subject: Gmail and SSL In-Reply-To: References: <20121214105130.68c6003e@godzilla> <696bd4d3-aab0-4550-89d8-5e98944db7e5@mail.pelican.org> Message-ID: <20121214170439.GF9750@leitl.org> On Fri, Dec 14, 2012 at 11:36:08AM -0500, Christopher Morrow wrote: > > Seconded. I was a hold-out for a long time on personal stuff - I trust me, I'm not paying someone else to trust me - but StartSSL makes a lot of the pain go away with minimal effort. > > > > because paying for random numbers is craziness. Of course, the same logic applies to IP addresses >;> From recourse at gmail.com Fri Dec 14 17:09:08 2012 From: recourse at gmail.com (Joseph Jackson) Date: Fri, 14 Dec 2012 11:09:08 -0600 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D=2Droot_is_changing_its_IPv4_address?= =?windows-1252?Q?_on_the_3rd_of_January=2E?= In-Reply-To: <50CB5AE7.8070709@mtcc.com> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <20121214165240.GA15550@rootmail.cc.le.ac.uk> <50CB5AE7.8070709@mtcc.com> Message-ID: Mike, You will need to update your root.hints file on any of your forwarding DNS servers. Most OS vendors will include an update but its a good idea to manually check. On Fri, Dec 14, 2012 at 10:59 AM, Michael Thomas wrote: > Matthew Newton wrote: > >> On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote: >> >>> On 13/12/2012 22:54, Jason Castonguay wrote: >>> >>>> Advisory ? D-root is changing its IPv4 address on the 3rd of January. >>>> >>> You've just given 3 weeks notice for a component change in one of the few >>> critical part of the Internet's infrastructure, at a time when most >>> >> >> I think that /was/ the advance notification - you've got 6 months :) >> >> "The old address will continue to work for at least six months >> after the transition, but will ultimately be retired from >> service." >> > > So really stupid question, and hopefully it's just me, do I need to do > something > on my servers? > > Second question: I know that renumbering is important in the abstract, but > is there > really an overwhelming reason why renumbering the root servers is > critical? Shouldn't > they all be in PI space for starters? > > Mike > > From morrowc.lists at gmail.com Fri Dec 14 17:09:35 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 14 Dec 2012 12:09:35 -0500 Subject: Gmail and SSL In-Reply-To: <20121214170439.GF9750@leitl.org> References: <20121214105130.68c6003e@godzilla> <696bd4d3-aab0-4550-89d8-5e98944db7e5@mail.pelican.org> <20121214170439.GF9750@leitl.org> Message-ID: On Fri, Dec 14, 2012 at 12:04 PM, Eugen Leitl wrote: > On Fri, Dec 14, 2012 at 11:36:08AM -0500, Christopher Morrow wrote: > >> > Seconded. I was a hold-out for a long time on personal stuff - I trust me, I'm not paying someone else to trust me - but StartSSL makes a lot of the pain go away with minimal effort. >> > >> >> because paying for random numbers is craziness. > > Of course, the same logic applies to IP addresses >;> see odd tunderwood's presentation on using random numbers for ip addressing, without registry support for same. From morrowc.lists at gmail.com Fri Dec 14 17:11:50 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 14 Dec 2012 12:11:50 -0500 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D=2Droot_is_changing_its_IPv4_address?= =?windows-1252?Q?_on_the_3rd_of_January=2E?= In-Reply-To: <50CB5AE7.8070709@mtcc.com> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <20121214165240.GA15550@rootmail.cc.le.ac.uk> <50CB5AE7.8070709@mtcc.com> Message-ID: On Fri, Dec 14, 2012 at 11:59 AM, Michael Thomas wrote: > Matthew Newton wrote: >> >> On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote: >>> >>> On 13/12/2012 22:54, Jason Castonguay wrote: >>>> >>>> Advisory ? D-root is changing its IPv4 address on the 3rd of January. >>> >>> You've just given 3 weeks notice for a component change in one of the few >>> critical part of the Internet's infrastructure, at a time when most >> >> >> I think that /was/ the advance notification - you've got 6 months :) >> >> "The old address will continue to work for at least six months >> after the transition, but will ultimately be retired from >> service." > > > So really stupid question, and hopefully it's just me, do I need to do > something > on my servers? your crontab that updates your root-hints may already have caught the change... > Second question: I know that renumbering is important in the abstract, but > is there > really an overwhelming reason why renumbering the root servers is critical? > Shouldn't > they all be in PI space for starters? > ;; ANSWER SECTION: d.root-servers.net. 604800 IN A 128.8.10.90 128.8.0.0/16 - legacy space... > Mike > From walter.keen at rainierconnect.net Fri Dec 14 17:12:00 2012 From: walter.keen at rainierconnect.net (Walter Keen) Date: Fri, 14 Dec 2012 09:12:00 -0800 (PST) Subject: =?utf-8?Q?Re:_Advisory_=E2=80=94_D-root_is_changing_it?= =?utf-8?Q?s_IPv4_address_on_the_3rd_of_January.?= In-Reply-To: <50CB5AE7.8070709@mtcc.com> Message-ID: <125203102.6465009.1355505120487.JavaMail.root@zimbra01.rainierconnect.net> If I had to guess, I would guess that renumbering is likely required to get it into a more portable address assignment from a multi-homing perspective. Look at the whois information below If I were hosting a root server or something similar, I would certainly want it segregated enough that I could manage multi-homing for that address prefix outside of my other networks. In this case, I'd assume UMDNET-1 may have monetary or administrative policies regarding the ability to be multi-homed and the degree to which it can be, however providing multiple links to UMD-ROOTD-NET is likely much easier because those decisions (or cost of connections) don't necessarily need to affect UMDNET-1 NetRange: 128.8.0.0 - 128.8.255.255 CIDR: 128.8.0.0/16 OriginAS: AS27 NetName: UMDNET-1 NetHandle: NET-128-8-0-0-1 Parent: NET-128-0-0-0-0 NetType: Direct Assignment RegDate: 1984-08-01 Updated: 2011-05-03 Ref: http://whois.arin.net/rest/net/NET-128-8-0-0-1 NetRange: 199.7.91.0 - 199.7.91.255 CIDR: 199.7.91.0/24 OriginAS: AS6059, AS27, AS10886 NetName: UMD-ROOTD-NET NetHandle: NET-199-7-91-0-1 Parent: NET-199-0-0-0-0 NetType: Direct Assignment RegDate: 2007-12-07 Updated: 2012-03-20 Ref: http://whois.arin.net/rest/net/NET-199-7-91-0-1 ----- Original Message ----- From: "Michael Thomas" To: "Matthew Newton" Cc: nanog at nanog.org Sent: Friday, December 14, 2012 8:59:19 AM Subject: Re: Advisory ? D-root is changing its IPv4 address on the 3rd of January. Matthew Newton wrote: > On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote: >> On 13/12/2012 22:54, Jason Castonguay wrote: >>> Advisory ? D-root is changing its IPv4 address on the 3rd of January. >> You've just given 3 weeks notice for a component change in one of the few >> critical part of the Internet's infrastructure, at a time when most > > I think that /was/ the advance notification - you've got 6 months :) > > "The old address will continue to work for at least six months > after the transition, but will ultimately be retired from > service." So really stupid question, and hopefully it's just me, do I need to do something on my servers? Second question: I know that renumbering is important in the abstract, but is there really an overwhelming reason why renumbering the root servers is critical? Shouldn't they all be in PI space for starters? Mike From bmanning at vacation.karoshi.com Fri Dec 14 17:12:00 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 14 Dec 2012 17:12:00 +0000 Subject: Advisory =?utf-8?B?4oCUIEQtcm9v?= =?utf-8?Q?t?= is changing its IPv4 address on the 3rd of January. In-Reply-To: <50CB5AE7.8070709@mtcc.com> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <20121214165240.GA15550@rootmail.cc.le.ac.uk> <50CB5AE7.8070709@mtcc.com> Message-ID: <20121214171200.GA3414@vacation.karoshi.com.> On Fri, Dec 14, 2012 at 08:59:19AM -0800, Michael Thomas wrote: > Matthew Newton wrote: > >On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote: > >>On 13/12/2012 22:54, Jason Castonguay wrote: > >>>Advisory > >>You've just given 3 weeks notice for a component change in one of the few > >>critical part of the Internet's infrastructure, at a time when most > > > >I think that /was/ the advance notification - you've got 6 months :) > > > > "The old address will continue to work for at least six months > > after the transition, but will ultimately be retired from > > service." > > So really stupid question, and hopefully it's just me, do I need to do > something > on my servers? > > Second question: I know that renumbering is important in the abstract, but > is there > really an overwhelming reason why renumbering the root servers is critical? > Shouldn't > they all be in PI space for starters? > > Mike you might want to pick up the new belt/suspenders file aka root.hints, named.ca, et.al. and install it on your servers in the course of the next two years. if you can't reach D, then you should be able to reach the other 12. i beleive that D has not changed its IP address since before the RIR system came into existance and therefore had no idea what "PI" space means. Some of this stuff is really old/stable and making changes to foundational/stable systems is fraught with peril. Being careful is just being prudent. Perhaps of real interest to the NANOG community is the ability to "see" this prefix in their routing tables. /bill From woody at pch.net Fri Dec 14 17:13:39 2012 From: woody at pch.net (Bill Woodcock) Date: Fri, 14 Dec 2012 09:13:39 -0800 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: <50CB5AE7.8070709@mtcc.com> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <20121214165240.GA15550@rootmail.cc.le.ac.uk> <50CB5AE7.8070709@mtcc.com> Message-ID: On Dec 14, 2012, at 8:59 AM, Michael Thomas wrote: > Matthew Newton wrote: > So really stupid question, and hopefully it's just me, do I need to do something > on my servers? Update the hints file. /var/named/ somewhere in all likelihood. > Second question: I know that renumbering is important in the abstract, but is there > really an overwhelming reason why renumbering the root servers is critical? Shouldn't > they all be in PI space for starters? Starters was a _long_ time ago, and the person who did it shouldn't be disturbed. -Bill From jabley at hopcount.ca Fri Dec 14 17:13:49 2012 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 14 Dec 2012 12:13:49 -0500 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: <50CB5AE7.8070709@mtcc.com> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <20121214165240.GA15550@rootmail.cc.le.ac.uk> <50CB5AE7.8070709@mtcc.com> Message-ID: <57D7B905-F0CD-4A09-8F67-626CD8AA8E13@hopcount.ca> Hi Michael, On 2012-12-14, at 11:59, Michael Thomas wrote: > Matthew Newton wrote: >> On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote: >>> On 13/12/2012 22:54, Jason Castonguay wrote: >>>> Advisory ? D-root is changing its IPv4 address on the 3rd of January. >>> You've just given 3 weeks notice for a component change in one of the few >>> critical part of the Internet's infrastructure, at a time when most >> I think that /was/ the advance notification - you've got 6 months :) >> "The old address will continue to work for at least six months >> after the transition, but will ultimately be retired from >> service." > > So really stupid question, and hopefully it's just me, do I need to do something > on my servers? When nameservers first boot, all they have is a hints file. This is either baked in to the software, or provided as a "hints file", or some combination. The hints file you have today will have the current/outgoing D-Root address. The first thing a resolver does before it is ready for service, again, armed only with the hints file, is to send a priming query to a root server. This query is of the form ". IN NS?". Resolvers will try servers from the hints file until they get a response. Once the priming response is received, the data originally harvested from the hints file can be thrown away. Once D-Root renumbers, a freshly booted resolver with an old hints file will either: - send a priming query to one of A, B, C, E, F, G, H, I, J, K, L, M, and obtain a response that contains the new D-Root address - send a priming query to the old D-Root v4 address, and also obtain a response that contains the new D-Root address Once service is discontinued on the current/outgoing D-Root address, such a resolver might fail to obtain a response to its priming query if it happens to try the D/v4 address first. It will re-try with a different address until it succeeds. In principle, you only need one reachable address in the hints file to work to get up and running. In summary, theory (and practice) tells us that: 1. You should update your hints file from time to time, and 2. If you don't, chances are overwhelmingly good that it will make no difference, and everything will work as normal. Joe From nick at foobar.org Fri Dec 14 17:18:31 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 14 Dec 2012 17:18:31 +0000 Subject: Advisory =?UTF-8?B?4oCUIEQtcm9vdCBpcyBjaGFuZ2luZyBpdHMgSVB2NA==?= =?UTF-8?B?IGFkZHJlc3Mgb24gdGhlIDNyZCBvZiBKYW51YXJ5Lg==?= In-Reply-To: <20121214165240.GA15550@rootmail.cc.le.ac.uk> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <20121214165240.GA15550@rootmail.cc.le.ac.uk> Message-ID: <50CB5F67.5040108@foobar.org> On 14/12/2012 16:52, Matthew Newton wrote: > "The old address will continue to work for at least six months > after the transition, but will ultimately be retired from > service." I'm suggesting a lot more notification than 6 months before 128.8.10.90 is switched off. And corroborative announcements backed up from authoritative sources, not just a single email to nanog. It turns out that the Internet extends far beyond the borders of continental north america, and this change affects everyone who runs a resolver server. It would be really good to have a formal public statement of intent from UMD about their long term plans for 128.8.10.90 after retirement so that we don't have a repeat of the L root hijacking debacle in 2008. Everyone is extremely appreciative of the work that UMD has done in hosting this service since 1987. However, hosting a root server is a pretty big responsibility which includes maintenance of not just the existing addresses, but also all historical addresses to ensure that people who hit them after retirement (whether now or 20 years down the line) are not served bogus data. Nick From jabley at hopcount.ca Fri Dec 14 17:45:00 2012 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 14 Dec 2012 12:45:00 -0500 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: <50CB5706.3090308@foobar.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> Message-ID: <6C01E67E-0299-485F-8269-23B9BE3793AD@hopcount.ca> On 2012-12-14, at 11:42, Nick Hilliard wrote: > You've just given 3 weeks notice for a component change in one of the few > critical part of the Internet's infrastructure, at a time when most > networks have entered a configuration freeze (which will usually finish at > the end of 2013 week one or week two), and where two of those weeks are > holiday / slack periods in large parts of the world where many people won't > be working. To be clear: - there is no configuration change necessary in the next 3 weeks for resolvers - there is no configuration change necessary in the next 6 months for resolvers - even after 6 months, chances are resolvers which are not reconfigured will continue to work as normal > You are absolutely kidding, right? These changes have happened before (other root servers have renumbered). I have never heard of an operational problem caused by such an exercise, and I guarantee there are resolvers running happily today with hints files that are *ancient*. > Can I politely ask you / UMD to please reconsider the timing and > publicisation of this change because it has important operational > consequences for the entire globe. I think the trailing clause in your message above is over-stated. In fact, there are near zero operational consequences. Joe From bmanning at vacation.karoshi.com Fri Dec 14 17:54:10 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 14 Dec 2012 17:54:10 +0000 Subject: Advisory =?utf-8?B?4oCUIEQtcm9v?= =?utf-8?Q?t?= is changing its IPv4 address on the 3rd of January. In-Reply-To: <6C01E67E-0299-485F-8269-23B9BE3793AD@hopcount.ca> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <6C01E67E-0299-485F-8269-23B9BE3793AD@hopcount.ca> Message-ID: <20121214175410.GB3414@vacation.karoshi.com.> On Fri, Dec 14, 2012 at 12:45:00PM -0500, Joe Abley wrote: > > These changes have happened before (other root servers have renumbered). I have never heard of an operational problem caused by such an exercise, and I guarantee there are resolvers running happily today with hints files that are *ancient*. > > Joe i had one, back last century, when B renumbered. the old address of B was the last working address in the bootstrap file from 1986. :) i'm fairly confident that 99.9999% of all the existant bootstrap files on the Internet today contain at least 9 working IP addresses for root nameservers. That said, its -very- important to ensure (at each ISP, worldwide) that you have reachability to the new prefix. (wrt notification, I'm persuaded its valid and that the notice will be sent to many more groups as the hours/days progress ... remember, its not a flash change) /bill From jra at baylink.com Fri Dec 14 17:56:55 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 14 Dec 2012 12:56:55 -0500 (EST) Subject: =?utf-8?Q?Re:_Advisory_=E2=80=94_D-root_is_changing_it?= =?utf-8?Q?s_IPv4_address_on_the_3rd_of_January.?= In-Reply-To: <50CB5F67.5040108@foobar.org> Message-ID: <32936126.38747.1355507815632.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Nick Hilliard" > It would be really good to have a formal public statement of intent from > UMD about their long term plans for 128.8.10.90 after retirement so that we > don't have a repeat of the L root hijacking debacle in 2008. Quite so: UMD: Where will the old IP route after the 6 month period is complete? Somewhere safe? In point of fact, ISTM that there *is no way* to make this completely safe; granted that it's a low percentage attack, and thus probably not useful to actual attackers, but the possibility exists that someone could hijack that block at a provider level, and provide their own replacement for that old server IP. But of course, they can do it *now*, too, so I guess it doesn't matter anymore. 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 msa at latt.net Fri Dec 14 17:56:23 2012 From: msa at latt.net (Majdi S. Abbas) Date: Fri, 14 Dec 2012 12:56:23 -0500 Subject: Advisory =?utf-8?B?4oCUIEQtcm9v?= =?utf-8?Q?t?= is changing its IPv4 address on the 3rd of January. In-Reply-To: <50CB5706.3090308@foobar.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> Message-ID: <20121214175623.GA23718@puck.nether.net> On Fri, Dec 14, 2012 at 04:42:46PM +0000, Nick Hilliard wrote: > Jason, > > You've just given 3 weeks notice for a component change in one of the few > critical part of the Internet's infrastructure, at a time when most > networks have entered a configuration freeze (which will usually finish at > the end of 2013 week one or week two), and where two of those weeks are > holiday / slack periods in large parts of the world where many people won't > be working. Nick, I feel compelled to point out that the new service address is available now, and the old one will be available for another six months. Feel free to wait until after the holidays to make your changes. Cheers, --msa From jgreco at ns.sol.net Fri Dec 14 18:06:09 2012 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 14 Dec 2012 12:06:09 -0600 (CST) Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D=2Droot_is_changing_its_IPv4_address?= In-Reply-To: Message-ID: <201212141806.qBEI6A1t080693@aurora.sol.net> > > So really stupid question, and hopefully it's just me, do I need to do > > something > > on my servers? > > your crontab that updates your root-hints may already have caught the chang= > e... That seems like a spectacularly bad idea. How do you validate the new root-hints automatically? What if someone manages to send you something malicious in place of the correct one? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From antkojm1 at gmail.com Fri Dec 14 18:17:24 2012 From: antkojm1 at gmail.com (Joe Antkowiak) Date: Fri, 14 Dec 2012 12:17:24 -0600 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D=2Droot_is_changing_its_IPv4_address?= =?windows-1252?Q?_on_the_3rd_of_January=2E?= In-Reply-To: <32936126.38747.1355507815632.JavaMail.root@benjamin.baylink.com> References: <50CB5F67.5040108@foobar.org> <32936126.38747.1355507815632.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, Dec 14, 2012 at 11:56 AM, Jay Ashworth wrote: > Quite so: UMD: Where will the old IP route after the 6 month period is > complete? Somewhere safe? > > In point of fact, ISTM that there *is no way* to make this completely safe; > granted that it's a low percentage attack, and thus probably not useful > to actual attackers, but the possibility exists that someone could hijack > that block at a provider level, and provide their own replacement for that > old server IP. > This is an extremely good point... Where will the former addresses be going after this? I'm sure someone's thought about that though...I hope. From morrowc.lists at gmail.com Fri Dec 14 18:23:41 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 14 Dec 2012 13:23:41 -0500 Subject: =?windows-1252?Q?Re=3A_Re=3A_Advisory_=97_D=2Droot_is_changing_its_IPv4_add?= =?windows-1252?Q?ress?= In-Reply-To: <201212141806.qBEI6A1t080693@aurora.sol.net> References: <201212141806.qBEI6A1t080693@aurora.sol.net> Message-ID: dnssec On Dec 14, 2012 1:06 PM, "Joe Greco" wrote: > > > So really stupid question, and hopefully it's just me, do I need to do > > > something > > > on my servers? > > > > your crontab that updates your root-hints may already have caught the > chang= > > e... > > That seems like a spectacularly bad idea. How do you validate the new > root-hints automatically? What if someone manages to send you something > malicious in place of the correct one? > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] > then I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > From nick at foobar.org Fri Dec 14 18:37:31 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 14 Dec 2012 18:37:31 +0000 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: References: <50CB5F67.5040108@foobar.org> <32936126.38747.1355507815632.JavaMail.root@benjamin.baylink.com> Message-ID: <50CB71EB.4010003@foobar.org> On 14/12/2012 18:17, Joe Antkowiak wrote: > I'm sure someone's thought about that though...I hope. I've no doubt they have, but let's put it out on display. Nick From cscora at apnic.net Fri Dec 14 18:54:29 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 Dec 2012 04:54:29 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201212141854.qBEIsTIX023666@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 15 Dec, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 437576 Prefixes after maximum aggregation: 180670 Deaggregation factor: 2.42 Unique aggregates announced to Internet: 214733 Total ASes present in the Internet Routing Table: 42833 Prefixes per ASN: 10.22 Origin-only ASes present in the Internet Routing Table: 33929 Origin ASes announcing only one prefix: 15857 Transit ASes present in the Internet Routing Table: 5694 Transit-only ASes present in the Internet Routing Table: 135 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 31 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 1188 Unregistered ASNs in the Routing Table: 426 Number of 32-bit ASNs allocated by the RIRs: 3579 Number of 32-bit ASNs visible in the Routing Table: 3210 Prefixes from 32-bit ASNs in the Routing Table: 8662 Special use prefixes present in the Routing Table: 15 Prefixes being announced from unallocated address space: 150 Number of addresses announced to Internet: 2619294732 Equivalent to 156 /8s, 31 /16s and 68 /24s Percentage of available address space announced: 70.7 Percentage of allocated address space announced: 70.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.0 Total number of prefixes smaller than registry allocations: 154967 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 104923 Total APNIC prefixes after maximum aggregation: 32629 APNIC Deaggregation factor: 3.22 Prefixes being announced from the APNIC address blocks: 105840 Unique aggregates announced from the APNIC address blocks: 43291 APNIC Region origin ASes present in the Internet Routing Table: 4800 APNIC Prefixes per ASN: 22.05 APNIC Region origin ASes announcing only one prefix: 1245 APNIC Region transit ASes present in the Internet Routing Table: 796 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: 386 Number of APNIC addresses announced to Internet: 716073472 Equivalent to 42 /8s, 174 /16s and 106 /24s Percentage of available APNIC address space announced: 83.7 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: 156038 Total ARIN prefixes after maximum aggregation: 78497 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 156749 Unique aggregates announced from the ARIN address blocks: 70462 ARIN Region origin ASes present in the Internet Routing Table: 15339 ARIN Prefixes per ASN: 10.22 ARIN Region origin ASes announcing only one prefix: 5794 ARIN Region transit ASes present in the Internet Routing Table: 1592 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 18 Number of ARIN addresses announced to Internet: 1089133184 Equivalent to 64 /8s, 234 /16s and 218 /24s Percentage of available ARIN address space announced: 57.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 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: 112707 Total RIPE prefixes after maximum aggregation: 58169 RIPE Deaggregation factor: 1.94 Prefixes being announced from the RIPE address blocks: 115585 Unique aggregates announced from the RIPE address blocks: 74144 RIPE Region origin ASes present in the Internet Routing Table: 16988 RIPE Prefixes per ASN: 6.80 RIPE Region origin ASes announcing only one prefix: 8127 RIPE Region transit ASes present in the Internet Routing Table: 2763 Average RIPE Region AS path length visible: 5.1 Max RIPE Region AS path length visible: 31 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2078 Number of RIPE addresses announced to Internet: 650196324 Equivalent to 38 /8s, 193 /16s and 53 /24s Percentage of available RIPE address space announced: 94.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: 45280 Total LACNIC prefixes after maximum aggregation: 8984 LACNIC Deaggregation factor: 5.04 Prefixes being announced from the LACNIC address blocks: 48812 Unique aggregates announced from the LACNIC address blocks: 23091 LACNIC Region origin ASes present in the Internet Routing Table: 1746 LACNIC Prefixes per ASN: 27.96 LACNIC Region origin ASes announcing only one prefix: 505 LACNIC Region transit ASes present in the Internet Routing Table: 327 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 24 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 722 Number of LACNIC addresses announced to Internet: 120667944 Equivalent to 7 /8s, 49 /16s and 63 /24s Percentage of available LACNIC address space announced: 71.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 9844 Total AfriNIC prefixes after maximum aggregation: 2338 AfriNIC Deaggregation factor: 4.21 Prefixes being announced from the AfriNIC address blocks: 10440 Unique aggregates announced from the AfriNIC address blocks: 3614 AfriNIC Region origin ASes present in the Internet Routing Table: 584 AfriNIC Prefixes per ASN: 17.88 AfriNIC Region origin ASes announcing only one prefix: 186 AfriNIC Region transit ASes present in the Internet Routing Table: 127 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 6 Number of AfriNIC addresses announced to Internet: 42905600 Equivalent to 2 /8s, 142 /16s and 176 /24s Percentage of available AfriNIC address space announced: 42.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2933 11556 905 Korea Telecom (KIX) 17974 2431 826 46 PT TELEKOMUNIKASI INDONESIA 7545 1815 301 90 TPG Internet Pty Ltd 4755 1654 381 171 TATA Communications formerly 9829 1415 1156 42 BSNL National Internet Backbo 9583 1183 88 501 Sify Limited 7552 1138 1062 11 Vietel Corporation 4808 1128 2056 318 CNCGROUP IP network: China169 24560 1035 385 165 Bharti Airtel Ltd., Telemedia 9498 1030 307 69 BHARTI Airtel Ltd. 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 7029 3193 994 216 Windstream Communications Inc 6389 3129 3718 139 bellsouth.net, inc. 18566 2082 382 180 Covad Communications 22773 1944 2932 131 Cox Communications, Inc. 1785 1938 678 124 PaeTec Communications, Inc. 20115 1687 1607 623 Charter Communications 4323 1591 1153 395 Time Warner Telecom 30036 1381 291 721 Mediacom Communications Corp 7018 1290 10533 854 AT&T WorldNet Services 7011 1206 321 685 Citizens Utilities 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 1765 544 16 Corbina telecom 2118 1424 97 15 EUnet/RELCOM Autonomous Syste 34984 877 211 228 BILISIM TELEKOM 12479 868 777 64 Uni2 Autonomous System 13188 756 95 129 Educational Network 31148 741 38 13 FreeNet ISP 6830 715 2313 436 UPC Distribution Services 20940 712 229 549 Akamai Technologies European 58113 633 70 378 LIR DATACENTER TELECOM SRL 8551 611 367 39 Bezeq International 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 10620 2264 386 207 TVCABLE BOGOTA 28573 2213 1298 69 NET Servicos de Comunicao S.A 7303 1673 1139 201 Telecom Argentina Stet-France 8151 1599 3016 352 UniNet S.A. de C.V. 6503 1537 435 67 AVANTEL, S.A. 27947 761 85 93 Telconet S.A 3816 661 309 71 Empresa Nacional de Telecomun 18881 608 716 18 Global Village Telecom 11172 603 85 68 Servicios Alestra S.A de C.V 7738 579 1178 33 Telecomunicacoes da Bahia 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 24863 873 275 36 LINKdotNET AS number 36998 772 48 3 MOBITEL 8452 684 958 13 TEDATA 6713 485 602 20 Itissalat Al-MAGHRIB 24835 291 80 8 RAYA Telecom - Egypt 3741 267 906 225 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 181 697 88 MTN Network Solutions 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 7029 3193 994 216 Windstream Communications Inc 6389 3129 3718 139 bellsouth.net, inc. 4766 2933 11556 905 Korea Telecom (KIX) 17974 2431 826 46 PT TELEKOMUNIKASI INDONESIA 10620 2264 386 207 TVCABLE BOGOTA 28573 2213 1298 69 NET Servicos de Comunicao S.A 18566 2082 382 180 Covad Communications 22773 1944 2932 131 Cox Communications, Inc. 1785 1938 678 124 PaeTec Communications, Inc. 7545 1815 301 90 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3129 2990 bellsouth.net, inc. 17974 2431 2385 PT TELEKOMUNIKASI INDONESIA 28573 2213 2144 NET Servicos de Comunicao S.A 10620 2264 2057 TVCABLE BOGOTA 4766 2933 2028 Korea Telecom (KIX) 18566 2082 1902 Covad Communications 1785 1938 1814 PaeTec Communications, Inc. 22773 1944 1813 Cox Communications, Inc. 8402 1765 1749 Corbina telecom 7545 1815 1725 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 61309 UNALLOCATED 5.1.96.0/21 41562 Host4all Sarl 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 59530 UNALLOCATED 5.8.182.0/24 31261 GARS Telecom 61408 UNALLOCATED 5.56.0.0/21 174 Cogent Communication 61395 UNALLOCATED 5.83.56.0/22 3292 TDC Tele Danmark 61395 UNALLOCATED 5.83.60.0/22 3292 TDC Tele Danmark 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 3549 Global Crossing 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 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.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.112.114.0/24 23884 Proimage Engineering and Comm 41.222.80.0/21 37110 Moztel LDA 41.223.108.0/22 36966 >>UNKNOWN<< 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.66.32.0/20 18864 >>UNKNOWN<< 64.187.208.0/24 174 Cogent Communications 64.187.209.0/24 23005 Power Pulse 65.111.1.0/24 32258 SDN Global 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:18 /9:13 /10:29 /11:87 /12:244 /13:477 /14:857 /15:1544 /16:12483 /17:6562 /18:10967 /19:21593 /20:30927 /21:32879 /22:44170 /23:40758 /24:229702 /25:1349 /26:1744 /27:868 /28:182 /29:80 /30:17 /31:0 /32:26 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2622 3193 Windstream Communications Inc 18566 2032 2082 Covad Communications 6389 1776 3129 bellsouth.net, inc. 8402 1493 1765 Corbina telecom 30036 1288 1381 Mediacom Communications Corp 22773 1276 1944 Cox Communications, Inc. 11492 1147 1183 Cable One 6503 1055 1537 AVANTEL, S.A. 1785 1022 1938 PaeTec Communications, Inc. 7011 954 1206 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:650 2:715 3:3 4:13 5:687 6:3 8:487 12:1940 13:3 14:701 15:11 16:3 17:6 20:27 23:221 24:1795 27:1435 31:1321 32:54 33:2 34:2 36:7 37:1091 38:844 39:2 40:141 41:2768 42:179 44:3 46:1714 47:3 49:513 50:627 52:12 54:28 55:8 57:28 58:1069 59:553 60:236 61:1307 62:1039 63:2021 64:4370 65:2207 66:4498 67:2081 68:1187 69:3338 70:933 71:557 72:1894 74:2632 75:471 76:290 77:1032 78:1005 79:518 80:1208 81:977 82:633 83:535 84:531 85:1155 86:459 87:960 88:352 89:1741 90:304 91:5362 92:602 93:1664 94:2002 95:1639 96:487 97:322 98:969 99:40 100:31 101:288 103:1922 105:517 106:117 107:202 108:508 109:1699 110:821 111:972 112:461 113:746 114:642 115:901 116:888 117:777 118:965 119:1255 120:376 121:679 122:1723 123:1173 124:1322 125:1291 128:551 129:200 130:300 131:641 132:319 133:142 134:255 135:62 136:215 137:234 138:343 139:167 140:181 141:301 142:510 143:355 144:493 145:89 146:521 147:294 148:738 149:331 150:153 151:237 152:399 153:187 154:22 155:441 156:229 157:380 158:257 159:677 160:335 161:419 162:377 163:193 164:584 165:450 166:475 167:567 168:993 169:131 170:1006 171:164 172:6 173:1704 174:626 175:443 176:870 177:1484 178:1743 180:1351 181:185 182:1123 183:301 184:632 185:125 186:2107 187:1465 188:1893 189:1606 190:6154 192:6094 193:5819 194:4653 195:3656 196:1244 197:284 198:3998 199:5157 200:6014 201:2030 202:8839 203:8731 204:4477 205:2572 206:2780 207:2825 208:4072 209:3661 210:2897 211:1528 212:2101 213:1871 214:888 215:74 216:5176 217:1606 218:596 219:320 220:1257 221:542 222:336 223:365 End of report From jabley at hopcount.ca Fri Dec 14 19:02:31 2012 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 14 Dec 2012 14:02:31 -0500 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: References: <50CB5F67.5040108@foobar.org> <32936126.38747.1355507815632.JavaMail.root@benjamin.baylink.com> Message-ID: <80E95C9C-C9FA-4229-BE12-99BB2953F94C@hopcount.ca> On 2012-12-14, at 13:17, Joe Antkowiak wrote: > On Fri, Dec 14, 2012 at 11:56 AM, Jay Ashworth wrote: > >> Quite so: UMD: Where will the old IP route after the 6 month period is >> complete? Somewhere safe? >> >> In point of fact, ISTM that there *is no way* to make this completely safe; >> granted that it's a low percentage attack, and thus probably not useful >> to actual attackers, but the possibility exists that someone could hijack >> that block at a provider level, and provide their own replacement for that >> old server IP. >> > > This is an extremely good point... Where will the former addresses be > going after this? As I understand it (but ask UMD!) - D-Root is currently numbered out of a general-purpose UMD /16 into a dedicated, specifically-assigned /24 - the UMD /16 is not going anywhere The announcement is that D-Root is being renumbered, not that UMD is renumbering its whole network. Other root servers have renumbered out of institutional, general-purpose networks into dedicated networks in the past. I think the last one was B-Root in 2004, from an address within 128.9.0.0/16 to an address within 192.228.79.0/24 (see ). > I'm sure someone's thought about that though...I hope. Joe From jfmezei_nanog at vaxination.ca Fri Dec 14 19:03:42 2012 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 14 Dec 2012 14:03:42 -0500 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: <57D7B905-F0CD-4A09-8F67-626CD8AA8E13@hopcount.ca> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <20121214165240.GA15550@rootmail.cc.le.ac.uk> <50CB5AE7.8070709@mtcc.com> <57D7B905-F0CD-4A09-8F67-626CD8AA8E13@hopcount.ca> Message-ID: <50CB780E.2000803@vaxination.ca> On 12-12-14 12:13, Joe Abley wrote: > In summary, theory (and practice) tells us that: > > 1. You should update your hints file from time to time, and > 2. If you don't, chances are overwhelmingly good that it will make no difference, and everything will work as normal. But this is important to those who write DNS server software to ensure they embed the most up to date version of the root servers in their binaries. There are also a number of much older systems which no longer get software updates (such as VAX-VMS) so it is good practice to manually maintain the root.hints files so that over time, you don't accumulate more than a couple of disused root server IP addresses. From jra at baylink.com Fri Dec 14 19:25:43 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 14 Dec 2012 14:25:43 -0500 (EST) Subject: =?utf-8?Q?Re:_Advisory_=E2=80=94_D-root_is_changing_it?= =?utf-8?Q?s_IPv4_address_on_the_3rd_of_January.?= In-Reply-To: <80E95C9C-C9FA-4229-BE12-99BB2953F94C@hopcount.ca> Message-ID: <667257.38749.1355513143346.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joe Abley" > >> Quite so: UMD: Where will the old IP route after the 6 month period > >> is complete? Somewhere safe? > As I understand it (but ask UMD!) > > - D-Root is currently numbered out of a general-purpose UMD /16 into a > dedicated, specifically-assigned /24 > - the UMD /16 is not going anywhere > > The announcement is that D-Root is being renumbered, not that UMD is > renumbering its whole network. So, in short, UMD will still own the losing allocation, and be able to make relatively sure nothing else is placed at that IP (though of course they won't necessarily be able to make sure no one hijacks that entire prefix -- does Renesys have a pay-special-attention list?) 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 jeroen at mompl.net Fri Dec 14 19:32:17 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 14 Dec 2012 11:32:17 -0800 Subject: "Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications".... In-Reply-To: References: <50AB49EA.3030101@cis.vutbr.cz> <20121120163214.794af87b@tux.DEF.witbe.net> <50B18BF5.1090203@bogus.com> <7B2C3091-763E-4C03-86E7-DE38694482A0@arbor.net> <3D7CBEFA-1294-4AF7-8013-B29684DB5991@arbor.net> <50B35C4B.7090602@gmail.com> <95501E75-A1EF-48F2-8AA1-972BE6B94E90@delong.com> <45BC0F26-506F-4D43-9A28-2F3623EA9779@arbor.net> <50B512B6.1010701@mtcc.com> <50B52B74.4070606@unfix.org> Message-ID: <50CB7EC1.2090601@mompl.net> On 11/27/2012 01:26 PM, david raistrick wrote: > On Tue, 27 Nov 2012, Jeroen Massar wrote: > >> As for actually getting IPv6 at home or at work, there are so many ways >> to get that, thus not having it is a completely ridiculous excuse. > > bull. explain using a tunnel broker to anyone who isn't a network engineer. Old threat, I know... I am not calling myself a network "engineer" but I got the that ipv6 tunnelling working very well, from corporate offices spanning 3 continents to my own virtual servers and humble home DSL. The only thing it requires is to not be intellectually challenged and have a desire to get it working. Then you can do it in a couple of hours. Excellent read: http://madduck.net/docs/ipv6/ Greetings, Jeroen -- Earthquake Magnitude: 5.1 Date: Friday, December 14, 2012 17:46:45 UTC Location: New Ireland region, Papua New Guinea Latitude: -5.2589; Longitude: 153.4126 Depth: 36.70 km From bmanning at vacation.karoshi.com Fri Dec 14 19:38:03 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 14 Dec 2012 19:38:03 +0000 Subject: Advisory =?utf-8?B?4oCUIEQtcm9v?= =?utf-8?Q?t?= is changing its IPv4 address on the 3rd of January. In-Reply-To: <667257.38749.1355513143346.JavaMail.root@benjamin.baylink.com> References: <80E95C9C-C9FA-4229-BE12-99BB2953F94C@hopcount.ca> <667257.38749.1355513143346.JavaMail.root@benjamin.baylink.com> Message-ID: <20121214193803.GC3414@vacation.karoshi.com.> On Fri, Dec 14, 2012 at 02:25:43PM -0500, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Joe Abley" > > > >> Quite so: UMD: Where will the old IP route after the 6 month period > > >> is complete? Somewhere safe? > > > As I understand it (but ask UMD!) > > > > - D-Root is currently numbered out of a general-purpose UMD /16 into a > > dedicated, specifically-assigned /24 > > - the UMD /16 is not going anywhere > > > > The announcement is that D-Root is being renumbered, not that UMD is > > renumbering its whole network. > > So, in short, UMD will still own the losing allocation, and be able to make > relatively sure nothing else is placed at that IP (though of course they > won't necessarily be able to make sure no one hijacks that entire prefix -- > does Renesys have a pay-special-attention list?) > > Cheers, > -- jra But how do you know the Renesys allocations haven't been hijacked?? /bill From randy at psg.com Fri Dec 14 19:41:48 2012 From: randy at psg.com (Randy Bush) Date: Fri, 14 Dec 2012 11:41:48 -0800 Subject: btw, the itu imploded Message-ID: From jra at baylink.com Fri Dec 14 19:46:49 2012 From: jra at baylink.com (Jay Ashworth) Date: Fri, 14 Dec 2012 14:46:49 -0500 (EST) Subject: =?utf-8?Q?Re:_Advisory_=E2=80=94_D-root_is_changing_it?= =?utf-8?Q?s_IPv4_address_on_the_3rd_of_January.?= In-Reply-To: <20121214193803.GC3414@vacation.karoshi.com.> Message-ID: <17005711.38755.1355514409227.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: bmanning at vacation.karoshi.com > > So, in short, UMD will still own the losing allocation, and be able > > to make > > relatively sure nothing else is placed at that IP (though of course > > they > > won't necessarily be able to make sure no one hijacks that entire > > prefix -- > > does Renesys have a pay-special-attention list?) > > But how do you know the Renesys allocations haven't been hijacked?? I know you're being a smartass, Bill, but you're right: I assume Renesys has made provisions for that, but I don't know what they are. No doubt they'll pop in and post a link to a blog post they wrote 5 years ago which explains. ;-) 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 bmanning at vacation.karoshi.com Fri Dec 14 19:47:40 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 14 Dec 2012 19:47:40 +0000 Subject: btw, the itu imploded - NOT In-Reply-To: References: Message-ID: <20121214194740.GD3414@vacation.karoshi.com.> not at all... the WCIT 2012 concluded without agreement. Hardly the same thing. /bill From wbailey at satelliteintelligencegroup.com Fri Dec 14 19:49:49 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Fri, 14 Dec 2012 19:49:49 +0000 Subject: btw, the itu imploded In-Reply-To: References: Message-ID: ....? Again? ;) >From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Randy Bush Date: 12/14/2012 11:44 AM (GMT-08:00) To: North American Network Operators' Group Subject: btw, the itu imploded From mikea at mikea.ath.cx Fri Dec 14 19:51:37 2012 From: mikea at mikea.ath.cx (Mike A) Date: Fri, 14 Dec 2012 13:51:37 -0600 Subject: btw, the itu imploded In-Reply-To: References: Message-ID: <20121214195137.GA83702@mikea.ath.cx> On Fri, Dec 14, 2012 at 11:41:48AM -0800, Randy Bush wrote: ---end quoted text--- Yep. _Gloriously_! The US walked out, followed by bunchty others. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From castongj at umd.edu Fri Dec 14 20:13:43 2012 From: castongj at umd.edu (Jason Castonguay) Date: Fri, 14 Dec 2012 15:13:43 -0500 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: <50CB5706.3090308@foobar.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> Message-ID: <50CB8877.80605@umd.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/14/12 11:42, Nick Hilliard wrote: > On 13/12/2012 22:54, Jason Castonguay wrote: >> Advisory ? D-root is changing its IPv4 address on the 3rd of >> January. > > Jason, > > > You've just given 3 weeks notice for a component change in one of > the few critical part of the Internet's infrastructure, at a time > when most networks have entered a configuration freeze (which will > usually finish at the end of 2013 week one or week two), and where > two of those weeks are holiday / slack periods in large parts of > the world where many people won't be working. > > In addition, there is no further announcement notices on > www.root-servers.org, d.root-servers.net, www.iana.org or > www.icann.org. > > You are absolutely kidding, right? > Hi Nick, and Nanog, I've given 3 weeks + 6 months (at least) notice on a service change that will not be noticed by most anyone. Its a change to the HINTS file, which is only used on bootstrapping. So anyone who does not update it will connect to any of the other 12 root-servers, and receive the updated IP from then on. If you have not updated your HINTS file since 1987 you may have issues bootstrapping, but you are good from 89/09/18 on. Additionally, we will be actively monitoring usage after the 6 month period to determine when best to terminate the service on the old IP. The old address, which is in the middle of UMD's network, is going to be black-holed once the change is over. Nothing will be on that IP once we move the root off. The rest of UMD's network is staying put. This move is part of UMD's commitment to improve the service, so we can support DNS anycast. Additional notice to other listservs and on web pages is coming soon. Thanks, - -- Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDLiHcACgkQA5NiLuECHn7U0wCgrNA/kNTNT65yHPG9uVgUxn9m khkAoNu/kKkcTVVsFbgd7IlIHkvrDLdD =+DnX -----END PGP SIGNATURE----- From bmanning at vacation.karoshi.com Fri Dec 14 20:01:27 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 14 Dec 2012 20:01:27 +0000 Subject: Advisory =?utf-8?B?4oCUIEQtcm9v?= =?utf-8?Q?t?= is changing its IPv4 address on the 3rd of January. In-Reply-To: <17005711.38755.1355514409227.JavaMail.root@benjamin.baylink.com> References: <20121214193803.GC3414@vacation.karoshi.com.> <17005711.38755.1355514409227.JavaMail.root@benjamin.baylink.com> Message-ID: <20121214200127.GE3414@vacation.karoshi.com.> On Fri, Dec 14, 2012 at 02:46:49PM -0500, Jay Ashworth wrote: > ----- Original Message ----- > > From: bmanning at vacation.karoshi.com > > > > So, in short, UMD will still own the losing allocation, and be able > > > to make > > > relatively sure nothing else is placed at that IP (though of course > > > they > > > won't necessarily be able to make sure no one hijacks that entire > > > prefix -- > > > does Renesys have a pay-special-attention list?) > > > > But how do you know the Renesys allocations haven't been hijacked?? > > I know you're being a smartass, Bill, but you're right: I assume Renesys > has made provisions for that, but I don't know what they are. > > No doubt they'll pop in and post a link to a blog post they wrote 5 years > ago which explains. ;-) > > Cheers, > -- jra the smart-ass answer to the nagging question on prefix reuse is: "Top Men are working on it" A more reasoned (maybe) response might be: To my knowledge, there is tension between creating "golden" addresses and address flexablity/reuse. I'd really like to swing back toward address flexability/reuse, but there is a whole lot of inertia behind the "golden" address crowd. Of the six renumbering events that come to mind, four of the prefixes are sequestered. The two that are not were in net 10. I am unaware of -anyone- who still points at the old addresses in net 10 space. I think there were other renumbering events, but have not kept track of the old prefix use. /bill From woody at pch.net Fri Dec 14 20:04:04 2012 From: woody at pch.net (Bill Woodcock) Date: Fri, 14 Dec 2012 12:04:04 -0800 Subject: btw, the itu imploded In-Reply-To: <20121214195137.GA83702@mikea.ath.cx> References: <20121214195137.GA83702@mikea.ath.cx> Message-ID: <375240A1-3D24-4563-AD1E-E324356AE371@pch.net> On Dec 14, 2012, at 11:51 AM, Mike A wrote: > > Yep. _Gloriously_! The US walked out, followed by bunchty others. > > At current count, to the best of my incomplete knowledge, approximately 85 countries, led by China, Saudi Arabia, Vietnam, and Cuba, have backed the ITU, while approximately 55 countries, led by the OECD countries, have backed the Internet. Yes, this is a radical simplification. The main unfortunate outcome is that the ITU has managed to get Study Group 3 approved to try to figure out how to override peering agreements with government-imposed settlements. Again, a radical simplification. Happy to discuss in more detail if people like. PP23 of http://files.wcitleaks.org/public/S12-WCIT12-C-0065!!MSW-E.pdf if you want to read it for yourself. -Bill From jfmezei_nanog at vaxination.ca Fri Dec 14 20:12:26 2012 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 14 Dec 2012 15:12:26 -0500 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: <50CB8877.80605@umd.edu> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> Message-ID: <50CB882A.30502@vaxination.ca> On 12-12-14 15:13, Jason Castonguay wrote: > I've given 3 weeks + 6 months (at least) notice on a service change that > will not be noticed by most anyone. Upon hearing your announcement, I went and dig myself a new root.hints file from one of the root servers. the "D" root is still pointing to the old address. So I had to go in and manually edit the root.hints file myself. I blame you for all that extra work :-) Would there be any impact to having the root servers immediatly provide the new IP for the D server so that a dig ns . @a.root-servers.net. > root.hints would yield the new updated file ? I realise that keeping the old IP functional for some time is important for all the static configurations. But does it matter if a dynamic list is updated "real time" without much advance warning ? From richard.barnes at gmail.com Fri Dec 14 20:19:52 2012 From: richard.barnes at gmail.com (Richard Barnes) Date: Fri, 14 Dec 2012 15:19:52 -0500 Subject: btw, the itu imploded In-Reply-To: References: Message-ID: See also: http://www.ipv.sx/wcit/ On Fri, Dec 14, 2012 at 2:41 PM, Randy Bush wrote: > > From job at instituut.net Fri Dec 14 20:28:21 2012 From: job at instituut.net (Job Snijders) Date: Fri, 14 Dec 2012 21:28:21 +0100 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: <50CB882A.30502@vaxination.ca> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> Message-ID: Hi Jean, On Dec 14, 2012, at 9:12 PM, Jean-Francois Mezei wrote: > On 12-12-14 15:13, Jason Castonguay wrote: > >> I've given 3 weeks + 6 months (at least) notice on a service change that >> will not be noticed by most anyone. > > Upon hearing your announcement, I went and dig myself a new root.hints > file from one of the root servers. the "D" root is still pointing to the > old address. So I had to go in and manually edit the root.hints file > myself. I blame you for all that extra work :-) derp derp > Would there be any impact to having the root servers immediatly provide > the new IP for the D server so that a > dig ns . @a.root-servers.net. > root.hints would yield the new updated > file ? As far as I understand, after 3 January 2013 such a dig command would create a new updated file with the new IP address. Kind regards, Job From nick at foobar.org Fri Dec 14 20:32:02 2012 From: nick at foobar.org (Nick Hilliard) Date: Fri, 14 Dec 2012 20:32:02 +0000 Subject: btw, the itu imploded In-Reply-To: <20121214195137.GA83702@mikea.ath.cx> References: <20121214195137.GA83702@mikea.ath.cx> Message-ID: <50CB8CC2.2050700@foobar.org> On 14/12/2012 19:51, Mike A wrote: > Yep. _Gloriously_! The US walked out, followed by bunchty others. > > The ITU didn't implode and that article gives a ridiculously misleading impression of what happened. The BBC gives a more balanced viewpoint: http://www.bbc.co.uk/news/technology-20717774 There's some stuff up on some US news channels (ABC, etc), but some of the larger players (CNN, NY Times + others) haven't actually woken up to the extent of this tech/political landgrab, and have no recent articles on the outcome or the political importance of it. What actually happened is that the ITU ignored their previous promises not to have a vote on the ITRs. When a vote was finally called because it was apparently that there was no general consensus on the articles, 77 countries voted in favour and 33 voted against, causing the treaty to start the process of becoming legally binding in those countries which voted in favour. The current positions are here: http://files.wcitleaks.org/public/S12-WCIT12-C-0066!!MSW-E.pdf http://files.wcitleaks.org/public/S12-WCIT12-C-0067!!MSW-E.pdf Many countries are formally sitting on the fence, including pretty much every country in Europe which didn't walk out - also enjoy the spat in declarations #4 (argentina) and #93 (UK). Now that this landgrab has succeeded in large chunks of the world, the ITU's position has consolidated, although not nearly to the extent that had originally been envisaged in the draft ITRs. I don't forsee this debate dying any time soon. Nick From castongj at umd.edu Fri Dec 14 20:37:10 2012 From: castongj at umd.edu (Jason Castonguay) Date: Fri, 14 Dec 2012 15:37:10 -0500 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: <50CB882A.30502@vaxination.ca> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> Message-ID: <50CB8DF6.5050707@umd.edu> On 12/14/2012 03:12 PM, Jean-Francois Mezei wrote: > On 12-12-14 15:13, Jason Castonguay wrote: > >> I've given 3 weeks + 6 months (at least) notice on a service change that >> will not be noticed by most anyone. > Upon hearing your announcement, I went and dig myself a new root.hints > file from one of the root servers. the "D" root is still pointing to the > old address. So I had to go in and manually edit the root.hints file > myself. I blame you for all that extra work :-) > > Would there be any impact to having the root servers immediatly provide > the new IP for the D server so that a > dig ns . @a.root-servers.net. > root.hints would yield the new updated > file ? > > I realise that keeping the old IP functional for some time is important > for all the static configurations. But does it matter if a dynamic list > is updated "real time" without much advance warning ? > Hi Jean-Francois, On the 3rd you should be able to dig and see the new entry, like the dynamic list you have mentioned. Thanks, -- Jason From antkojm1 at gmail.com Fri Dec 14 21:10:44 2012 From: antkojm1 at gmail.com (Joe Antkowiak) Date: Fri, 14 Dec 2012 15:10:44 -0600 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D=2Droot_is_changing_its_IPv4_address?= =?windows-1252?Q?_on_the_3rd_of_January=2E?= In-Reply-To: <50CB8877.80605@umd.edu> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> Message-ID: On Fri, Dec 14, 2012 at 2:13 PM, Jason Castonguay wrote: > The old address, which is in the middle of UMD's network, is going to be > black-holed once the change is over. Nothing will be on that IP once we > move the root off. The rest of UMD's network is staying put. This move > is part of UMD's commitment to improve the service, so we can support > DNS anycast. > > Just a quick question....if the old block is going to be black-holed but kept allocated...why does it need to be changed in the first place, or why does the existing have to be disabled? (just have both addresses active/responding?) Forgive me if I'm missing something. From bmanning at vacation.karoshi.com Fri Dec 14 21:25:16 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 14 Dec 2012 21:25:16 +0000 Subject: Advisory =?utf-8?B?4oCUIEQtcm9v?= =?utf-8?Q?t?= is changing its IPv4 address on the 3rd of January. In-Reply-To: References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> Message-ID: <20121214212516.GA4396@vacation.karoshi.com.> On Fri, Dec 14, 2012 at 03:10:44PM -0600, Joe Antkowiak wrote: > On Fri, Dec 14, 2012 at 2:13 PM, Jason Castonguay wrote: > > > The old address, which is in the middle of UMD's network, is going to be > > black-holed once the change is over. Nothing will be on that IP once we > > move the root off. The rest of UMD's network is staying put. This move > > is part of UMD's commitment to improve the service, so we can support > > DNS anycast. > > > > > Just a quick question....if the old block is going to be black-holed but > kept allocated...why does it need to be changed in the first place, or why > does the existing have to be disabled? (just have both addresses > active/responding?) > > Forgive me if I'm missing something. because you would not accept a /30 cutout of the UMD /16 coming from some random IX in Singapore. (see Joe Ableys post earlier today on why legacy nodes are / have renumbered.) /bill From antkojm1 at gmail.com Fri Dec 14 21:33:47 2012 From: antkojm1 at gmail.com (Joe Antkowiak) Date: Fri, 14 Dec 2012 15:33:47 -0600 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D=2Droot_is_changing_its_IPv4_address?= =?windows-1252?Q?_on_the_3rd_of_January=2E?= In-Reply-To: <50cb9954.c2b12a0a.0db0.ffffa361SMTPIN_ADDED_BROKEN@mx.google.com> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50cb9954.c2b12a0a.0db0.ffffa361SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On Fri, Dec 14, 2012 at 3:25 PM, wrote: > > because you would not accept a /30 cutout of the UMD /16 coming > from some random IX in Singapore. (see Joe Ableys post earlier > today > on why legacy nodes are / have renumbered.) > > /bill > Agreed on the routing (although I wouldn't ever expect to see the subnet encompassing a root server IP advertised in the wild with..anything even close to 30 bits), and understood on the minimal/non-existant operational impacts. Guess I'm just being curious. From gordon.lennox.13 at gmail.com Fri Dec 14 21:34:21 2012 From: gordon.lennox.13 at gmail.com (Gordon Lennox) Date: Fri, 14 Dec 2012 22:34:21 +0100 Subject: btw, the itu imploded In-Reply-To: <50CB8CC2.2050700@foobar.org> References: <20121214195137.GA83702@mikea.ath.cx> <50CB8CC2.2050700@foobar.org> Message-ID: <91863A29-F5B0-4CC8-ADAB-6B0DF93C7F96@gmail.com> WCIT-12 was but one exchange. The next one is WTPF-13: "The World Telecommunication/Information and Communication Technology Policy Forum (WTPF) is a high-level international event to exchange views on the key policy issues arising from today's fast changing information and communication technology (ICT) environment. WTPF 2013 will take place in Geneva, Switzerland in May 2013." Then there is Plenipotentiary in Busan, Republic of Korea from 20 October to 7 November 2014. "The Plenipotentiary Conference is the key event at which ITU Member States decide on the future role of the organization, thereby determining the organization's ability to influence and affect the development of Information and Communication Technologies (ICTs) worldwide. The Plenipotentiary Conference is the top policy-making body of the ITU." The ITU is not going away that soon. The game goes on. Gordon From Matthew.Black at csulb.edu Fri Dec 14 21:45:58 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Fri, 14 Dec 2012 21:45:58 +0000 Subject: Gmail and SSL In-Reply-To: <50CB4B43.10803@alter3d.ca> References: <50CB49F7.5050304@afxr.net> <50CB4B43.10803@alter3d.ca> Message-ID: A major problem with free or low-cost certificates is that their intermediate CA certificate does not always point back to a root certificate in client machines and/or software. matthew black california state university, long beach -----Original Message----- From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] Sent: Friday, December 14, 2012 7:53 AM To: nanog at nanog.org Subject: Re: Gmail and SSL On 12/14/2012 10:47 AM, Randy wrote: > I don't have hundreds of dollars to get my ssl certificates signed You can get single-host certificates issued for free from StartSSL, or for very cheaply (under $10) from low-cost providers like CheapSSL.com. I've never had a problem having my StartSSL certs verified by anyone. - Pete From cidr-report at potaroo.net Fri Dec 14 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Dec 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201212142200.qBEM0050009363@wattle.apnic.net> This report has been generated at Fri Dec 14 21:13:09 2012 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 07-12-12 438154 251164 08-12-12 438993 251474 09-12-12 438633 251424 10-12-12 438626 251518 11-12-12 439046 251249 12-12-12 438968 251564 13-12-12 439358 252020 14-12-12 440081 251852 AS Summary 42957 Number of ASes in routing system 17873 Number of ASes announcing only one prefix 3192 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 115225824 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'). --- 14Dec12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 439914 251807 188107 42.8% All ASes AS6389 3128 143 2985 95.4% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2232 70 2162 96.9% NET Servicos de Comunicao S.A. AS4766 2933 923 2010 68.5% KIXS-AS-KR Korea Telecom AS17974 2431 570 1861 76.6% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 1944 137 1807 93.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS7029 3192 1457 1735 54.4% WINDSTREAM - Windstream Communications Inc AS18566 2082 423 1659 79.7% COVAD - Covad Communications Co. AS10620 2264 652 1612 71.2% Telmex Colombia S.A. AS2118 1424 51 1373 96.4% RELCOM-AS OOO "NPO Relcom" AS7303 1673 396 1277 76.3% Telecom Argentina S.A. AS4323 1596 401 1195 74.9% TWTC - tw telecom holdings, inc. AS4755 1653 526 1127 68.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS7552 1144 196 948 82.9% VIETEL-AS-AP Vietel Corporation AS8151 1607 692 915 56.9% Uninet S.A. de C.V. AS7545 1820 944 876 48.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 1017 170 847 83.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 1128 351 777 68.9% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS1785 1937 1162 775 40.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS13977 856 118 738 86.2% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS9808 739 29 710 96.1% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS855 716 53 663 92.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS24560 1035 407 628 60.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS17676 710 90 620 87.3% GIGAINFRA Softbank BB Corp. AS3356 1115 499 616 55.2% LEVEL3 Level 3 Communications AS3549 1057 441 616 58.3% GBLX Global Crossing Ltd. AS22561 1038 439 599 57.7% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 1000 405 595 59.5% VZGNI-TRANSIT - Verizon Online LLC AS18881 608 41 567 93.3% Global Village Telecom AS36998 772 213 559 72.4% SDN-MOBITEL AS22047 579 22 557 96.2% VTR BANDA ANCHA S.A. Total 45430 12021 33409 73.5% 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- 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.222.80.0/21 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 64.187.208.0/24 AS174 COGENT Cogent/PSI 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.171.32.0/20 AS705 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 68.234.0.0/19 AS40430 COLO4JAX-AS - colo4jax, LLC 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 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 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.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.217.250.0/24 AS43108 GARM-AS Garm Technologies Ltd. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 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.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 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.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 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.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 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 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 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 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.87.96.0/21 AS40638 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. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.21.160.0/20 AS27876 American Data Networks 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.194.160.0/20 AS27876 American Data Networks 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 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 Dec 14 22:00:01 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 Dec 2012 22:00:01 GMT Subject: BGP Update Report Message-ID: <201212142200.qBEM01hE009376@wattle.apnic.net> BGP Update Report Interval: 06-Dec-12 -to- 13-Dec-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 53057 2.1% 38.9 -- BSNL-NIB National Internet Backbone 2 - AS8402 46615 1.9% 22.9 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS3909 38398 1.6% 1129.4 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - AS29256 27247 1.1% 412.8 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 5 - AS7303 24350 1.0% 4.7 -- Telecom Argentina S.A. 6 - AS12768 23507 0.9% 242.3 -- ER-TELECOM-AS CJSC "ER-Telecom Holding" 7 - AS7029 19577 0.8% 6.6 -- WINDSTREAM - Windstream Communications Inc 8 - AS13188 18179 0.7% 31.2 -- BANKINFORM-AS TOV "Bank-Inform" 9 - AS28573 17709 0.7% 7.8 -- NET Servicos de Comunicao S.A. 10 - AS2708 15804 0.6% 113.7 -- Universidad de Guanajuato 11 - AS9583 13079 0.5% 10.6 -- SIFY-AS-IN Sify Limited 12 - AS29049 12828 0.5% 39.1 -- DELTA-TELECOM-AS Delta Telecom LTD. 13 - AS10620 12239 0.5% 5.8 -- Telmex Colombia S.A. 14 - AS4538 12056 0.5% 23.2 -- ERX-CERNET-BKB China Education and Research Network Center 15 - AS3816 12007 0.5% 18.1 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 16 - AS4755 10703 0.4% 6.5 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 17 - AS17974 10580 0.4% 4.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 18 - AS11664 10286 0.4% 33.9 -- Techtel LMDS Comunicaciones Interactivas S.A. 19 - AS14420 10038 0.4% 21.8 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 20 - AS58113 10022 0.4% 15.8 -- LIR-AS LIR DATACENTER TELECOM SRL TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS2033 8808 0.3% 8808.0 -- PANIX - Panix Network Information Center 2 - AS24057 8467 0.3% 8467.0 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 3 - AS33158 3136 0.1% 3136.0 -- DATA-SERVICES-INC - Data Services Incorporated 4 - AS6174 5731 0.2% 2865.5 -- SPRINTLINK8 - Sprint 5 - AS26799 5586 0.2% 2793.0 -- DKR - DKR CAPITAL 6 - AS41674 1842 0.1% 1842.0 -- ALVARION-AS Alvarion SRL 7 - AS14680 5021 0.2% 1673.7 -- REALE-6 - Auction.com 8 - AS4 1539 0.1% 333.0 -- COMUNICALO DE MEXICO S.A. DE C.V 9 - AS3909 38398 1.6% 1129.4 -- QWEST-AS-3908 - Qwest Communications Company, LLC 10 - AS6629 7337 0.3% 917.1 -- NOAA-AS - NOAA 11 - AS3 8199 0.3% 460.0 -- CMED-AS Cmed Technology Ltd 12 - AS57918 858 0.0% 858.0 -- ACOD-AS ACOD CJSC 13 - AS40946 1178 0.1% 589.0 -- PROCON - Sat Track 14 - AS32529 582 0.0% 582.0 -- CGI-FEDERAL-ASN-1 - CGI Federal 15 - AS17293 1957 0.1% 489.2 -- VTXC - VTX Communications 16 - AS45178 3847 0.1% 480.9 -- ROSHAN-AF Main Street, House No. 13 Wazir Akbar Khan 17 - AS57201 474 0.0% 474.0 -- EDF-AS Estonian Defence Forces 18 - AS30589 1320 0.1% 440.0 -- ACTIVEHOST-WASH-AVE - ActiveHost Corporation 19 - AS28667 6417 0.3% 427.8 -- Network Telecomunica??es LTDA 20 - AS473 427 0.0% 427.0 -- AFCONC-BLOCK1-AS - 754th Electronic Systems Group TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 151.118.254.0/24 12768 0.5% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - 151.118.255.0/24 12767 0.5% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.18.0/24 12720 0.5% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 209.48.168.0/24 8808 0.3% AS2033 -- PANIX - Panix Network Information Center 5 - 202.14.255.0/24 8467 0.3% AS24057 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 6 - 178.248.238.0/24 8151 0.3% AS3 -- CMED-AS Cmed Technology Ltd 7 - 192.58.232.0/24 7304 0.3% AS6629 -- NOAA-AS - NOAA 8 - 12.30.238.0/24 5584 0.2% AS26799 -- DKR - DKR CAPITAL 9 - 194.63.9.0/24 4446 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 10 - 12.139.133.0/24 4246 0.2% AS14680 -- REALE-6 - Auction.com 11 - 69.38.178.0/24 4187 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 12 - 206.80.78.0/24 3963 0.1% AS20340 -- APPIA-COMMUNICATIONS - ISPHONE, INC. 13 - 139.139.19.0/24 3691 0.1% AS1562 -- DNIC-ASBLK-01550-01601 - DoD Network Information Center 14 - 12.183.21.0/24 3136 0.1% AS33158 -- DATA-SERVICES-INC - Data Services Incorporated 15 - 208.16.110.0/24 2867 0.1% AS6174 -- SPRINTLINK8 - Sprint 16 - 206.105.75.0/24 2864 0.1% AS6174 -- SPRINTLINK8 - Sprint 17 - 115.170.128.0/17 2643 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange 18 - 5.0.32.0/19 2524 0.1% AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment 19 - 123.252.208.0/24 2491 0.1% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 20 - 178.253.102.0/24 2467 0.1% AS29256 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 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 alter3d at alter3d.ca Fri Dec 14 23:03:05 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Fri, 14 Dec 2012 18:03:05 -0500 Subject: Gmail and SSL In-Reply-To: References: <50CB49F7.5050304@afxr.net> <50CB4B43.10803@alter3d.ca> Message-ID: <50CBB029.6050107@alter3d.ca> I've heard this argument fairly often when I mention free/cheap certificates to colleagues, etc, but no one has ever actually pointed to a reasonable case where this is true ("the 20 year old VMS system that I've never patched running OpenSSL 0.0.0.0.1-pre-alpha doesn't work" doesn't count...). I tested my StartSSL certs against quite a number of clients and haven't found anything reasonably modern (say in the last 10 years) that didn't work either out of the box or by updating the root CA list from the OS vendor via the OS' standard patching mechanism In my experience, free/cheap certs "not working" on some clients is, in 99.9% of cases, a misconfiguration error where the server isn't presenting the cert chain properly (usually omitting the intermediate cert), which works on some platforms (often because they include the intermediate certs to work around these kinds of problems) but not on others. Fixing the cert chain that's presented to the client has ALWAYS resolved these types of issues in my experience. If you have specific example that you know breaks with a specific (free/cheap cert, client) pair, I'd love to know so I can test it (if possible, i.e. I can actually get my hands on the client device/software). - Pete On 12/14/2012 4:45 PM, Matthew Black wrote: > A major problem with free or low-cost certificates is that their intermediate CA certificate does not always point back to a root certificate in client machines and/or software. > > matthew black > california state university, long beach > > > > -----Original Message----- > From: Peter Kristolaitis [mailto:alter3d at alter3d.ca] > Sent: Friday, December 14, 2012 7:53 AM > To: nanog at nanog.org > Subject: Re: Gmail and SSL > > On 12/14/2012 10:47 AM, Randy wrote: >> I don't have hundreds of dollars to get my ssl certificates signed > You can get single-host certificates issued for free from StartSSL, or > for very cheaply (under $10) from low-cost providers like CheapSSL.com. > I've never had a problem having my StartSSL certs verified by anyone. > > - Pete > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4431 bytes Desc: S/MIME Cryptographic Signature URL: From morrowc.lists at gmail.com Sat Dec 15 03:54:54 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 14 Dec 2012 22:54:54 -0500 Subject: Gmail and SSL In-Reply-To: <50CBB029.6050107@alter3d.ca> References: <50CB49F7.5050304@afxr.net> <50CB4B43.10803@alter3d.ca> <50CBB029.6050107@alter3d.ca> Message-ID: On Fri, Dec 14, 2012 at 6:03 PM, Peter Kristolaitis wrote: > In my experience, free/cheap certs "not working" on some clients is, in > 99.9% of cases, a misconfiguration error where the server isn't presenting > the cert chain properly (usually omitting the intermediate cert), which > works on some platforms (often because they include the intermediate certs > to work around these kinds of problems) but not on others. Fixing the cert > chain that's presented to the client has ALWAYS resolved these types of > issues in my experience. and in the case of the original topic... if the gmail servers don't accept StartSSL certs, please let me know I'll see about a fix. From eric-list at truenet.com Sat Dec 15 04:11:17 2012 From: eric-list at truenet.com (eric-list at truenet.com) Date: Fri, 14 Dec 2012 23:11:17 -0500 Subject: OpenFlow, please don't start a flame war... Message-ID: <5e62eb07$4f5b9433$5635a55b$@truenet.com> It's been about 2 years in since I've heard about the concept, and honestly I'm about ready to jump into test environments at my house. My questions are pretty basic, what distro would you recommend for a controller, and should I start by virtualizing in VMWare or HyperV or jump into some cheap Linksys WRT routers. The more I hear about the tech from colleges, Google, BigSwitch, etc is leaning me to really start learning, so any help would appreciated. 24 Hagerty Boulevard, Unit 10, West Chester PA 19382P: 610-429-8200 | F: 610-429-3222 | E: sales at truenet.com From jeff-kell at utc.edu Sat Dec 15 04:44:48 2012 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 14 Dec 2012 23:44:48 -0500 Subject: OpenFlow, please don't start a flame war... In-Reply-To: <5e62eb07$4f5b9433$5635a55b$@truenet.com> References: <5e62eb07$4f5b9433$5635a55b$@truenet.com> Message-ID: <50CC0040.5060203@utc.edu> On 12/14/2012 11:11 PM, eric-list at truenet.com wrote: > It's been about 2 years in since I've heard about the concept, and honestly > I'm about ready to jump into test environments at my house. My questions > are pretty basic, what distro would you recommend for a controller, and > should I start by virtualizing in VMWare or HyperV or jump into some cheap > Linksys WRT routers. The more I hear about the tech from colleges, Google, > BigSwitch, etc is leaning me to really start learning, so any help would > appreciated. Yeah, it's the neatest thing since sliced bread, but requires layer-2 connectivity across the board. When you exhaust your mac address tables, we'll welcome you back to the real world. Jeff From drc at virtualized.org Sat Dec 15 04:48:07 2012 From: drc at virtualized.org (David Conrad) Date: Fri, 14 Dec 2012 20:48:07 -0800 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: <80E95C9C-C9FA-4229-BE12-99BB2953F94C@hopcount.ca> References: <50CB5F67.5040108@foobar.org> <32936126.38747.1355507815632.JavaMail.root@benjamin.baylink.com> <80E95C9C-C9FA-4229-BE12-99BB2953F94C@hopcount.ca> Message-ID: <364AE42C-D844-4543-8FC4-CD7EBD318DEC@virtualized.org> On Dec 14, 2012, at 11:02 AM, Joe Abley wrote: > Other root servers have renumbered out of institutional, general-purpose networks into dedicated networks in the past. I think the last one was B-Root in 2004, Actually, it was "L" in 2007... :) Regards, -drc From snoble at sonn.com Sat Dec 15 05:23:30 2012 From: snoble at sonn.com (Steve Noble) Date: Fri, 14 Dec 2012 21:23:30 -0800 Subject: OpenFlow, please don't start a flame war... In-Reply-To: <50CC0040.5060203@utc.edu> References: <5e62eb07$4f5b9433$5635a55b$@truenet.com> <50CC0040.5060203@utc.edu> Message-ID: On Dec 14, 2012 8:47 PM, "Jeff Kell" wrote: > > Yeah, it's the neatest thing since sliced bread, but requires layer-2 > connectivity across the board. When you exhaust your mac address > tables, we'll welcome you back to the real world. I think you are confusing vendor solutions with a protocol. For OpenFlow related learning and hands on I suggest the routeflow project. https://sites.google.com/site/routeflow/home From bmanning at vacation.karoshi.com Sat Dec 15 05:50:44 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 15 Dec 2012 05:50:44 +0000 Subject: Advisory =?utf-8?B?4oCUIEQtcm9v?= =?utf-8?Q?t?= is changing its IPv4 address on the 3rd of January. In-Reply-To: <364AE42C-D844-4543-8FC4-CD7EBD318DEC@virtualized.org> References: <50CB5F67.5040108@foobar.org> <32936126.38747.1355507815632.JavaMail.root@benjamin.baylink.com> <80E95C9C-C9FA-4229-BE12-99BB2953F94C@hopcount.ca> <364AE42C-D844-4543-8FC4-CD7EBD318DEC@virtualized.org> Message-ID: <20121215055044.GA4647@vacation.karoshi.com.> On Fri, Dec 14, 2012 at 08:48:07PM -0800, David Conrad wrote: > On Dec 14, 2012, at 11:02 AM, Joe Abley wrote: > > Other root servers have renumbered out of institutional, general-purpose networks into dedicated networks in the past. I think the last one was B-Root in 2004, > > Actually, it was "L" in 2007... :) > > Regards, > -drc SOME people have very long memories. /bill From joly at punkcast.com Sat Dec 15 10:28:42 2012 From: joly at punkcast.com (Joly MacFie) Date: Sat, 15 Dec 2012 05:28:42 -0500 Subject: =?windows-1252?Q?VIDEO=3A_Mitigating_DDoS_Attacks=3A_Best_Practices_for_a?= =?windows-1252?Q?n_Evolving_Threat_Landscape_=96_NYC_12=2F5_=23DDoS?= Message-ID: As promised this is the full video of PIR's recent DDoS event in NYC. I've waited to post it until we got the closed captioning done. If anyone should be willing to volunteer to help translate the captions into other languages they can do so via AMARA - http://www.universalsubtitles.org/en/videos/lvgGlpwZR0lA/info/mitigating-ddos-attacks-best-practices-for-an-evolving-threat-landscape/- it's possible to just contribute as much or as little as you have time to do. ** joly posted: "The Internet Society's New York Chapter (ISOC-NY) and the New York Technology Council (NYTECH) joined the Public Interest Registry (PIR) in presenting a midday symposium "Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape" in New Yor" [image: Mitigating DDoS Attacks 12/5/2012]The Internet Society's New York Chapter (ISOC-NY ) and the New York Technology Council (NYTECH ) joined the Public Interest Registry (PIR ) in presenting a midday symposium "Mitigating DDoS Attacks: Best Practices for an Evolving Threat Landscape " in New York City on December 5 2012. Participating organizations included Afilias, Google, Neustar, Symantec, EFF, and De Natris Consult. The event was webcast live via the Internet Society Chapters Livestream Channel. Audio / transcript links are below. English Closed captions are available. MODERATOR Brian Cute - CEO, Public Interest Registry (PIR) SPEAKERS Jeff Greene - Senior Policy Counsel, Symantec Ram Mohan - EVP & Chief Technology Officer, Afilias Damian Menscher -- Security Engineer, Google Miguel Ramos - Senior Product Manager, Neustar Danny McPherson - Chief Security Officer, Verisign Jillian York - Director for International Freedom of Expression, Electronic Frontier Foundation (EFF) - Download audio : http://isoc-ny.org/ddos/mitigating_ddos.mp3 - Download transcript: http://isoc-ny.org/ddos/mitigating_ddos.txt Comment See all comments *Trouble clicking?* Copy and paste this URL into your browser: http://isoc-ny.org/p2/4505 -- --------------------------------------------------------------- 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 sander at steffann.nl Sat Dec 15 13:49:15 2012 From: sander at steffann.nl (Sander Steffann) Date: Sat, 15 Dec 2012 14:49:15 +0100 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: <50CB8877.80605@umd.edu> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> Message-ID: <2170B230-3FED-436D-BF6F-C68E8173EBDB@steffann.nl> Hi, > Additionally, we will be actively monitoring usage after the 6 month > period to determine when best to terminate the service on the old IP. Good to hear that. > The old address, which is in the middle of UMD's network, is going to be > black-holed once the change is over. Nothing will be on that IP once we > move the root off. Thank you, very important to get that confirmed :-) > Additional notice to other listservs and on web pages is coming soon. Thanks! Sander From nanog at studio442.com.au Sat Dec 15 14:19:13 2012 From: nanog at studio442.com.au (Julien Goodwin) Date: Sun, 16 Dec 2012 01:19:13 +1100 Subject: Advisory =?UTF-8?B?4oCUIEQtcm9vdCBpcyBjaGFuZ2luZyBpdHMgSVB2NA==?= =?UTF-8?B?IGFkZHJlc3Mgb24gdGhlIDNyZCBvZiBKYW51YXJ5Lg==?= In-Reply-To: <50CB780E.2000803@vaxination.ca> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <20121214165240.GA15550@rootmail.cc.le.ac.uk> <50CB5AE7.8070709@mtcc.com> <57D7B905-F0CD-4A09-8F67-626CD8AA8E13@hopcount.ca> <50CB780E.2000803@vaxination.ca> Message-ID: <50CC86E1.8060503@studio442.com.au> On 15/12/12 06:03, Jean-Francois Mezei wrote: > There are also a number of much older systems which no longer get > software updates (such as VAX-VMS) so it is good practice to manually > maintain the root.hints files so that over time, you don't accumulate > more than a couple of disused root server IP addresses. Hosts like that should be using forwarders, not running their own recursive resolver. (And probably ported to Alpha at least in the VMS case, which is still "receiving updates" even if its been two and a half years since the last release) Outside of VAX-VMS or old Windows systems I doubt there's much out there that runs a recursive resolver that can't just have the current version of bind installed fairly easily. There's probably some appliance type systems, but the vast majority of those are so broken that an out of date hints file is the least of their worries. From jlk at thrashyour.com Sat Dec 15 15:20:57 2012 From: jlk at thrashyour.com (John Kinsella) Date: Sat, 15 Dec 2012 07:20:57 -0800 Subject: OpenFlow, please don't start a flame war... In-Reply-To: <5e62eb07$4f5b9433$5635a55b$@truenet.com> References: <5e62eb07$4f5b9433$5635a55b$@truenet.com> Message-ID: <1315261221926645056@unknownmsgid> I'm biased, but I'd say give cloudstack a try. Supports openflow, and fairly easy to spin up. http://www.slideshare.net/xen_com_mgr/under-the-hood-open-vswitch-openflow-in-xcp-xenserver John On Dec 14, 2012, at 8:13 PM, "eric-list at truenet.com" wrote: > It's been about 2 years in since I've heard about the concept, and honestly > I'm about ready to jump into test environments at my house. My questions > are pretty basic, what distro would you recommend for a controller, and > should I start by virtualizing in VMWare or HyperV or jump into some cheap > Linksys WRT routers. The more I hear about the tech from colleges, Google, > BigSwitch, etc is leaning me to really start learning, so any help would > appreciated. > > > 24 Hagerty Boulevard, Unit 10, West Chester PA 19382P: 610-429-8200 | F: 610-429-3222 | E: sales at truenet.com > > From davei at otd.com Sat Dec 15 16:56:23 2012 From: davei at otd.com (Dave Israel) Date: Sat, 15 Dec 2012 11:56:23 -0500 Subject: OpenFlow, please don't start a flame war... In-Reply-To: <5e62eb07$4f5b9433$5635a55b$@truenet.com> References: <5e62eb07$4f5b9433$5635a55b$@truenet.com> Message-ID: <50CCABB7.3030403@otd.com> On 12/14/2012 11:11 PM, eric-list at truenet.com wrote: > It's been about 2 years in since I've heard about the concept, and honestly > I'm about ready to jump into test environments at my house. My questions > are pretty basic, what distro would you recommend for a controller, and > should I start by virtualizing in VMWare or HyperV or jump into some cheap > Linksys WRT routers. The more I hear about the tech from colleges, Google, > BigSwitch, etc is leaning me to really start learning, so any help would > appreciated. OpenFlow is a big arena. Do you know what you want to do with it? If you're looking to write your own intelligence, I recommend the OpenFlow tutorial at http://www.openflow.org/wk/index.php/OpenFlow_Tutorial . It helps you get started in a virtual environment, and introduces you to a number of controller platforms. -Dave From marka at isc.org Sat Dec 15 21:58:46 2012 From: marka at isc.org (Mark Andrews) Date: Sun, 16 Dec 2012 08:58:46 +1100 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: Your message of "Fri, 14 Dec 2012 15:12:26 CDT." <50CB882A.30502@vaxination.ca> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> Message-ID: <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> In message <50CB882A.30502 at vaxination.ca>, Jean-Francois Mezei writes: > On 12-12-14 15:13, Jason Castonguay wrote: > > > I've given 3 weeks + 6 months (at least) notice on a service change that > > will not be noticed by most anyone. > > Upon hearing your announcement, I went and dig myself a new root.hints > file from one of the root servers. the "D" root is still pointing to the > old address. So I had to go in and manually edit the root.hints file > myself. I blame you for all that extra work :-) Yet you appear to have not read the announcement. :-) > Would there be any impact to having the root servers immediatly provide > the new IP for the D server so that a > dig ns . @a.root-servers.net. > root.hints would yield the new updated > file ? Then people would complain "You didn't give us any warning". This is a HEADSUP of an upcoming change. > I realise that keeping the old IP functional for some time is important > for all the static configurations. But does it matter if a dynamic list > is updated "real time" without much advance warning ? 3 weeks is not a lot of "advance warning". -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jared at puck.nether.net Sat Dec 15 22:13:22 2012 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 15 Dec 2012 17:13:22 -0500 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> Message-ID: <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> On Dec 15, 2012, at 4:58 PM, Mark Andrews wrote: >> I realise that keeping the old IP functional for some time is important >> for all the static configurations. But does it matter if a dynamic list >> is updated "real time" without much advance warning ? > > 3 weeks is not a lot of "advance warning". 3 weeks is plenty for a service that in 6 months you may see degraded to 12/13 capacity if you haven't properly maintained it AND it is used for recursive service. (trusting a referral from a root or sub-root delegation to the root is crazy!). I could only wish my automobile would notify me 6 months of its impending failure should I take no action... Oh, and you can just download the root zone from ftp://ftp.internic.net/domain/root.zone ... - Jared From drc at virtualized.org Sat Dec 15 22:25:12 2012 From: drc at virtualized.org (David Conrad) Date: Sat, 15 Dec 2012 14:25:12 -0800 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> Message-ID: <2AE310B3-0313-4D23-82E3-8E603060A432@virtualized.org> On Dec 15, 2012, at 2:13 PM, Jared Mauch wrote: > Oh, and you can just download the root zone from ftp://ftp.internic.net/domain/root.zone ... Or, perhaps more conveniently, zone transfer the root zone from xfr.lax.dns.icann.org or xfr.cjr.dns.icann.org (see http://dns.icann.org/services/axfr/). Regards, -drc From marka at isc.org Sat Dec 15 22:32:25 2012 From: marka at isc.org (Mark Andrews) Date: Sun, 16 Dec 2012 09:32:25 +1100 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: Your message of "Sat, 15 Dec 2012 17:13:22 CDT." <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> Message-ID: <20121215223225.8805A2D13E64@drugs.dv.isc.org> In message <42515678-F2CE-48CE-A0E6-4211C5F0F1A1 at puck.nether.net>, Jared Mauch writes: > > On Dec 15, 2012, at 4:58 PM, Mark Andrews wrote: > > >> I realise that keeping the old IP functional for some time is = > important > >> for all the static configurations. But does it matter if a dynamic = > list > >> is updated "real time" without much advance warning ? > >=20 > > 3 weeks is not a lot of "advance warning". > > 3 weeks is plenty for a service that in 6 months you may see degraded to = > 12/13 capacity if you haven't properly maintained it AND it is used for = > recursive service. (trusting a referral from a root or sub-root = > delegation to the root is crazy!). 3 weeks is not a lot of time to inform every recursive service operator in the world that there is a change coming. Remember nameservers will start logging warning messages as of January 3rd. There is a big difference between 'This is just fallout from D changing it's address' to 'What does this message mean and do I have to worry?' > I could only wish my automobile would notify me 6 months of its = > impending failure should I take no action... > > Oh, and you can just download the root zone from = > ftp://ftp.internic.net/domain/root.zone ... > > - Jared= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jfmezei_nanog at vaxination.ca Sat Dec 15 22:54:52 2012 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 15 Dec 2012 17:54:52 -0500 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: <20121215223225.8805A2D13E64@drugs.dv.isc.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> <20121215223225.8805A2D13E64@drugs.dv.isc.org> Message-ID: <50CCFFBC.5000207@vaxination.ca> On 12-12-15 17:32, Mark Andrews wrote: > 3 weeks is not a lot of time to inform every recursive service > operator in the world that there is a change coming. Remember > nameservers will start logging warning messages as of January 3rd. Nameservers will NOT log messages starting Jan 3rd. The old IP address will continue to work for 6 months after that. Tempest in a tea pot. Besides all this is moot since the simulation which runs our universe ends this friday (the 21st is the end of the world, remember ? :-) So you edit your root.hints file today, and schedule a rndc refresh before June 3rd when convenient. From drc at virtualized.org Sat Dec 15 23:07:18 2012 From: drc at virtualized.org (David Conrad) Date: Sat, 15 Dec 2012 15:07:18 -0800 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: <20121215223225.8805A2D13E64@drugs.dv.isc.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> <20121215223225.8805A2D13E64@drugs.dv.isc.org> Message-ID: <76ED8740-1958-43C1-9331-6C95C44FC89E@virtualized.org> On Dec 15, 2012, at 2:32 PM, Mark Andrews wrote: > 3 weeks is not a lot of time to inform every recursive service > operator in the world that there is a change coming. Given the impact of the change, I figure 3 weeks is plenty. > Remember nameservers will start logging warning messages as of January 3rd. And if they do, recursive service operators who haven't seen the message will (if they care) update their root hints. This seems to be exactly the right thing. I fail to see the concern here. > There is a big difference between 'This is just fallout from D > changing it's address' to 'What does this message mean and do I have > to worry?' Are BIND's warning messages so opaque that someone who is looking at name server log messages can't figure out that the warning is talking about a root server IP address being changed? The handwringing over this issue is a bit over the top. Regards, -drc From Bryan at bryanfields.net Sat Dec 15 23:21:17 2012 From: Bryan at bryanfields.net (Bryan Fields) Date: Sat, 15 Dec 2012 18:21:17 -0500 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: <76ED8740-1958-43C1-9331-6C95C44FC89E@virtualized.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> <20121215223225.8805A2D13E64@drugs.dv.isc.org> <76ED8740-1958-43C1-9331-6C95C44FC89E@virtualized.org> Message-ID: <50CD05ED.2020707@bryanfields.net> On 12/15/12 6:07 PM, David Conrad wrote: > Are BIND's warning messages so opaque that someone who is looking at name > server log messages can't figure out that the warning is talking about a > root server IP address being changed? What about the people that are running BIND 4 on an old Solaris 2.6 box, and the log file filled up at 2gb back in 2006? Also they forgot the root password, and no one has a boot disk. Won't somebody think of the boxen? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From marine64 at gmail.com Sat Dec 15 23:25:34 2012 From: marine64 at gmail.com (Brian Henson) Date: Sat, 15 Dec 2012 18:25:34 -0500 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D=2Droot_is_changing_its_IPv4_address?= =?windows-1252?Q?_on_the_3rd_of_January=2E?= In-Reply-To: <50CD05ED.2020707@bryanfields.net> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> <20121215223225.8805A2D13E64@drugs.dv.isc.org> <76ED8740-1958-43C1-9331-6C95C44FC89E@virtualized.org> <50CD05ED.2020707@bryanfields.net> Message-ID: Let us all have a moment of silence to remember all those poor unmanaged servers out there......Thank you now nuke them all and start over :) On Sat, Dec 15, 2012 at 6:21 PM, Bryan Fields wrote: > On 12/15/12 6:07 PM, David Conrad wrote: > > Are BIND's warning messages so opaque that someone who is looking at name > > server log messages can't figure out that the warning is talking about a > > root server IP address being changed? > > What about the people that are running BIND 4 on an old Solaris 2.6 box, > and > the log file filled up at 2gb back in 2006? Also they forgot the root > password, and no one has a boot disk. > > Won't somebody think of the boxen? > > -- > Bryan Fields > > 727-409-1194 - Voice > 727-214-2508 - Fax > http://bryanfields.net > > From nick at foobar.org Sun Dec 16 00:45:32 2012 From: nick at foobar.org (Nick Hilliard) Date: Sun, 16 Dec 2012 00:45:32 +0000 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: <76ED8740-1958-43C1-9331-6C95C44FC89E@virtualized.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> <20121215223225.8805A2D13E64@drugs.dv.isc.org> <76ED8740-1958-43C1-9331-6C95C44FC89E@virtualized.org> Message-ID: <50CD19AC.7060708@foobar.org> On 15/12/2012 23:07, David Conrad wrote: > The handwringing over this issue is a bit over the top. It's a question of what's procedurally sensible. Sensible things would include longer notice of the impending change to the root zone, more widespread notice of what's happening and generally not poking around with really important bits of the Internet at times which are well known for having configuration freezes and/or when many people are going to be on holidays. There are many bits of the internet where changes will only affect small areas, but this change will affect everyone even if they people don't realise it (and yes, it probably won't affect them visibly because of root cache repriming). Other sensible things might include: - liaising with operating system vendors and recurser servers code authors and providing them with extra advance notice so that they can roll these changes into their code in a structured way. Software update release cycles often take many months to roll out, particularly for non OSS code. - perhaps some targeted localisation of the d.root-servers.org notice so that more than 15% of the world population can read it (english == 5% native speakers, 10% second language)? Lots of people are aware that resolver dns servers will automatically reprime their root cache without manual intervention. However, not everyone will realise it and a random punter who looks at this notice and doesn't understand root cache mechanics may well think that they need to start updating their DNS configuration files on Jan 3. It's not clear from the change notification that you don't necessarily need to do this. This change wasn't planned over a coffee last thursday morning. It's obviously been on the cards for several years, so asking for more carefully structured notice in a procedurally sensible sort of way isn't an unreasonable thing to expect as part of the migration plan. Nick From jfmezei_nanog at vaxination.ca Sun Dec 16 01:11:55 2012 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 15 Dec 2012 20:11:55 -0500 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: <50CD19AC.7060708@foobar.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> <20121215223225.8805A2D13E64@drugs.dv.isc.org> <76ED8740-1958-43C1-9331-6C95C44FC89E@virtualized.org> <50CD19AC.7060708@foobar.org> Message-ID: <50CD1FDB.900@vaxination.ca> On 12-12-15 19:45, Nick Hilliard wrote: > widespread notice of what's happening and generally not poking around with > really important bits of the Internet at times which are well known for > having configuration freezes and/or when many people are going to be on > holidays. You have 6.75 months to implement this before the current IP address no longer works. Use idle time during holidays to plan when you will do this change if your configs are frozen during holidays. I did react with a sense of urgency when I first read the message, but once you re-read it, you realise the timing and advance notice are plenty sufficient. > Software update release > cycles often take many months to roll out, particularly for non OSS code. Those one support can get a patch from their vendor or simple instructions on how to edit their root.honts file to change an IP address it in (or use dig to get the new one). > This change wasn't planned over a coffee last thursday morning. It's > obviously been on the cards for several years, But probably can't make an announcement until everything has been approved. Also, if you annouce something that will happen 1 year from now, more people will just postpone the change and forgot about it. From damian at google.com Sun Dec 16 01:34:44 2012 From: damian at google.com (Damian Menscher) Date: Sat, 15 Dec 2012 17:34:44 -0800 Subject: Solutions for DoS & DDoS In-Reply-To: References: <0D89D80C-D288-402F-8723-B837EA52313C@gmail.com> Message-ID: On Fri, Dec 7, 2012 at 1:30 AM, Yuri Slobodyanyuk wrote: > - If speaking of web/email services - hosted solution is viable to some > degree (e..g Amazon AWS Cloudfront, Google Apps, CDNs etc) . IT is not a > DEDICATED hosted solution against DDOS, so be prepared for the provider to > shut down the client if the attack gets heavy enough > While Google's business isn't DDoS mitigation, we do see plenty of attacks on user content we host (Google Hosted Services backed by Blogger, App Engine, or other properties) and it's generally not a problem (thinking back over the past few years I can't remember ever terminating a victim). Happy to host more victims, as the attacks provide good (if unplanned) load tests. ;) Send me an email if you want to discuss special needs, and I'll let you know how we might be able to help. Damian From drc at virtualized.org Sun Dec 16 02:26:14 2012 From: drc at virtualized.org (David Conrad) Date: Sat, 15 Dec 2012 18:26:14 -0800 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: <50CD19AC.7060708@foobar.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> <20121215223225.8805A2D13E64@drugs.dv.isc.org> <76ED8740-1958-43C1-9331-6C95C44FC89E@virtualized.org> <50CD19AC.7060708@foobar.org> Message-ID: Nick, On Dec 15, 2012, at 4:45 PM, Nick Hilliard wrote: > On 15/12/2012 23:07, David Conrad wrote: >> The handwringing over this issue is a bit over the top. > It's a question of what's procedurally sensible. Sensible things would > include longer notice of the impending change to the root zone, Given reality and the way root priming works, 3 weeks notice and 6 months of continued service seems sensible to me. > more widespread notice of what's happening I gather recursive server implementations provide a warning message telling folks that the IP address has changed. That seems like a more useful notification methodology than sending email to a few (or even many) mailing lists. > and generally not poking around with > really important bits of the Internet at times which are well known for > having configuration freezes and/or when many people are going to be on > holidays. It simply doesn't matter if folks refuse to make a change during the holidays. The worst case scenario is they'll get a warning message in their recursive server log files. Presumably, the folks who look at those log files will be able to understand what it means. They have 6 months after the change occurs to update their root hints. Even if they don't, this particular change will only affect people 1/13th of the time their name servers reprime and will do so in a way that is wildly unlikely to even be noticed. > This change wasn't planned over a coffee last thursday morning. It's > obviously been on the cards for several years, so asking for more carefully > structured notice in a procedurally sensible sort of way isn't an > unreasonable thing to expect as part of the migration plan. You seem to be a bit confused about roles and prerogatives here. The UMD folks are making a change to _their_ infrastructure. They have sent out a notice in advance of that change to folks who might be interested. They were under absolutely no obligation to do so. There is no contractual or service level agreement between UMD and _anyone_ that requires them to do _anything_ with regards to root service. The fact that they gave 3 weeks notice that they were changing the IP addresses of their server shows they are nice folks. Neither you nor anyone else that uses "D" has any right to dictate how UMD operates their infrastructure, how much notice to give when making changes to that infrastructure, who gets notified, etc. Welcome to the wonderful wacky world of volunteer root service! With that said, I would argue it should be the responsibility of the maintainers of the root hints to notify software vendors, recursive operators, etc. of a change since the maintainer of the root hints file has vetted/implemented the change. It is also more likely that the world has at least heard of the maintainers of the root hints than some random person posting unsigned messages from a University (no offense Jason :-)). Regards, -drc From bmanning at vacation.karoshi.com Sun Dec 16 03:47:46 2012 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 16 Dec 2012 03:47:46 +0000 Subject: Advisory =?utf-8?B?4oCUIEQtcm9v?= =?utf-8?Q?t?= is changing its IPv4 address on the 3rd of January. In-Reply-To: <50CD19AC.7060708@foobar.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> <20121215223225.8805A2D13E64@drugs.dv.isc.org> <76ED8740-1958-43C1-9331-6C95C44FC89E@virtualized.org> <50CD19AC.7060708@foobar.org> Message-ID: <20121216034746.GA8998@vacation.karoshi.com.> On Sun, Dec 16, 2012 at 12:45:32AM +0000, Nick Hilliard wrote: > On 15/12/2012 23:07, David Conrad wrote: > > The handwringing over this issue is a bit over the top. > > It's a question of what's procedurally sensible. Sensible things would > include longer notice of the impending change to the root zone, more > widespread notice of what's happening and generally not poking around with > really important bits of the Internet at times which are well known for > having configuration freezes and/or when many people are going to be on > holidays. There are many bits of the internet where changes will only > affect small areas, but this change will affect everyone even if they > people don't realise it (and yes, it probably won't affect them visibly > because of root cache repriming). how much notice would you like? > > Other sensible things might include: > > - liaising with operating system vendors and recurser servers code authors > and providing them with extra advance notice so that they can roll these > changes into their code in a structured way. Software update release > cycles often take many months to roll out, particularly for non OSS code. its not clear this has not been done. nor is it clear that it would be needed, given the bootstrap methods that have been current for more than a decade. > - perhaps some targeted localisation of the d.root-servers.org notice so > that more than 15% of the world population can read it (english == 5% > native speakers, 10% second language)? its not clear this has not been done. where you you localise this notice and what methods would you use? > Lots of people are aware that resolver dns servers will automatically > reprime their root cache without manual intervention. However, not > everyone will realise it and a random punter who looks at this notice and > doesn't understand root cache mechanics may well think that they need to > start updating their DNS configuration files on Jan 3. It's not clear from > the change notification that you don't necessarily need to do this. true - there is an expectation that the reader has a basic understanding of the DNS. My grandmother would be confused, but would clearly understand from the notice that there were many months before the existing system would change. Perhaps the notice should suggest talking with your service provider if you don't understand or have questions. > This change wasn't planned over a coffee last thursday morning. It's > obviously been on the cards for several years, so asking for more carefully > structured notice in a procedurally sensible sort of way isn't an > unreasonable thing to expect as part of the migration plan. are these all the points that concern you? are there others? lets get them all on the table. > > Nick > From kmedcalf at dessus.com Sun Dec 16 04:44:14 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 15 Dec 2012 21:44:14 -0700 Subject: =?UTF-8?Q?Re:_Advisory_=E2=80=94_D-root_is_changing_i?= =?UTF-8?Q?ts_IPv4_address_on_the_3rd_of_January.?= Message-ID: If your grandmother were running her own recursive DNS resolver, I expect she would have no difficulty understanding the message. It is the young-uns that have difficulty comprehending (and using) the English language. Sent from Samsung Mobile -------- Original message -------- From: bmanning at vacation.karoshi.com Date: To: Nick Hilliard Cc: "nanog at nanog.org Group" Subject: Re: Advisory ? D-root is changing its IPv4 address on the 3rd of January. On Sun, Dec 16, 2012 at 12:45:32AM +0000, Nick Hilliard wrote: > On 15/12/2012 23:07, David Conrad wrote: > > The handwringing over this issue is a bit over the top. > > It's a question of what's procedurally sensible.? Sensible things would > include longer notice of the impending change to the root zone, more > widespread notice of what's happening and generally not poking around with > really important bits of the Internet at times which are well known for > having configuration freezes and/or when many people are going to be on > holidays.? There are many bits of the internet where changes will only > affect small areas, but this change will affect everyone even if they > people don't realise it (and yes, it probably won't affect them visibly > because of root cache repriming). how much notice would you like? > > Other sensible things might include: > > - liaising with operating system vendors and recurser servers code authors > and providing them with extra advance notice so that they can roll these > changes into their code in a structured way.? Software update release > cycles often take many months to roll out, particularly for non OSS code. its not clear this has not been done.? nor is it clear that it would be needed, given the bootstrap methods that have been current for more than a decade. > - perhaps some targeted localisation of the d.root-servers.org notice so > that more than 15% of the world population can read it (english == 5% > native speakers, 10% second language)? its not clear this has not been done. where you you localise this notice and what methods would you use? > Lots of people are aware that resolver dns servers will automatically > reprime their root cache without manual intervention.? However, not > everyone will realise it and a random punter who looks at this notice and > doesn't understand root cache mechanics may well think that they need to > start updating their DNS configuration files on Jan 3.? It's not clear from > the change notification that you don't necessarily need to do this. true - there is an expectation that the reader has a basic understanding of the DNS.? My grandmother would be confused, but would clearly understand from the notice that there were many months before the existing system would change.? Perhaps the notice should suggest talking with your service provider if you don't understand or have questions.? > This change wasn't planned over a coffee last thursday morning.? It's > obviously been on the cards for several years, so asking for more carefully > structured notice in a procedurally sensible sort of way isn't an > unreasonable thing to expect as part of the migration plan. are these all the points that concern you?? are there others? lets get them all on the table. > > Nick > From nick at foobar.org Sun Dec 16 12:07:23 2012 From: nick at foobar.org (Nick Hilliard) Date: Sun, 16 Dec 2012 12:07:23 +0000 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> <20121215223225.8805A2D13E64@drugs.dv.isc.org> <76ED8740-1958-43C1-9331-6C95C44FC89E@virtualized.org> <50CD19AC.7060708@foobar.org> Message-ID: <50CDB97B.2090002@foobar.org> On 16/12/2012 02:26, David Conrad wrote: > The UMD folks are making a change to _their_ infrastructure. as is their prerogative. It's just that they happen to operate a particular chunk of Internet infrastructure which is pretty important in the scale of things. > They have > sent out a notice in advance of that change to folks who might be > interested. They were under absolutely no obligation to do so. There is > no contractual or service level agreement between UMD and _anyone_ that > requires them to do _anything_ with regards to root service. yep, absolutely. > The fact > that they gave 3 weeks notice that they were changing the IP addresses > of their server shows they are nice folks. Neither you nor anyone else > that uses "D" has any right to dictate how UMD operates their > infrastructure, how much notice to give when making changes to that > infrastructure, who gets notified, etc. No-one's dictating: I'm just asking them politely to take some suggestions into consideration - suggestions which no-one has so far pointed out as being unreasonable, and which I would tend to view as being procedurally sensible and good things to do. That's all. Nick From ariel at post.tau.ac.il Sun Dec 16 13:02:04 2012 From: ariel at post.tau.ac.il (Ariel Biener) Date: Sun, 16 Dec 2012 15:02:04 +0200 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: <50CDB97B.2090002@foobar.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> <20121215223225.8805A2D13E64@drugs.dv.isc.org> <76ED8740-1958-43C1-9331-6C95C44FC89E@virtualized.org> <50CD19AC.7060708@foobar.org> <50CDB97B.2090002@foobar.org> Message-ID: <50CDC64C.7060006@post.tau.ac.il> Nick Hilliard wrote: > On 16/12/2012 02:26, David Conrad wrote: >> The UMD folks are making a change to _their_ infrastructure. A site who hosts a Global Internet critical infrastructure is not bound to the same procedures as a regular site. It takes a certain amount of trust to have one of the Internet's core devices hosted at your site. While it is sometimes required to perform changes, it is no wonder that the community is involved and worried, since the D root server is a global infrastructure device, regardless of where it is located, and it is expected from UMD to behave accordingly (not that they are not, but just in the grand scheme of things). I am pretty sure that UMD doesn't think that the D root is akin their web server, as you would suggest in your mail (their infrastructure, their server, their procedure, not owe anything to anyone, etc etc...) It is critical to all of us, and we can and should lend our advice or even request (and sometimes require) a level of assurance that we (that is the operators on theInternet which is being served by D, since D is no local UMD service) will not end up hurt. It is their decision to make ultimately, but they can and should hear us, and if there is actually a grain of wisdom in what is being said, to consider it and amend plans. While there is no "specific and contractual" SLA in place, that does not mean that a root server operator is free to do whatever they please with critical global infrastructure, and I am very sure that this attitude is not prevalent with any Root operator out there. best, -- Ariel -- Ariel Biener e-mail: ariel at post.tau.ac.il PGP: http://www.tau.ac.il/~ariel/pgp.html From jfmezei_nanog at vaxination.ca Sun Dec 16 18:23:16 2012 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 16 Dec 2012 13:23:16 -0500 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: <50CDB97B.2090002@foobar.org> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> <20121215223225.8805A2D13E64@drugs.dv.isc.org> <76ED8740-1958-43C1-9331-6C95C44FC89E@virtualized.org> <50CD19AC.7060708@foobar.org> <50CDB97B.2090002@foobar.org> Message-ID: <50CE1194.4010902@vaxination.ca> On 12-12-16 07:07, Nick Hilliard wrote: > No-one's dictating: I'm just asking them politely to take some suggestions > into consideration - suggestions which no-one has so far pointed out as > being unreasonable, and which I would tend to view as being procedurally > sensible and good things to do. That's all. I believe you are assuming that the department which runs tne root server at UMD has a choice in the matter. Consider a campus-wide IPv4 address space reorganisation to make better use of their available space. It would make sense to do this during summer when students are away. Having to stop using that IP by June would fit that scenario. The scarcity of IPv4 will result in more and more streamlining of network address spaces within organisations. While I have seen this announcement because I subscribed to nanog, I wouldnt be surprised to see that news spread via many other means. And how much more warning would one really need ? It isn't as if they were to announce that the end of the world will be this coming friday. (that one was announced centuries ago and isn't getting much press :-) This is a simple change, the internet will not stop running. It may take an extra second to reboot the bind servers that haven't gotten updates. From shrdlu at deaddrop.org Sun Dec 16 19:36:45 2012 From: shrdlu at deaddrop.org (Lynda) Date: Sun, 16 Dec 2012 11:36:45 -0800 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: <20121215055044.GA4647@vacation.karoshi.com.> References: <50CB5F67.5040108@foobar.org> <32936126.38747.1355507815632.JavaMail.root@benjamin.baylink.com> <80E95C9C-C9FA-4229-BE12-99BB2953F94C@hopcount.ca> <364AE42C-D844-4543-8FC4-CD7EBD318DEC@virtualized.org> <20121215055044.GA4647@vacation.karoshi.com.> Message-ID: <50CE22CD.10809@deaddrop.org> On 12/14/2012 9:50 PM, bmanning at vacation.karoshi.com wrote: > On Fri, Dec 14, 2012 at 08:48:07PM -0800, David Conrad wrote: >> On Dec 14, 2012, at 11:02 AM, Joe Abley wrote: >>> Other root servers have renumbered out of institutional, general-purpose networks into dedicated networks in the past. I think the last one was B-Root in 2004, >> >> Actually, it was "L" in 2007... :) > SOME people have very long memories. Actually, I have an excellent memory also. The one thing I do NOT remember is this much Sturm und Drang over any of the past changes. I believe that the first few changes were actually painful (they were for me), but really, everything has gone along just fine and dandy until now. I gently point out the following resource (which I'm sure nearly everyone here already knew about): http://www.zakon.org/robert/internet/timeline/ DNS first reared its head in 1984. For the very longest time I even kept my copy of hints updated by hand, leaving notes as to the old IP, so that I'd notice if anything from my end was trying to reach an old IP (the amount of stupidity hard coded in was just as bad then as now). I downloaded one of the last hosts.txt files, in 1992, out of sentiment. It still makes me nostalgic to look at it. Is it just me? I do not remember L or previous entries garnering this much attention, and it seems there was actually a bit less time between announcement of the change, and my ::face::palm:: when I saw log entries, and realized I was lazy. I have no idea when the IP was turned off, since it wouldn't have *mattered* to me. I do remember quite a bit of discussion here and there when the first ones were changing, but it was local discussion, when my world was a bit more narrow and focused. I did actually look (although not very hard) for an actual history of the original hosts, and the migrations from legacy IPs and legacy names into the less colorful format of *.root-servers.net that we know and love today. For those of you still worried, I promise it will all be okay. I promise. -- Put a smile on it, even if you don't feel like it. Try building something up, instead of tearing it down. Santa believes in you, even if you don't believe in him. From joly at punkcast.com Sun Dec 16 20:18:51 2012 From: joly at punkcast.com (Joly MacFie) Date: Sun, 16 Dec 2012 15:18:51 -0500 Subject: =?windows-1252?Q?Re=3A_VIDEO=3A_Mitigating_DDoS_Attacks=3A_Best_Practices_f?= =?windows-1252?Q?or_an_Evolving_Threat_Landscape_=96_NYC_12=2F5_=23DDoS?= In-Reply-To: References: Message-ID: It has been pointed out to me ( Thanks Yuri!) that I screwed up the url for the AMARA translation page for this, it is http://www.universalsubtitles.org/en-gb/videos/lvgGlpwZR0lA/info/mitigating-ddos-attacks-best-practices-for-an-evolving-threat-landscape/#video If I may say a bit more.about captioning in general... The Internet Society recently produced a paper 'Moving Forward' on the importance of increasing our efforts on accessibility, and another 'Local Content ' on how important language is in fostering the growth of the Internet. Video captioning is one area where everyone, via crowd-sourcing, can easily contribute, given the tools. AMARA is just such a tool. It's a simple 4 step process. Type, sync, info, and check. One can do as much/little as one can and then leave it for someone else to pick up and continue. It's a practice we can, and should, all learn. j On Sat, Dec 15, 2012 at 5:28 AM, Joly MacFie wrote: > As promised this is the full video of PIR's recent DDoS event in NYC. I've > waited to post it until we got the closed captioning done. If anyone should > be willing to volunteer to help translate the captions into other languages > they can do so via AMARA - > http://www.universalsubtitles.org/en/videos/lvgGlpwZR0lA/info/mitigating-ddos-attacks-best-practices-for-an-evolving-threat-landscape/- it's possible to just contribute as much or as little as you have time to > do. > > ** > joly posted: "The Internet Society's New York Chapter (ISOC-NY) and the > New York Technology Council (NYTECH) joined the Public Interest Registry > (PIR) in presenting a midday symposium "Mitigating DDoS Attacks: Best > Practices for an Evolving Threat Landscape" in New Yor" > > [image: Mitigating DDoS Attacks 12/5/2012]The > Internet Society's New York Chapter (ISOC-NY ) and > the New York Technology Council (NYTECH ) joined the > Public Interest Registry (PIR ) in presenting a > midday symposium "Mitigating DDoS Attacks: Best Practices for an Evolving > Threat Landscape " in New York City > on December 5 2012. Participating organizations included Afilias, Google, > Neustar, Symantec, EFF, and De Natris Consult. The event was webcast live > via the Internet Society Chapters Livestream Channel. Audio / transcript > links are below. English Closed captions are available. > > > MODERATOR > Brian Cute - CEO, Public Interest Registry (PIR) > > SPEAKERS > Jeff Greene - Senior Policy Counsel, Symantec > Ram Mohan - EVP & Chief Technology Officer, Afilias > Damian Menscher -- Security Engineer, Google > Miguel Ramos - Senior Product Manager, Neustar > Danny McPherson - Chief Security Officer, Verisign > Jillian York - Director for International Freedom of Expression, > Electronic Frontier Foundation (EFF) > > > > - Download audio : http://isoc-ny.org/ddos/mitigating_ddos.mp3 > - Download transcript: http://isoc-ny.org/ddos/mitigating_ddos.txt > > Comment See all comments > > > *Trouble clicking?* Copy and paste this URL into your browser: > http://isoc-ny.org/p2/4505 > > > > > > > -- > --------------------------------------------------------------- > 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 > -------------------------------------------------------------- > - > -- --------------------------------------------------------------- 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 dougb at dougbarton.us Sun Dec 16 20:20:57 2012 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 16 Dec 2012 12:20:57 -0800 Subject: btw, the itu imploded In-Reply-To: <50CB8CC2.2050700@foobar.org> References: <20121214195137.GA83702@mikea.ath.cx> <50CB8CC2.2050700@foobar.org> Message-ID: <50CE2D29.9030103@dougbarton.us> On 12/14/2012 12:32 PM, Nick Hilliard wrote: > I don't forsee this debate dying any time soon. What some of us have been saying since at least 2003 (if not earlier) is that it will _never_ die. Free speech, and the opportunities that an open Internet provide to the people who live in repressed regimes are the most dangerous things in the world to said regimes, and they will do everything in their power to eliminate them. I'm certain that most of you have already noticed how cutting off the Internet is now on page 1 of every country's list of "Things to do when there is an uprising ..." Doug From regnauld at nsrc.org Sun Dec 16 20:31:09 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Sun, 16 Dec 2012 21:31:09 +0100 Subject: btw, the itu imploded In-Reply-To: <50CE2D29.9030103@dougbarton.us> References: <20121214195137.GA83702@mikea.ath.cx> <50CB8CC2.2050700@foobar.org> <50CE2D29.9030103@dougbarton.us> Message-ID: <20121216203109.GA14566@x0.dk> On Sun, Dec 16, 2012 at 12:20:57PM -0800, Doug Barton wrote: > > I'm certain that most of you have already noticed how cutting off the > Internet is now on page 1 of every country's list of "Things to do when > there is an uprising ..." In Egypt, this may actually have led to the opposite of what the regime in place expected. Not the best source, but to illustrate: http://content.usatoday.com/communities/technologylive/post/2011/01/egyptian-protestors-ditch-tech-use-word-of-mouth-to-mobilize/1 It was argued that because there was no access to the net, and no other way to find out what was really going on, Egyptian citizens got off their couches and down into the street, which in some cases got some people to take sides and join the protests. Case of damned if you do, and damned if you don't, as far as censorship goes. Phil From dougb at dougbarton.us Sun Dec 16 20:36:22 2012 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 16 Dec 2012 12:36:22 -0800 Subject: btw, the itu imploded In-Reply-To: <20121216203109.GA14566@x0.dk> References: <20121214195137.GA83702@mikea.ath.cx> <50CB8CC2.2050700@foobar.org> <50CE2D29.9030103@dougbarton.us> <20121216203109.GA14566@x0.dk> Message-ID: <50CE30C6.9050608@dougbarton.us> On 12/16/2012 12:31 PM, Phil Regnauld wrote: > On Sun, Dec 16, 2012 at 12:20:57PM -0800, Doug Barton wrote: >> >> I'm certain that most of you have already noticed how cutting off the >> Internet is now on page 1 of every country's list of "Things to do when >> there is an uprising ..." > > In Egypt, this may actually have led to the opposite of what the regime > in place expected. Not the best source, but to illustrate: > > http://content.usatoday.com/communities/technologylive/post/2011/01/egyptian-protestors-ditch-tech-use-word-of-mouth-to-mobilize/1 > > It was argued that because there was no access to the net, and no > other way to find out what was really going on, Egyptian citizens > got off their couches and down into the street, which in some > cases got some people to take sides and join the protests. > > Case of damned if you do, and damned if you don't, as far as > censorship goes. Or, "Freedom routes around brokenness." :) From dougb at dougbarton.us Sun Dec 16 20:40:53 2012 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 16 Dec 2012 12:40:53 -0800 Subject: Advisory =?windows-1252?Q?=97_D-root_is_changing_its?= =?windows-1252?Q?_IPv4_address_on_the_3rd_of_January=2E?= In-Reply-To: <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> References: <50CA5CB1.8010306@umd.edu> <50CB5706.3090308@foobar.org> <50CB8877.80605@umd.edu> <50CB882A.30502@vaxination.ca> <20121215215846.3F69F2D13CFC@drugs.dv.isc.org> <42515678-F2CE-48CE-A0E6-4211C5F0F1A1@puck.nether.net> Message-ID: <50CE31D5.9070902@dougbarton.us> On 12/15/2012 02:13 PM, Jared Mauch wrote: > 3 weeks is plenty for a service that in 6 months you may see degraded to 12/13 capacity ... or 21/22 capacity, if you have IPv6. :) And the v6 address of D is not changing. FWIW I agree with the "tempest in a teapot" assessment. I think UMD has given more than adequate notice, and I'm looking at this from not only my perspective as former IANA-dude, but also as someone who formerly would have been the person to update this in FreeBSD. From a real, operational perspective, this is simply not that big a deal. In fact, it's hardly a deal at all. Doug From arnold at nipper.de Sun Dec 16 21:13:23 2012 From: arnold at nipper.de (Arnold Nipper) Date: Sun, 16 Dec 2012 22:13:23 +0100 Subject: Strict route filtering at IX? In-Reply-To: <20121212122209.1f2b08e7@marvin.nonattached.net> References: <20121212122209.1f2b08e7@marvin.nonattached.net> Message-ID: <50CE3973.9010605@nipper.de> On 12.12.2012 12:22, Dan Luedtke wrote: > So, here's the question: How do you filter at exchanges? Afaik BCP is to not prefix- as-path/origing-filtering well maintained routeservers at an IXP but simply put in max prefix limits. Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arnold at nipper.de phone: +49 6224 5593407 2 mobile: +49 172 2650958 fax: +49 6224 5593407 9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From iljitsch at muada.com Sun Dec 16 22:48:13 2012 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 16 Dec 2012 23:48:13 +0100 Subject: 32-bit ASes at routeviews Message-ID: Looking for 32-bit AS numbers, I get some strange results from routeviews: route-views>sh ip bgp regexp _23456_ BGP table version is 2393809200, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 31.177.16.0/22 128.223.253.10 0 3582 3701 3356 23456 3.1043 i * 46.29.72.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i * 46.243.96.0/21 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i * 91.208.62.0/24 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i * 91.217.87.0/24 194.85.40.15 0 3267 174 23456 3.661 i * 91.230.169.0/24 208.51.134.254 13905 0 3549 29152 29152 29152 29152 23456 23456 23456 23456 3.1426 i * 91.238.8.0/24 194.85.40.15 0 3267 8220 23456 3.2040 i * 111.235.148.0/22 194.85.40.15 0 3267 9498 9730 23456 i * 141.0.176.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i Unless I missed something, AS 23456 is supposed to show up as a stand-in for 32-bit ASNs on 16-bit BGP implementations, not in _addition_ to 32-bit ASNs. So the penultimate line would make sense if the other lines weren't there and the others don't make sense period. Maybe a bug in the IOS they're running? route-views>sh ver Cisco IOS Software, 7200 Software (C7200P-ADVENTERPRISEK9-M), Version 12.4(24)T2, RELEASE SOFTWARE (fc2) Or is something else going on? From cjeker at diehard.n-r-g.com Mon Dec 17 11:14:58 2012 From: cjeker at diehard.n-r-g.com (Claudio Jeker) Date: Mon, 17 Dec 2012 12:14:58 +0100 Subject: 32-bit ASes at routeviews In-Reply-To: References: Message-ID: <20121217111458.GA686@diehard.n-r-g.com> On Sun, Dec 16, 2012 at 11:48:13PM +0100, Iljitsch van Beijnum wrote: > Looking for 32-bit AS numbers, I get some strange results from routeviews: > > route-views>sh ip bgp regexp _23456_ > BGP table version is 2393809200, local router ID is 128.223.51.103 > Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, > r RIB-failure, S Stale > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path > * 31.177.16.0/22 128.223.253.10 0 3582 3701 3356 23456 3.1043 i > * 46.29.72.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i > * 46.243.96.0/21 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i > * 91.208.62.0/24 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i > * 91.217.87.0/24 194.85.40.15 0 3267 174 23456 3.661 i > * 91.230.169.0/24 208.51.134.254 13905 0 3549 29152 29152 29152 29152 23456 23456 23456 23456 3.1426 i > * 91.238.8.0/24 194.85.40.15 0 3267 8220 23456 3.2040 i > * 111.235.148.0/22 194.85.40.15 0 3267 9498 9730 23456 i > * 141.0.176.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i > > Unless I missed something, AS 23456 is supposed to show up as a stand-in for 32-bit ASNs on 16-bit BGP implementations, not in _addition_ to 32-bit ASNs. So the penultimate line would make sense if the other lines weren't there and the others don't make sense period. > > Maybe a bug in the IOS they're running? > > route-views>sh ver > Cisco IOS Software, 7200 Software (C7200P-ADVENTERPRISEK9-M), Version 12.4(24)T2, RELEASE SOFTWARE (fc2) > > Or is something else going on? This can happen when a old 2-byte only routers are doing prepends with the neighbor address (4-byte). Then the magic in the 4-byte AS RFC to fix up ASPATH has no chance to work and you will see 23456. -- :wq Claudio From andy at nosignal.org Mon Dec 17 11:42:17 2012 From: andy at nosignal.org (Andy Davidson) Date: Mon, 17 Dec 2012 11:42:17 +0000 Subject: Strict route filtering at IX? In-Reply-To: <20121212122209.1f2b08e7@marvin.nonattached.net> Message-ID: Hi, Dan -- On 12/12/2012 11:22, "Dan Luedtke" wrote: >So, here's the question: How do you filter at exchanges? >Where is the error in my workflow? >Is strict route filtering a myth? You can see if the route-servers at the IX already filter. For example, this is the case at LONAP, where strict filters against RADB are built. Networks with open policy and large numbers of peers will naturally find it hard to filter peer *prefixes* on session config, because as you have found the config quickly becomes large and unwieldy. As Arnold has said, filtering with max-prefix and AS-path is more common on bilateral sessions. My advice would be to encourage your IX operator to filter on the route-servers, and rely on MLP derived adjacency for networks that you want to peer with, but don't trust enough not to prefix-filter. Andy From randy at psg.com Mon Dec 17 13:14:50 2012 From: randy at psg.com (Randy Bush) Date: Mon, 17 Dec 2012 08:14:50 -0500 Subject: Advisory =?UTF-8?B?4oCU?= D-root is changing its IPv4 address on the 3rd of January. In-Reply-To: <50CE22CD.10809@deaddrop.org> References: <50CB5F67.5040108@foobar.org> <32936126.38747.1355507815632.JavaMail.root@benjamin.baylink.com> <80E95C9C-C9FA-4229-BE12-99BB2953F94C@hopcount.ca> <364AE42C-D844-4543-8FC4-CD7EBD318DEC@virtualized.org> Message-ID: > Actually, I have an excellent memory also. The one thing I do NOT > remember is this much Sturm und Drang over any of the past changes. increase in number of people who can't resist telling others what they should do randy From jsw at inconcepts.biz Mon Dec 17 14:41:51 2012 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 17 Dec 2012 09:41:51 -0500 Subject: 32-bit ASes at routeviews In-Reply-To: <20121217111458.GA686@diehard.n-r-g.com> References: <20121217111458.GA686@diehard.n-r-g.com> Message-ID: On Mon, Dec 17, 2012 at 6:14 AM, Claudio Jeker wrote: > This can happen when a old 2-byte only routers are doing prepends with the > neighbor address (4-byte). Then the magic in the 4-byte AS RFC to fix up > ASPATH has no chance to work and you will see 23456. After a careful re-read of RFC4893 section 4.2.3 Processing Received Updates, I am fairly sure it is either an implementation issue with the involved 4-octet ASN routers, or else their transit providers are using as-path-*expand* when learning their routes for some reason (customers ask for the strangest things.) The specification for 4-octet AS refers to "old" and "new" BGP speakers, which I'll do here: When NEW speaker receives a route from an OLD speaker, its job is to make AS_PATH and AS4_PATH the same length by using ASNs from from AS_PATH, which cannot have been inserted into AS4_PATH by the OLD speaker(s) that do not support the Attribute. If a NEW speaker implements as-path-prepend incorrectly, and puts 23456 (AS_TRANS) into AS4_PATH instead of his real ASN, then the route passes through some OLD speakers and out to a NEW one again, the second NEW speaker has no opportunity to reconstruct the correct path. On the other hand, if an OLD speaker is configured for as-path-*expand* as it learns routes from a NEW speaker, then it may insert AS_TRANS into the AS_PATH but no entries are being pushed to AS4_PATH. This is a limitation of the specification and cannot be avoided. In effect, the use of as-path-* expand* at a NEW->OLD boundary where the NEW router has a 4-octet ASN and OLD router is performing *expand* means the correct AS_PATH cannot be rebuilt. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From jwininger at ifncom.net Mon Dec 17 16:56:30 2012 From: jwininger at ifncom.net (James Wininger) Date: Mon, 17 Dec 2012 16:56:30 +0000 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: Eric, We recently migrate away from IPPlan to 6connect. There is significant cost to the application but the end result (IMHO) is well worth it. IPPlan was great that is used MySQL, as many of us use that DB, so integration was easy, but what we were trying to do with the integration on the "backend" with IPPlan, 6connect does out of the box. DNS integration, RESTful with ARIN, user access control etc. Not trying to sell the product here, just saying that we went through what you are going through and if it helps, I wish we had the time back that we put into IPPlan. They have hosted and "local" installs available, but they prefer the hosted model. We did local install. -- Jim On Dec 12, 2012, at 8:22 PM, Eric A Louie wrote: I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small staff of engineers. They have regionalized IP addresses so blocks are local, but there are subnets that are global. don't care if it's a linux or windows solution. Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) We're not dealing with a lot now, but the potential for growth is pretty high. What are you using and how is it working for you? Much appreciated, Eric From jwininger at ifncom.net Mon Dec 17 17:01:15 2012 From: jwininger at ifncom.net (James Wininger) Date: Mon, 17 Dec 2012 17:01:15 +0000 Subject: Fiber only in DataCenters? Message-ID: Hello all, Looking for input from "providers" as well as "consumers" of data center space and facilities. Specifically speaking to the types of available physical cross connects. Are there data centers out there that are "fiber only"? That is to say that the cross connects are fiber only and no copper cross connects are available? I understand that fiber is great and all, but to my knowledge there are a lot of folks still using and needing copper cross connects. Am I wrong? -- Jim From lathama at gmail.com Mon Dec 17 17:14:27 2012 From: lathama at gmail.com (Andrew Latham) Date: Mon, 17 Dec 2012 12:14:27 -0500 Subject: Fiber only in DataCenters? In-Reply-To: References: Message-ID: On Mon, Dec 17, 2012 at 12:01 PM, James Wininger wrote: > Hello all, > > Looking for input from "providers" as well as "consumers" of data center space and facilities. Specifically speaking to the types of available physical cross connects. > > Are there data centers out there that are "fiber only"? That is to say that the cross connects are fiber only and no copper cross connects are available? > > I understand that fiber is great and all, but to my knowledge there are a lot of folks still using and needing copper cross connects. Am I wrong? > -- > > Jim In general the physical size and space needed for security make fiber a requirement. Copper is very useful but ladder racks and managed cabling can make runs much longer. Fiber is simply the next scale. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From walter.keen at rainierconnect.net Mon Dec 17 17:14:32 2012 From: walter.keen at rainierconnect.net (Walter Keen) Date: Mon, 17 Dec 2012 09:14:32 -0800 (PST) Subject: Fiber only in DataCenters? In-Reply-To: Message-ID: <2086788147.6540281.1355764472400.JavaMail.root@zimbra01.rainierconnect.net> Many of the colocation datacenters or carrier hotel datacenters we are in only have copper facilities for tdm based circuits such as DS1 and DS3. The distance in many of these are simply too great for a copper ethernet connection. ( > 100m ) Some smaller ones prefer copper, where distance is not an issue, but I've found that to be the minority. ----- Original Message ----- From: "James Wininger" To: nanog at nanog.org Sent: Monday, December 17, 2012 9:01:15 AM Subject: Fiber only in DataCenters? Hello all, Looking for input from "providers" as well as "consumers" of data center space and facilities. Specifically speaking to the types of available physical cross connects. Are there data centers out there that are "fiber only"? That is to say that the cross connects are fiber only and no copper cross connects are available? I understand that fiber is great and all, but to my knowledge there are a lot of folks still using and needing copper cross connects. Am I wrong? -- Jim From joelja at bogus.com Mon Dec 17 17:22:08 2012 From: joelja at bogus.com (joel jaeggli) Date: Mon, 17 Dec 2012 09:22:08 -0800 Subject: Fiber only in DataCenters? In-Reply-To: References: Message-ID: <50CF54C0.9010106@bogus.com> On 12/17/12 9:01 AM, James Wininger wrote: > Hello all, > > Looking for input from "providers" as well as "consumers" of data center space and facilities. Specifically speaking to the types of available physical cross connects. > > Are there data centers out there that are "fiber only"? That is to say that the cross connects are fiber only and no copper cross connects are available? > > I understand that fiber is great and all, but to my knowledge there are a lot of folks still using and needing copper cross connects. Am I wrong? If the facility is big enough the utility of twisted pair becomes quite limited, both due to distance and differing electrical potential, multibuilding campuses in particular make this is a nonstarter. In one facility I'm in, I'm over 300 meters from each of the MMRs, with the results that the OOB for the serial console server for out equipment located out there in the MMR's being on serial over fiber transceivers connected by om4 multimode. > -- > > Jim > > From isabeldias1 at yahoo.com Mon Dec 17 17:26:49 2012 From: isabeldias1 at yahoo.com (Isabel Dias) Date: Mon, 17 Dec 2012 09:26:49 -0800 (PST) Subject: Fiber only in DataCenters? In-Reply-To: <2086788147.6540281.1355764472400.JavaMail.root@zimbra01.rainierconnect.net> References: <2086788147.6540281.1355764472400.JavaMail.root@zimbra01.rainierconnect.net> Message-ID: <1355765209.57483.YahooMailNeo@web164601.mail.gq1.yahoo.com> walter, i couldn't care less about your problem! get the message! ________________________________ From: Walter Keen To: James Wininger Cc: nanog at nanog.org Sent: Monday, December 17, 2012 5:14 PM Subject: Re: Fiber only in DataCenters? Many of the colocation datacenters or carrier hotel datacenters we are in only have copper facilities for tdm based circuits such as DS1 and DS3.? The distance in many of these are simply too great for a copper ethernet connection. ( > 100m ) Some smaller ones prefer copper, where distance is not an issue, but I've found that to be the minority. ----- Original Message ----- From: "James Wininger" To: nanog at nanog.org Sent: Monday, December 17, 2012 9:01:15 AM Subject: Fiber only in DataCenters? Hello all, Looking for input from "providers" as well as "consumers" of data center space and facilities. Specifically speaking to the types of available physical cross connects. Are there data centers out there that are "fiber only"? That is to say that the cross connects are fiber only and no copper cross connects are available? I understand that fiber is great and all, but to my knowledge there are a lot of folks still using and needing copper cross connects. Am I wrong? -- Jim From owen at delong.com Mon Dec 17 18:01:15 2012 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Dec 2012 10:01:15 -0800 Subject: Fiber only in DataCenters? In-Reply-To: References: Message-ID: <09D7B515-2618-4EF3-9A72-939616BFBD21@delong.com> On Dec 17, 2012, at 09:14 , Andrew Latham wrote: > On Mon, Dec 17, 2012 at 12:01 PM, James Wininger wrote: >> Hello all, >> >> Looking for input from "providers" as well as "consumers" of data center space and facilities. Specifically speaking to the types of available physical cross connects. >> >> Are there data centers out there that are "fiber only"? That is to say that the cross connects are fiber only and no copper cross connects are available? >> >> I understand that fiber is great and all, but to my knowledge there are a lot of folks still using and needing copper cross connects. Am I wrong? >> -- >> >> Jim > > In general the physical size and space needed for security make fiber > a requirement. Copper is very useful but ladder racks and managed > cabling can make runs much longer. Fiber is simply the next scale. > > I have yet to see a datacenter that doesn't offer both. That does not mean that all runs within any given datacenter can be done via copper, but I don't now of any datacenters that do not make copper cross-connects available to customers that wish to purchase them. Owen From jeroen at mompl.net Mon Dec 17 19:33:17 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 17 Dec 2012 11:33:17 -0800 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> Message-ID: <50CF737D.8080008@mompl.net> On 11/30/2012 02:02 PM, Naslund, Steve wrote: > OK, there must be a lot more paranoid people out there than I thought > for awhile? I am sure he will let you out to go to the bank, get your > stuff, and leave town. I think you have seen way to many movies. > So if the cops show up at his door tomorrow and say "Here's all your > stuff back, there was no evidence of a crime.", you are OK with this > guys keeping the "defense fund"? I for one vote for installing a de-gauging ring in your door frame. any removal of equipment you don't approve of will be wiped. That and encryption possibly combined with hiding the "real" OS (truecrypt can do that). Greetings, Jeroen -- Earthquake Magnitude: 5.1 Date: Monday, December 17, 2012 17:46:48 UTC Location: central East Pacific Rise Latitude: -3.9682; Longitude: -104.0375 Depth: 15.70 km From kyle.creyts at gmail.com Mon Dec 17 19:52:25 2012 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Mon, 17 Dec 2012 11:52:25 -0800 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <50CF737D.8080008@mompl.net> References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> <50CF737D.8080008@mompl.net> Message-ID: In most jurisdictions, wouldn't using a de-gaussing ring in the door frame to wipe any equipment being removed constitute "tampering with evidence" or interfering with an investigation if the authority in question is in possession of a warrant/subpoena? On Mon, Dec 17, 2012 at 11:33 AM, Jeroen van Aart wrote: > On 11/30/2012 02:02 PM, Naslund, Steve wrote: > >> OK, there must be a lot more paranoid people out there than I thought >> > > for awhile? I am sure he will let you out to go to the bank, get your >> stuff, and leave town. I think you have seen way to many movies. >> > > So if the cops show up at his door tomorrow and say "Here's all your >> stuff back, there was no evidence of a crime.", you are OK with this >> guys keeping the "defense fund"? >> > > I for one vote for installing a de-gauging ring in your door frame. any > removal of equipment you don't approve of will be wiped. That and > encryption possibly combined with hiding the "real" OS (truecrypt can do > that). > > Greetings, > Jeroen > > -- > Earthquake Magnitude: 5.1 > Date: Monday, December 17, 2012 17:46:48 UTC > Location: central East Pacific Rise > Latitude: -3.9682; Longitude: -104.0375 > Depth: 15.70 km > > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From greg.whynott at gmail.com Mon Dec 17 21:14:07 2012 From: greg.whynott at gmail.com (greg whynott) Date: Mon, 17 Dec 2012 16:14:07 -0500 Subject: =?UTF-8?Q?Re=3A_Advisory_=E2=80=94_D=2Droot_is_changing_its_IPv4_address?= =?UTF-8?Q?_on_the_3rd_of_January=2E?= In-Reply-To: References: <50CB5F67.5040108@foobar.org> <32936126.38747.1355507815632.JavaMail.root@benjamin.baylink.com> <80E95C9C-C9FA-4229-BE12-99BB2953F94C@hopcount.ca> <364AE42C-D844-4543-8FC4-CD7EBD318DEC@virtualized.org> <50CE22CD.10809@deaddrop.org> Message-ID: and ones who don't read posts before responding. On Mon, Dec 17, 2012 at 8:14 AM, Randy Bush wrote: > > Actually, I have an excellent memory also. The one thing I do NOT > > remember is this much Sturm und Drang over any of the past changes. > > increase in number of people who can't resist telling others what they > should do > > randy > > From alter3d at alter3d.ca Mon Dec 17 21:28:28 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Mon, 17 Dec 2012 16:28:28 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> <50CF737D.8080008@mompl.net> Message-ID: <50CF8E7C.3080001@alter3d.ca> Drifting a big off topic for NANOG (but hey, that happens every /pi/ days anyways!), but I'll toss this in... Like every other legal incident, it would be unique to your own situation. Keep in mind that, should any of the charges you mentioned go to court, the prosecution would have to prove /mens rea/ (intent). They would have to prove that you intended to cause the drives to be wiped specifically because you did not want them admitted as evidence. If you weren't even home at the time the warrant was executed, the worst lawyer in the world would be able to argue that you have the system in place to prevent sensitive data from leaving in the event of common theft, and that it's not your fault the police triggered it (and suggest that maybe they should add "scan for an intense EM field" to their standard procedures when dealing with computer equipment :p ). If you were home at the time (or knew that a warrant was being executed, e.g. if the police show up at your workplace to inform you), things would be a lot dicier. Actively hitting the "turn on the system" button would definitely be bad news for you. However, simply not turning it off as the officers are walking out the door, well... it was a VERY stressful situation for you, with all the police running all over your house, and you simply forgot about the system until much later (or so your lawyer could argue). There would definitely be some unhappy people with the situation regardless, and either way you'll be contributing to buying your lawyer a new car. ;) Now, having said all that... I'm not sure I'd want to pay the electricity bill for keeping that degausser running... :p - Pete On 12/17/2012 02:52 PM, Kyle Creyts wrote: > In most jurisdictions, wouldn't using a de-gaussing ring in the door frame > to wipe any equipment being removed constitute "tampering with evidence" or > interfering with an investigation if the authority in question is in > possession of a warrant/subpoena? > > On Mon, Dec 17, 2012 at 11:33 AM, Jeroen van Aart wrote: > >> On 11/30/2012 02:02 PM, Naslund, Steve wrote: >> >>> OK, there must be a lot more paranoid people out there than I thought >>> >> for awhile? I am sure he will let you out to go to the bank, get your >>> stuff, and leave town. I think you have seen way to many movies. >>> >> So if the cops show up at his door tomorrow and say "Here's all your >>> stuff back, there was no evidence of a crime.", you are OK with this >>> guys keeping the "defense fund"? >>> >> I for one vote for installing a de-gauging ring in your door frame. any >> removal of equipment you don't approve of will be wiped. That and >> encryption possibly combined with hiding the "real" OS (truecrypt can do >> that). >> >> Greetings, >> Jeroen >> >> -- >> Earthquake Magnitude: 5.1 >> Date: Monday, December 17, 2012 17:46:48 UTC >> Location: central East Pacific Rise >> Latitude: -3.9682; Longitude: -104.0375 >> Depth: 15.70 km >> >> > From Valdis.Kletnieks at vt.edu Mon Dec 17 21:38:15 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 17 Dec 2012 16:38:15 -0500 Subject: 32-bit ASes at routeviews In-Reply-To: Your message of "Sun, 16 Dec 2012 23:48:13 +0100." References: Message-ID: <34521.1355780295@turing-police.cc.vt.edu> On Sun, 16 Dec 2012 23:48:13 +0100, Iljitsch van Beijnum said: > Looking for 32-bit AS numbers, I get some strange results from > routeviews: > Unless I missed something, AS 23456 is supposed to show up as a stand-in > for 32-bit ASNs on 16-bit BGP implementations, not in _addition_ to > 32-bit ASNs. So the penultimate line would make sense if the other lines > weren't there and the others don't make sense period. > > Maybe a bug in the IOS they're running? > Or is something else going on? I think you've just found a number of AS's that are at high risk of being mystified when D-root shuts down 7 months from now. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Mon Dec 17 21:45:34 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 17 Dec 2012 16:45:34 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: Your message of "Mon, 17 Dec 2012 16:28:28 -0500." <50CF8E7C.3080001@alter3d.ca> References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> <50CF737D.8080008@mompl.net> <50CF8E7C.3080001@alter3d.ca> Message-ID: <34925.1355780734@turing-police.cc.vt.edu> On Mon, 17 Dec 2012 16:28:28 -0500, Peter Kristolaitis said: > Now, having said all that... I'm not sure I'd want to pay the > electricity bill for keeping that degausser running... :p An EMP device doesn't have to chew power all the time... And of course, there's this: http://www.youtube.com/watch?v=8vxEimC3HME -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From marka at isc.org Mon Dec 17 23:53:26 2012 From: marka at isc.org (Mark Andrews) Date: Tue, 18 Dec 2012 10:53:26 +1100 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: Your message of "Mon, 17 Dec 2012 16:45:34 CDT." <34925.1355780734@turing-police.cc.vt.edu> References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> <50CF737D.8080008@mompl.net> <50CF8E7C.3080001@alter3d.ca> <34925.1355780734@turing-police.cc.vt.edu> Message-ID: <20121217235326.5D3ED2D22427@drugs.dv.isc.org> In message <34925.1355780734 at turing-police.cc.vt.edu>, Valdis.Kletnieks at vt.edu writes: > --==_Exmh_1355780734_2398P > Content-Type: text/plain; charset=us-ascii > > On Mon, 17 Dec 2012 16:28:28 -0500, Peter Kristolaitis said: > > > Now, having said all that... I'm not sure I'd want to pay the > > electricity bill for keeping that degausser running... :p > > An EMP device doesn't have to chew power all the time... > > And of course, there's this: http://www.youtube.com/watch?v=8vxEimC3HME I suspect you would fine that such a ring would illegal as it is a potential "man trap". There are reasons hospitals have big warning signs around similar equipment used for medical imaging. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From kmedcalf at dessus.com Tue Dec 18 01:53:03 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 17 Dec 2012 18:53:03 -0700 Subject: =?UTF-8?Q?Re:_Advisory_=E2=80=94_D-root_is_changing_i?= =?UTF-8?Q?ts_IPv4_address_on_the_3rd_of_January.?= Message-ID: <9lnais7c7ei9jielx67hx4be.1355795581892@email.android.com> Concomittant wirh reduced risk assessment capability? Sent from Samsung Mobile -------- Original message -------- From: Randy Bush Date: To: Lynda Cc: North American Network Operators' Group Subject: Re: Advisory ? D-root is changing its IPv4 address on the 3rd of January. From mysidia at gmail.com Tue Dec 18 02:45:04 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 17 Dec 2012 20:45:04 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20121217235326.5D3ED2D22427@drugs.dv.isc.org> References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> <50CF737D.8080008@mompl.net> <50CF8E7C.3080001@alter3d.ca> <34925.1355780734@turing-police.cc.vt.edu> <20121217235326.5D3ED2D22427@drugs.dv.isc.org> Message-ID: On 12/17/12, Mark Andrews wrote: > In message <34925.1355780734 at turing-police.cc.vt.edu>, >> On Mon, 17 Dec 2012 16:28:28 -0500, Peter Kristolaitis said: Yeah... degaussing rings consume a lot of energy you shouldn't need to consume. If you _must_ be able to protect data from extreme physical threats: keep it encrypted end to end at all times, and concentrate on Information assurance for the key itself, and making the equipment tamper resistant, to prevent eavesdropping, for example: by incorporating computer chassis into the support structure of the building, with, EM shielding, plate steel vault doors and relocking mechanisms; just as you'd want to safeguard other physical valuables. Encryption keys are short, and easy to store on small tamper-resistant smartcards, which can be burned up or erased in a second by a low voltage circuit; possibly one triggered automatically if the incorrect PIN is entered, or the correct 3rd or 4th (easily accidentally lost, or left at some other place) SIM Card/Micro-sim shapped parts containing enough other shares of the encryption key aren't inserted in a partner module shortly after powerup. As long as the crypto algorithm was sound, reliable destruction of the key should make the data as hard (or harder) to be recovered, than if media had been degaussed. >> And of course, there's this: http://www.youtube.com/watch?v=8vxEimC3HME > I suspect you would fine that such a ring would illegal as it is a > potential "man trap". There are reasons hospitals have big warning > signs around similar equipment used for medical imaging. > > Mark -- -JH From jfmezei_nanog at vaxination.ca Tue Dec 18 04:42:28 2012 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 17 Dec 2012 23:42:28 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> <50CF737D.8080008@mompl.net> <50CF8E7C.3080001@alter3d.ca> <34925.1355780734@turing-police.cc.vt.edu> <20121217235326.5D3ED2D22427@drugs.dv.isc.org> Message-ID: <50CFF434.1090901@vaxination.ca> On 12-12-17 21:45, Jimmy Hess wrote: > Yeah... degaussing rings consume a lot of energy you shouldn't need > to consume. Now now, you clearly have not watched enough scient fiction/action movies... Clearly, you have a mechanism which triggers the degaussing (or neutron bomb in the basement the minute a hard drive is disconnected from the server/disk array :-) And you just need to put up a sign "warning, this building is protected with a giant degaussing magnet to protect against data theft, remove all rings from your body parts if you intend to steal from this building :-) Note that they used this trick in "Breaking Bad" with a giant magnet in a van parked right next to where evidence room and they managed to zap the laptop that contained evidence against them. Of course, the laws of physics don't apply in Hollywood so it is not clear whether this is realistic or not. From henry at AegisInfoSys.com Tue Dec 18 07:02:24 2012 From: henry at AegisInfoSys.com (Henry Yen) Date: Tue, 18 Dec 2012 02:02:24 -0500 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> <50CF737D.8080008@mompl.net> <50CF8E7C.3080001@alter3d.ca> <34925.1355780734@turing-police.cc.vt.edu> <20121217235326.5D3ED2D22427@drugs.dv.isc.org> Message-ID: <20121218070223.GH16820@nntp.AegisInfoSys.com> On Mon, Dec 17, 2012 at 20:45:04AM -0600, Jimmy Hess wrote: > If you _must_ be able to protect data from extreme > physical threats: keep it encrypted end to end at all times, Physical threat is somewhat different than seizure by law enforcement, though. Although mooted when authorities decrypted an evidentiary laptop themselves, the idea of encryption as a shield against law enforcement is not yet a settled issue in the US; see the "Fricosu" case. A nice explanation: https://www.eff.org/deeplinks/2012/03/tale-two-encryption-cases -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From mysidia at gmail.com Tue Dec 18 07:32:56 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 18 Dec 2012 01:32:56 -0600 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: <20121218070223.GH16820@nntp.AegisInfoSys.com> References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> <50CF737D.8080008@mompl.net> <50CF8E7C.3080001@alter3d.ca> <34925.1355780734@turing-police.cc.vt.edu> <20121217235326.5D3ED2D22427@drugs.dv.isc.org> <20121218070223.GH16820@nntp.AegisInfoSys.com> Message-ID: On 12/18/12, Henry Yen wrote: > On Mon, Dec 17, 2012 at 20:45:04AM -0600, Jimmy Hess wrote: > Physical threat is somewhat different than seizure by law enforcement, > though. I'm not so sure about that. It's a kind of physical threat; the set of all physical threats includes a subset of threats that are LEO threats involving authorities and are related to (quasi-)legal threats. The law enforcement personnel may have been paid off by a rogue party in the first place, to seize and "misplace" the data (E.g. deny the legitimate principal access to it for the purposes of competitive advantage), or to seize and "accidentally" leak the data to overseas entity attempting to gain the data for economic advantage, by taking advantage of insufficient security controls of the law enforcement entity. > the idea of encryption as a shield against law enforcement is not yet a > settled issue in the US; see the "Fricosu" case. A nice explanation: > https://www.eff.org/deeplinks/2012/03/tale-two-encryption-cases It obviously wouldn't work for all kinds of data, but; even if it's not a 5th amendment issue; E.g. "required to reveal your keys and allow the data to be decrypted"; the POSSIBILITY has to exist that that you can in fact know or recover the keys. You can't testify against yourself, if you had your memory permanently wiped in some manner, so that you are incapable of ever recalling, because "there's nothing there to present" --- it doesn't matter if there was no 5th amendment, the fact your memory was wiped, erased the possibility of ever testifying. If an automatic response to the security breach results in complete reliable destruction of physical and logical devices absolutely required to be fully intact to recover the keys and execute decryption activity, then "there is inherently nothing to provide", once that occured; the remaining option would be for the LEO to dedicate massive computing resources over a sufficient hundred years, to discover the key through brute force key space search of 10^77+ keys. That's assuming no backups of the key devices. > -- > Henry Yen Aegis Information Systems, -- -JH From nanog at bitfreak.org Tue Dec 18 15:09:21 2012 From: nanog at bitfreak.org (Darren Pilgrim) Date: Tue, 18 Dec 2012 07:09:21 -0800 Subject: www.eftps.gov contact Message-ID: <50D08721.7090002@bitfreak.org> The hostname www.eftps.gov has both A and AAAA records, but the site is only reachable via IPv4. Worse, the IPv6 connectivity is broken in such a way that Firefox and Internet Explorer do not fall back to IPv4. Tracing is broken for both protocols. The 10-net addresss in the IPv4 path were cute. Calling their technical support was an exercise in futility. Supposedly they forwarded messages on to the right people; but the site is still broken after over a week's wait. If someone knows the admins behind the EFTPS website and can forward this to them, the accounting firm for which I work would appreciate it. Thanks, From brandon at bitradius.com Tue Dec 18 04:10:50 2012 From: brandon at bitradius.com (Brandon Lehmann) Date: Tue, 18 Dec 2012 04:10:50 +0000 Subject: William was raided for running a Tor exit node. Please help if you can. In-Reply-To: References: <20121130125853.GB7333@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0D7120F5@MUNEXBE1.medline.com> <50B92ACC.70104@alter3d.ca> <2A76E400AC84B845AAC35AA19F8E7A5D0D7121C9@MUNEXBE1.medline.com> <50CF737D.8080008@mompl.net> Message-ID: <15AE4040AA24964AAE3DA9F2DE04C4F589983858@W2K8-EX.corp.bitradius.com> In any event, I'm pretty sure that I'd rather get hit with "tampering with evidence" versus them retrieving data that may incriminate me. I believe this may be a the "lesser of two evils" game. > -----Original Message----- > From: Kyle Creyts [mailto:kyle.creyts at gmail.com] > Sent: Monday, December 17, 2012 2:52 PM > To: Jeroen van Aart > Cc: nanog at nanog.org > Subject: Re: William was raided for running a Tor exit node. Please > help if you can. > > In most jurisdictions, wouldn't using a de-gaussing ring in the door > frame to wipe any equipment being removed constitute "tampering with > evidence" or interfering with an investigation if the authority in > question is in possession of a warrant/subpoena? > > On Mon, Dec 17, 2012 at 11:33 AM, Jeroen van Aart > wrote: > > > On 11/30/2012 02:02 PM, Naslund, Steve wrote: > > > >> OK, there must be a lot more paranoid people out there than I > thought > >> > > > > for awhile? I am sure he will let you out to go to the bank, get > > your > >> stuff, and leave town. I think you have seen way to many movies. > >> > > > > So if the cops show up at his door tomorrow and say "Here's all your > >> stuff back, there was no evidence of a crime.", you are OK with this > >> guys keeping the "defense fund"? > >> > > > > I for one vote for installing a de-gauging ring in your door frame. > > any removal of equipment you don't approve of will be wiped. That and > > encryption possibly combined with hiding the "real" OS (truecrypt can > > do that). > > > > Greetings, > > Jeroen > > > > -- > > Earthquake Magnitude: 5.1 > > Date: Monday, December 17, 2012 17:46:48 UTC > > Location: central East Pacific Rise > > Latitude: -3.9682; Longitude: -104.0375 > > Depth: 15.70 km > > > > > > > -- > Kyle Creyts > > Information Assurance Professional > BSidesDetroit Organizer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2739 bytes Desc: not available URL: From itg at itechgeek.com Tue Dec 18 07:30:31 2012 From: itg at itechgeek.com (ITechGeek) Date: Tue, 18 Dec 2012 02:30:31 -0500 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D=2Droot_is_changing_its_IPv4_address?= =?windows-1252?Q?_on_the_3rd_of_January=2E?= In-Reply-To: <9lnais7c7ei9jielx67hx4be.1355795581892@email.android.com> References: <9lnais7c7ei9jielx67hx4be.1355795581892@email.android.com> Message-ID: For anyone who is worried that the root server change might impact them, they can go to http://www.iana.org/domains/root/files and download the root zone file. It probably won't need to be updated again until the next round of gTLDs is approved. ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) ITG at ITechGeek.Com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Key ID: DCB1191A / Fingerprint: AB46B7E363DA7E04ABFA57852AA9910ADCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net On Mon, Dec 17, 2012 at 8:53 PM, Keith Medcalf wrote: > Concomittant wirh reduced risk assessment capability? > > > Sent from Samsung Mobile > > -------- Original message -------- > From: Randy Bush > Date: > To: Lynda > Cc: North American Network Operators' Group > Subject: Re: Advisory ? D-root is changing its IPv4 address on the 3rd of > January. > > From dmburgess at linktechs.net Tue Dec 18 15:26:12 2012 From: dmburgess at linktechs.net (Dennis Burgess) Date: Tue, 18 Dec 2012 09:26:12 -0600 Subject: www.eftps.gov contact References: <50D08721.7090002@bitfreak.org> Message-ID: <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> I tried to this a month ago, no luck :( i.e. nothing back from them, just goes into no answer e-mail space! Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition"???????????????????????????????? ?Link Technologies, Inc -- Mikrotik & WISP Support Services??????????????????????????????????????????????????????????????????????????????????? ?Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs???????????????????????????????????????????????????? ?-- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace? -----Original Message----- From: Darren Pilgrim [mailto:nanog at bitfreak.org] Sent: Tuesday, December 18, 2012 9:09 AM To: nanog at nanog.org Subject: www.eftps.gov contact The hostname www.eftps.gov has both A and AAAA records, but the site is only reachable via IPv4. Worse, the IPv6 connectivity is broken in such a way that Firefox and Internet Explorer do not fall back to IPv4. Tracing is broken for both protocols. The 10-net addresss in the IPv4 path were cute. Calling their technical support was an exercise in futility. Supposedly they forwarded messages on to the right people; but the site is still broken after over a week's wait. If someone knows the admins behind the EFTPS website and can forward this to them, the accounting firm for which I work would appreciate it. Thanks, From morrowc.lists at gmail.com Tue Dec 18 15:33:46 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Dec 2012 10:33:46 -0500 Subject: www.eftps.gov contact In-Reply-To: <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> Message-ID: if only some us-gov folks read this mailing list... maybe someone form NIST could aim the right question to the right eftps.gov people? you'd think helping the taxman would be appreciated. On Tue, Dec 18, 2012 at 10:26 AM, Dennis Burgess wrote: > I tried to this a month ago, no luck :( i.e. nothing back from them, just goes into no answer e-mail space! > > Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" > Link Technologies, Inc -- Mikrotik & WISP Support Services > Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs > -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace > > > > -----Original Message----- > From: Darren Pilgrim [mailto:nanog at bitfreak.org] > Sent: Tuesday, December 18, 2012 9:09 AM > To: nanog at nanog.org > Subject: www.eftps.gov contact > > The hostname www.eftps.gov has both A and AAAA records, but the site is only reachable via IPv4. Worse, the IPv6 connectivity is broken in such a way that Firefox and Internet Explorer do not fall back to IPv4. > Tracing is broken for both protocols. The 10-net addresss in the IPv4 path were cute. > > Calling their technical support was an exercise in futility. Supposedly they forwarded messages on to the right people; but the site is still broken after over a week's wait. If someone knows the admins behind the EFTPS website and can forward this to them, the accounting firm for which I work would appreciate it. > > Thanks, > > From morrowc.lists at gmail.com Tue Dec 18 15:35:24 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Dec 2012 10:35:24 -0500 Subject: www.eftps.gov contact In-Reply-To: References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> Message-ID: On Tue, Dec 18, 2012 at 10:33 AM, Christopher Morrow wrote: > if only some us-gov folks read this mailing list... > maybe someone form NIST could aim the right question to the right > eftps.gov people? > you'd think helping the taxman would be appreciated. > it's probably also fair to point out that ... it seems to be working. (AAAA and A) > On Tue, Dec 18, 2012 at 10:26 AM, Dennis Burgess > wrote: >> I tried to this a month ago, no luck :( i.e. nothing back from them, just goes into no answer e-mail space! >> >> Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" >> Link Technologies, Inc -- Mikrotik & WISP Support Services >> Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs >> -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace >> >> >> >> -----Original Message----- >> From: Darren Pilgrim [mailto:nanog at bitfreak.org] >> Sent: Tuesday, December 18, 2012 9:09 AM >> To: nanog at nanog.org >> Subject: www.eftps.gov contact >> >> The hostname www.eftps.gov has both A and AAAA records, but the site is only reachable via IPv4. Worse, the IPv6 connectivity is broken in such a way that Firefox and Internet Explorer do not fall back to IPv4. >> Tracing is broken for both protocols. The 10-net addresss in the IPv4 path were cute. >> >> Calling their technical support was an exercise in futility. Supposedly they forwarded messages on to the right people; but the site is still broken after over a week's wait. If someone knows the admins behind the EFTPS website and can forward this to them, the accounting firm for which I work would appreciate it. >> >> Thanks, >> >> From morrowc.lists at gmail.com Tue Dec 18 15:36:55 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Dec 2012 10:36:55 -0500 Subject: www.eftps.gov contact In-Reply-To: References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> Message-ID: On Tue, Dec 18, 2012 at 10:35 AM, Christopher Morrow wrote: > On Tue, Dec 18, 2012 at 10:33 AM, Christopher Morrow > wrote: >> if only some us-gov folks read this mailing list... >> maybe someone form NIST could aim the right question to the right >> eftps.gov people? >> you'd think helping the taxman would be appreciated. >> > > it's probably also fair to point out that ... it seems to be working. > (AAAA and A) and traceroute/traceroute6 seems to work to the prem... 6 cr1.attga.ip.att.net (12.122.1.173) 79.126 ms 71.722 ms 74.646 ms 7 cr2.dlstx.ip.att.net (12.122.28.174) 74.001 ms 74.127 ms 74.198 ms 8 cr1.dlstx.ip.att.net (12.122.1.209) 75.261 ms 75.305 ms 75.405 ms 9 cr1.phmaz.ip.att.net (12.122.28.182) 73.070 ms 73.381 ms 73.408 ms 10 12.123.206.173 (12.123.206.173) 71.586 ms 70.289 ms 70.048 ms 11 12.87.83.6 (12.87.83.6) 71.226 ms 71.290 ms 71.526 ms 12 * * * 6 2600:803:95f::d (2600:803:95f::d) 4.618 ms 4.951 ms * 7 2600:805:51f::12 (2600:805:51f::12) 49.616 ms 49.726 ms 49.672 ms 8 2600:805:51f::12 (2600:805:51f::12) 48.548 ms 48.561 ms 48.75 ms 9 2620:10f:400e:1::6 (2620:10f:400e:1::6) 50 ms 53.366 ms 50.704 ms 10 * * * so, what's broken? >> On Tue, Dec 18, 2012 at 10:26 AM, Dennis Burgess >> wrote: >>> I tried to this a month ago, no luck :( i.e. nothing back from them, just goes into no answer e-mail space! >>> >>> Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" >>> Link Technologies, Inc -- Mikrotik & WISP Support Services >>> Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs >>> -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace >>> >>> >>> >>> -----Original Message----- >>> From: Darren Pilgrim [mailto:nanog at bitfreak.org] >>> Sent: Tuesday, December 18, 2012 9:09 AM >>> To: nanog at nanog.org >>> Subject: www.eftps.gov contact >>> >>> The hostname www.eftps.gov has both A and AAAA records, but the site is only reachable via IPv4. Worse, the IPv6 connectivity is broken in such a way that Firefox and Internet Explorer do not fall back to IPv4. >>> Tracing is broken for both protocols. The 10-net addresss in the IPv4 path were cute. >>> >>> Calling their technical support was an exercise in futility. Supposedly they forwarded messages on to the right people; but the site is still broken after over a week's wait. If someone knows the admins behind the EFTPS website and can forward this to them, the accounting firm for which I work would appreciate it. >>> >>> Thanks, >>> >>> From nanog at bitfreak.org Tue Dec 18 15:49:21 2012 From: nanog at bitfreak.org (Darren Pilgrim) Date: Tue, 18 Dec 2012 07:49:21 -0800 Subject: www.eftps.gov contact In-Reply-To: References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> Message-ID: <50D09081.7040809@bitfreak.org> On 2012-12-18 07:36, Christopher Morrow wrote: > On Tue, Dec 18, 2012 at 10:35 AM, Christopher Morrow >> it's probably also fair to point out that ... it seems to be working. >> (AAAA and A) > > so, what's broken? The end-user machines I tested on are behind 6in4 tunnels (MTU 1480). They open the TCP connection, but never load a page. They don't complete the HTTPS SSL handshake. On port 80, they send the HTTP request, but never get a response to GET /. From arturo.servin at gmail.com Tue Dec 18 15:51:09 2012 From: arturo.servin at gmail.com (Arturo Servin) Date: Tue, 18 Dec 2012 13:51:09 -0200 Subject: www.eftps.gov contact In-Reply-To: References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> Message-ID: <50D090ED.6010406@gmail.com> It works for me (http) Cannot ping, so maybe they filtered the whole ICMPv6 and you have a MTU problem. But that is only a guessing. as On 18/12/2012 13:36, Christopher Morrow wrote: > On Tue, Dec 18, 2012 at 10:35 AM, Christopher Morrow > wrote: >> On Tue, Dec 18, 2012 at 10:33 AM, Christopher Morrow >> wrote: >>> if only some us-gov folks read this mailing list... >>> maybe someone form NIST could aim the right question to the right >>> eftps.gov people? >>> you'd think helping the taxman would be appreciated. >>> >> >> it's probably also fair to point out that ... it seems to be working. >> (AAAA and A) > > and traceroute/traceroute6 seems to work to the prem... > > 6 cr1.attga.ip.att.net (12.122.1.173) 79.126 ms 71.722 ms 74.646 ms > 7 cr2.dlstx.ip.att.net (12.122.28.174) 74.001 ms 74.127 ms 74.198 ms > 8 cr1.dlstx.ip.att.net (12.122.1.209) 75.261 ms 75.305 ms 75.405 ms > 9 cr1.phmaz.ip.att.net (12.122.28.182) 73.070 ms 73.381 ms 73.408 ms > 10 12.123.206.173 (12.123.206.173) 71.586 ms 70.289 ms 70.048 ms > 11 12.87.83.6 (12.87.83.6) 71.226 ms 71.290 ms 71.526 ms > 12 * * * > > 6 2600:803:95f::d (2600:803:95f::d) 4.618 ms 4.951 ms * > 7 2600:805:51f::12 (2600:805:51f::12) 49.616 ms 49.726 ms 49.672 ms > 8 2600:805:51f::12 (2600:805:51f::12) 48.548 ms 48.561 ms 48.75 ms > 9 2620:10f:400e:1::6 (2620:10f:400e:1::6) 50 ms 53.366 ms 50.704 ms > 10 * * * > > so, what's broken? > >>> On Tue, Dec 18, 2012 at 10:26 AM, Dennis Burgess >>> wrote: >>>> I tried to this a month ago, no luck :( i.e. nothing back from them, just goes into no answer e-mail space! >>>> >>>> Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" >>>> Link Technologies, Inc -- Mikrotik & WISP Support Services >>>> Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs >>>> -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 3G - 3.65 - TV Whitespace >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Darren Pilgrim [mailto:nanog at bitfreak.org] >>>> Sent: Tuesday, December 18, 2012 9:09 AM >>>> To: nanog at nanog.org >>>> Subject: www.eftps.gov contact >>>> >>>> The hostname www.eftps.gov has both A and AAAA records, but the site is only reachable via IPv4. Worse, the IPv6 connectivity is broken in such a way that Firefox and Internet Explorer do not fall back to IPv4. >>>> Tracing is broken for both protocols. The 10-net addresss in the IPv4 path were cute. >>>> >>>> Calling their technical support was an exercise in futility. Supposedly they forwarded messages on to the right people; but the site is still broken after over a week's wait. If someone knows the admins behind the EFTPS website and can forward this to them, the accounting firm for which I work would appreciate it. >>>> >>>> Thanks, >>>> >>>> From morrowc.lists at gmail.com Tue Dec 18 15:52:27 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Dec 2012 10:52:27 -0500 Subject: www.eftps.gov contact In-Reply-To: <50D09081.7040809@bitfreak.org> References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> <50D09081.7040809@bitfreak.org> Message-ID: On Tue, Dec 18, 2012 at 10:49 AM, Darren Pilgrim wrote: > On 2012-12-18 07:36, Christopher Morrow wrote: >> >> On Tue, Dec 18, 2012 at 10:35 AM, Christopher Morrow >> >>> it's probably also fair to point out that ... it seems to be working. >>> (AAAA and A) >> >> >> so, what's broken? > > > The end-user machines I tested on are behind 6in4 tunnels (MTU 1480). They > open the TCP connection, but never load a page. They don't complete the > HTTPS SSL handshake. On port 80, they send the HTTP request, but never get > a response to GET /. see, now we're getting information that FDC/IRS could actually use! :) This looks like an MTU issue then? From nanog at bitfreak.org Tue Dec 18 16:02:04 2012 From: nanog at bitfreak.org (Darren Pilgrim) Date: Tue, 18 Dec 2012 08:02:04 -0800 Subject: www.eftps.gov contact In-Reply-To: References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> <50D09081.7040809@bitfreak.org> Message-ID: <50D0937C.7010702@bitfreak.org> On 2012-12-18 07:52, Christopher Morrow wrote: > see, now we're getting information that FDC/IRS could actually use! > :) This looks like an MTU issue then? I believe so. From morrowc.lists at gmail.com Tue Dec 18 16:08:23 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Dec 2012 11:08:23 -0500 Subject: www.eftps.gov contact In-Reply-To: <50D0937C.7010702@bitfreak.org> References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> <50D09081.7040809@bitfreak.org> <50D0937C.7010702@bitfreak.org> Message-ID: On Tue, Dec 18, 2012 at 11:02 AM, Darren Pilgrim wrote: > On 2012-12-18 07:52, Christopher Morrow wrote: >> >> see, now we're getting information that FDC/IRS could actually use! >> :) This looks like an MTU issue then? > > > I believe so. so, a suggestion to eftps.gov/irs/fdc is to simply clamp MSS on their servers, no? From drc at virtualized.org Tue Dec 18 16:15:22 2012 From: drc at virtualized.org (David Conrad) Date: Tue, 18 Dec 2012 08:15:22 -0800 Subject: =?windows-1252?Q?Re=3A_Advisory_=97_D-root_is_changing_its_IPv4_?= =?windows-1252?Q?address_on_the_3rd_of_January=2E?= In-Reply-To: References: <9lnais7c7ei9jielx67hx4be.1355795581892@email.android.com> Message-ID: On Dec 17, 2012, at 11:30 PM, ITechGeek wrote: > For anyone who is worried that the root server change might impact them, > they can go to http://www.iana.org/domains/root/files and download the root > zone file. It probably won't need to be updated again until the next round > of gTLDs is approved. Err, no. The root zone changes twice a day and its contents change quite frequently as TLD managers update their name servers, do key rollovers, etc. If you're going to copy the root zone, I'd recommend using a zone transfer from the name servers described in http://dns.icann.org/services/axfr/ or, at the very least, set up a cron job to pull the root zone twice a day. WRT the root _hints_ change, setting up a cron job to pull, verify, and install the root hints file periodically (once a month should probably be sufficient) would probably be a good idea. Regards, -drc From nanog at bitfreak.org Tue Dec 18 16:15:31 2012 From: nanog at bitfreak.org (Darren Pilgrim) Date: Tue, 18 Dec 2012 08:15:31 -0800 Subject: www.eftps.gov contact In-Reply-To: References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> <50D09081.7040809@bitfreak.org> <50D0937C.7010702@bitfreak.org> Message-ID: <50D096A3.5010706@bitfreak.org> On 2012-12-18 08:08, Christopher Morrow wrote: > On Tue, Dec 18, 2012 at 11:02 AM, Darren Pilgrim wrote: >> On 2012-12-18 07:52, Christopher Morrow wrote: >>> >>> see, now we're getting information that FDC/IRS could actually use! >>> :) This looks like an MTU issue then? >> >> >> I believe so. > > so, a suggestion to eftps.gov/irs/fdc is to simply clamp MSS on their > servers, no? I might instead suggest a read of RFC 4890. :) From morrowc.lists at gmail.com Tue Dec 18 16:31:30 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Dec 2012 11:31:30 -0500 Subject: www.eftps.gov contact In-Reply-To: <50D096A3.5010706@bitfreak.org> References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> <50D09081.7040809@bitfreak.org> <50D0937C.7010702@bitfreak.org> <50D096A3.5010706@bitfreak.org> Message-ID: On Tue, Dec 18, 2012 at 11:15 AM, Darren Pilgrim wrote: > 4890 it might not be their (eftps.gov's) fault though... but sure. From jra at baylink.com Tue Dec 18 17:06:07 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 18 Dec 2012 12:06:07 -0500 (EST) Subject: REMINDER: Include as much detail as you have on problem reports (was eftps.gov) Message-ID: <31311564.38787.1355850367104.JavaMail.root@benjamin.baylink.com> Aside from the fact that it helps unrelated people aid you in diagnosing the problem, there's another, more practical reason to do it: When you do, problems you're having will sometimes "magically" disappear, because someone who a) is in a position to fix it, but b) is not in a position to *talk about it* will see the report, do a facepalm, and twist the proper knob to make it go away. While this isn't as optimal in the global sense as a full dialogue on the problem would be, it's a helluva lot better than "it still doesn't work, a week later". And the shorter the thread, the higher the odds this might happen. "One posting" is optimal. :-) Just a thought. Cheers, -- jr 'Happy Chriskwanzukkah, and a Cool Yule' a -- 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 jra at baylink.com Tue Dec 18 17:25:08 2012 From: jra at baylink.com (Jay Ashworth) Date: Tue, 18 Dec 2012 12:25:08 -0500 (EST) Subject: Fiber only in DataCenters? In-Reply-To: Message-ID: <16918853.38795.1355851508167.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "James Wininger" > Are there data centers out there that are "fiber only"? That is to say > that the cross connects are fiber only and no copper cross connects > are available? I have not personally run across any DCs that do not permit copper Xcon, but I am young, and not well-travelled. 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 cjp at 0x1.net Tue Dec 18 17:59:49 2012 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Tue, 18 Dec 2012 12:59:49 -0500 Subject: Simple/best tool to verify PMTUD? Message-ID: <-500116504420455881@unknownmsgid> I'm looking for a simple tool to verify PMTUD is usable along a particular path. Ideally this tool would be cross-platform, or run on Linux or Windows. I've done some testing of my own by hand, but hoping a tool would help the admin on the other side be able to test for themselves. From djahandarie at gmail.com Tue Dec 18 18:09:34 2012 From: djahandarie at gmail.com (Darius Jahandarie) Date: Tue, 18 Dec 2012 13:09:34 -0500 Subject: Simple/best tool to verify PMTUD? In-Reply-To: <-500116504420455881@unknownmsgid> References: <-500116504420455881@unknownmsgid> Message-ID: On Tue, Dec 18, 2012 at 12:59 PM, Christopher J. Pilkington wrote: > I'm looking for a simple tool to verify PMTUD is usable along a > particular path. Ideally this tool would be cross-platform, or run on > Linux or Windows. tracepath (Linux), mturoute (Windows) -- Darius Jahandarie From marka at isc.org Tue Dec 18 20:19:22 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 19 Dec 2012 07:19:22 +1100 Subject: www.eftps.gov contact In-Reply-To: Your message of "Tue, 18 Dec 2012 11:31:30 CDT." References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> <50D09081.7040809@bitfreak.org> <50D0937C.7010702@bitfreak.org> <50D096A3.5010706@bitfreak.org> Message-ID: <20121218201922.5A6792D2F02E@drugs.dv.isc.org> In message , Christopher Morrow writes: > On Tue, Dec 18, 2012 at 11:15 AM, Darren Pilgrim wrote: > > 4890 > > it might not be their (eftps.gov's) fault though... but sure. If you run a server you should be expecting PTB for both IPv4 and IPv6. If you have broken equipement in front of the server you can set IPV6_USE_MIN_MTU to 1 on IPv6 sockets. There is no excuse to have connections broken due to PMTUD. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From morrowc.lists at gmail.com Tue Dec 18 20:22:09 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Dec 2012 15:22:09 -0500 Subject: www.eftps.gov contact In-Reply-To: <20121218201922.5A6792D2F02E@drugs.dv.isc.org> References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> <50D09081.7040809@bitfreak.org> <50D0937C.7010702@bitfreak.org> <50D096A3.5010706@bitfreak.org> <20121218201922.5A6792D2F02E@drugs.dv.isc.org> Message-ID: On Tue, Dec 18, 2012 at 3:19 PM, Mark Andrews wrote: > > In message , Christopher Morrow > writes: >> On Tue, Dec 18, 2012 at 11:15 AM, Darren Pilgrim wrote: >> > 4890 >> >> it might not be their (eftps.gov's) fault though... but sure. > > If you run a server you should be expecting PTB for both IPv4 and > IPv6. If you have broken equipement in front of the server you can > set IPV6_USE_MIN_MTU to 1 on IPv6 sockets. There is no excuse to > have connections broken due to PMTUD. sure there is! "my isp filters icmp" From marka at isc.org Tue Dec 18 20:25:25 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 19 Dec 2012 07:25:25 +1100 Subject: www.eftps.gov contact In-Reply-To: Your message of "Tue, 18 Dec 2012 15:22:09 CDT." References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> <50D09081.7040809@bitfreak.org> <50D0937C.7010702@bitfreak.org> <50D096A3.5010706@bitfreak.org> <20121218201922.5A6792D2F02E@drugs.dv.isc.org> Message-ID: <20121218202525.409B62D2F146@drugs.dv.isc.org> In message , Christopher Morrow writes: > On Tue, Dec 18, 2012 at 3:19 PM, Mark Andrews wrote: > > > > In message , Christopher Morrow > > writes: > >> On Tue, Dec 18, 2012 at 11:15 AM, Darren Pilgrim wrote: > >> > 4890 > >> > >> it might not be their (eftps.gov's) fault though... but sure. > > > > If you run a server you should be expecting PTB for both IPv4 and > > IPv6. If you have broken equipement in front of the server you can > > set IPV6_USE_MIN_MTU to 1 on IPv6 sockets. There is no excuse to > > have connections broken due to PMTUD. > > sure there is! "my isp filters icmp" You don't have a ISP then. You have a fraudster. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Tue Dec 18 20:35:23 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Dec 2012 12:35:23 -0800 Subject: www.eftps.gov contact In-Reply-To: References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> <50D09081.7040809@bitfreak.org> <50D0937C.7010702@bitfreak.org> <50D096A3.5010706@bitfreak.org> <20121218201922.5A6792D2F02E@drugs.dv.isc.org> Message-ID: <061156C4-4488-4543-B609-B7893F2BFB2E@delong.com> On Dec 18, 2012, at 12:22 , Christopher Morrow wrote: > On Tue, Dec 18, 2012 at 3:19 PM, Mark Andrews wrote: >> >> In message , Christopher Morrow >> writes: >>> On Tue, Dec 18, 2012 at 11:15 AM, Darren Pilgrim wrote: >>>> 4890 >>> >>> it might not be their (eftps.gov's) fault though... but sure. >> >> If you run a server you should be expecting PTB for both IPv4 and >> IPv6. If you have broken equipement in front of the server you can >> set IPV6_USE_MIN_MTU to 1 on IPv6 sockets. There is no excuse to >> have connections broken due to PMTUD. > > sure there is! "my isp filters icmp" Get a better ISP. Owen From morrowc.lists at gmail.com Tue Dec 18 20:37:16 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 18 Dec 2012 15:37:16 -0500 Subject: www.eftps.gov contact In-Reply-To: <061156C4-4488-4543-B609-B7893F2BFB2E@delong.com> References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> <50D09081.7040809@bitfreak.org> <50D0937C.7010702@bitfreak.org> <50D096A3.5010706@bitfreak.org> <20121218201922.5A6792D2F02E@drugs.dv.isc.org> <061156C4-4488-4543-B609-B7893F2BFB2E@delong.com> Message-ID: On Tue, Dec 18, 2012 at 3:35 PM, Owen DeLong wrote: > > On Dec 18, 2012, at 12:22 , Christopher Morrow wrote: > >> On Tue, Dec 18, 2012 at 3:19 PM, Mark Andrews wrote: >>> >>> In message , Christopher Morrow >>> writes: >>>> On Tue, Dec 18, 2012 at 11:15 AM, Darren Pilgrim wrote: >>>>> 4890 >>>> >>>> it might not be their (eftps.gov's) fault though... but sure. >>> >>> If you run a server you should be expecting PTB for both IPv4 and >>> IPv6. If you have broken equipement in front of the server you can >>> set IPV6_USE_MIN_MTU to 1 on IPv6 sockets. There is no excuse to >>> have connections broken due to PMTUD. >> >> sure there is! "my isp filters icmp" > > Get a better ISP. both of you crack me up. From marka at isc.org Tue Dec 18 20:51:17 2012 From: marka at isc.org (Mark Andrews) Date: Wed, 19 Dec 2012 07:51:17 +1100 Subject: www.eftps.gov contact In-Reply-To: Your message of "Tue, 18 Dec 2012 15:37:16 CDT." References: <50D08721.7090002@bitfreak.org> <50710E9A7E64454C974049FC998EB655749E11@03-exchange.lti.local> <50D09081.7040809@bitfreak.org> <50D0937C.7010702@bitfreak.org> <50D096A3.5010706@bitfreak.org> <20121218201922.5A6792D2F02E@drugs.dv.isc.org> <061156C4-4488-4543-B609-B7893F2BFB2E@delong.com> Message-ID: <20121218205117.EFB092D2F350@drugs.dv.isc.org> In message , Christopher Morrow writes: > On Tue, Dec 18, 2012 at 3:35 PM, Owen DeLong wrote: > > > > On Dec 18, 2012, at 12:22 , Christopher Morrow wrote: > > > >> On Tue, Dec 18, 2012 at 3:19 PM, Mark Andrews wrote: > >>> > >>> In message , Christopher Morrow > >>> writes: > >>>> On Tue, Dec 18, 2012 at 11:15 AM, Darren Pilgrim wrote: > >>>>> 4890 > >>>> > >>>> it might not be their (eftps.gov's) fault though... but sure. > >>> > >>> If you run a server you should be expecting PTB for both IPv4 and > >>> IPv6. If you have broken equipement in front of the server you can > >>> set IPV6_USE_MIN_MTU to 1 on IPv6 sockets. There is no excuse to > >>> have connections broken due to PMTUD. > >> > >> sure there is! "my isp filters icmp" > > > > Get a better ISP. > > both of you crack me up. Setting IPV6_USE_MIN_MTU on a IPv6 socket is a couple of lines of code in the http server. Been there, done that. If you can't do that then set the interface MTU to 1280. I repeat there is no excuse to have connection broken due to PMTU issues. A compentent sys admin can work around upstream problems. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From kemp at network-services.uoregon.edu Tue Dec 18 22:24:58 2012 From: kemp at network-services.uoregon.edu (John Kemp) Date: Tue, 18 Dec 2012 14:24:58 -0800 Subject: 32-bit ASes at routeviews In-Reply-To: References: Message-ID: <50D0ED3A.8040703@network-services.uoregon.edu> On 12/16/12 2:48 PM, Iljitsch van Beijnum wrote: > Looking for 32-bit AS numbers, I get some strange results from routeviews: > > route-views>sh ip bgp regexp _23456_ > BGP table version is 2393809200, local router ID is 128.223.51.103 > Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, > r RIB-failure, S Stale > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path > * 31.177.16.0/22 128.223.253.10 0 3582 3701 3356 23456 3.1043 i > * 46.29.72.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i > * 46.243.96.0/21 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i > * 91.208.62.0/24 154.11.11.113 0 0 852 174 39704 39704 23456 3.787 i > * 91.217.87.0/24 194.85.40.15 0 3267 174 23456 3.661 i > * 91.230.169.0/24 208.51.134.254 13905 0 3549 29152 29152 29152 29152 23456 23456 23456 23456 3.1426 i > * 91.238.8.0/24 194.85.40.15 0 3267 8220 23456 3.2040 i > * 111.235.148.0/22 194.85.40.15 0 3267 9498 9730 23456 i > * 141.0.176.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i > > Unless I missed something, AS 23456 is supposed to show up as a stand-in for 32-bit ASNs on 16-bit BGP implementations, not in _addition_ to 32-bit ASNs. So the penultimate line would make sense if the other lines weren't there and the others don't make sense period. > > Maybe a bug in the IOS they're running? > > route-views>sh ver > Cisco IOS Software, 7200 Software (C7200P-ADVENTERPRISEK9-M), Version 12.4(24)T2, RELEASE SOFTWARE (fc2) > > Or is something else going on? Off topic, this reminds me I would rather have ASPLAIN again. We switched a couple of years ago on a particular user request. If there is no objection, I would love to switch back ASAP. This would be on route-views, and on route-views3. Just asking if others concur? -- John Kemp (kemp at routeviews.org) RouteViews Engineer NOC: noc at routeviews.org MAIL: help at routeviews.org WWW: http://www.routeviews.org From nick at foobar.org Tue Dec 18 23:17:16 2012 From: nick at foobar.org (Nick Hilliard) Date: Tue, 18 Dec 2012 23:17:16 +0000 Subject: 32-bit ASes at routeviews In-Reply-To: <50D0ED3A.8040703@network-services.uoregon.edu> References: <50D0ED3A.8040703@network-services.uoregon.edu> Message-ID: <50D0F97C.5090108@foobar.org> On 18/12/2012 22:24, John Kemp wrote: > If there is no objection, I would love to switch back > ASAP. This would be on route-views, and on route-views3. > Just asking if others concur? rfc5396. I'd say go for it. Nick From d.nostra at gmail.com Wed Dec 19 00:46:12 2012 From: d.nostra at gmail.com (Michel de Nostredame) Date: Tue, 18 Dec 2012 16:46:12 -0800 Subject: Fiber only in DataCenters? In-Reply-To: <16918853.38795.1355851508167.JavaMail.root@benjamin.baylink.com> References: <16918853.38795.1355851508167.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Dec 18, 2012 at 9:25 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "James Wininger" > >> Are there data centers out there that are "fiber only"? That is to say >> that the cross connects are fiber only and no copper cross connects >> are available? > > I have not personally run across any DCs that do not permit copper Xcon, > but I am young, and not well-travelled. I believe all datacenter allow copper cross connections but maybe not actually provisioned by copper. Most of my copper cross connections are actually provisioned by in-house fibers plus FOT on both end. Hence the hand-off looks like copper. -- Michel~ From randy at psg.com Wed Dec 19 02:23:03 2012 From: randy at psg.com (Randy Bush) Date: Tue, 18 Dec 2012 21:23:03 -0500 Subject: 32-bit ASes at routeviews In-Reply-To: <50D0ED3A.8040703@network-services.uoregon.edu> References: <50D0ED3A.8040703@network-services.uoregon.edu> Message-ID: > Off topic, this reminds me I would rather have ASPLAIN > again. We switched a couple of years ago on a particular > user request. listening to those pesky users, eh? > If there is no objection, I would love to switch back > ASAP. This would be on route-views, and on route-views3. > Just asking if others concur? makes sense to me randy From ttauber at 1-4-5.net Wed Dec 19 03:28:15 2012 From: ttauber at 1-4-5.net (Tony Tauber) Date: Tue, 18 Dec 2012 22:28:15 -0500 Subject: 32-bit ASes at routeviews In-Reply-To: References: <50D0ED3A.8040703@network-services.uoregon.edu> Message-ID: +1 On Tue, Dec 18, 2012 at 9:23 PM, Randy Bush wrote: > > Off topic, this reminds me I would rather have ASPLAIN > > again. We switched a couple of years ago on a particular > > user request. > > listening to those pesky users, eh? > > > If there is no objection, I would love to switch back > > ASAP. This would be on route-views, and on route-views3. > > Just asking if others concur? > > makes sense to me > > randy > > From cjc+nanog at pumpky.net Wed Dec 19 06:28:12 2012 From: cjc+nanog at pumpky.net (Crist Clark) Date: Tue, 18 Dec 2012 22:28:12 -0800 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: Infoblox just started offering the IPAM portion of their software for free, http://www.infoblox.com/en/resources/software-downloads/ip-address-management-freeware.html We've been using the full-blown commercial appliances (IPAM, DHCP, and DNS), not the freeware. I don't know exactly how it works without the other pieces integrated, but it may be worth a look. From job at instituut.net Wed Dec 19 09:37:30 2012 From: job at instituut.net (Job Snijders) Date: Wed, 19 Dec 2012 11:37:30 +0200 Subject: Simple/best tool to verify PMTUD? In-Reply-To: <-500116504420455881@unknownmsgid> References: <-500116504420455881@unknownmsgid> Message-ID: <741C38E8-9616-4980-9541-4D7FA952B453@instituut.net> Hi, On Dec 18, 2012, at 7:59 PM, Christopher J. Pilkington wrote: > I'm looking for a simple tool to verify PMTUD is usable along a > particular path. Ideally this tool would be cross-platform, or run on > Linux or Windows. > > I've done some testing of my own by hand, but hoping a tool would help > the admin on the other side be able to test for themselves. Scamper is a really cool tool, look at this example: job at Alice:~$ sudo scamper -c 'trace -P UDP-paris -M' -i 8.8.4.4 2001:67c:208c:10::1 traceroute from 2a02:d28:666::69 to 2001:67c:208c:10::1 1 2a02:d28:666::1 0.247 ms [mtu: 1500] 2 2a02:d28:5580:666::a 1.085 ms [mtu: 1500] 3 2a02:d28:5580:1::31 7.141 ms [mtu: 1500] 4 2a02:d28:5580:1::21 6.588 ms [mtu: 1500] 5 2a02:d28:5580::1:411 6.815 ms [mtu: 1500] 6 2001:7f8:1::a501:2414:2 7.612 ms [mtu: 1500] 7 2001:9e0:0:2::2 9.793 ms [mtu: 1500] 8 2001:9e0:0:3::2 8.277 ms [mtu: 1500] 9 2001:9e0:0:9::2 8.851 ms [mtu: 1500] 10 2001:9e0:411:1::10 9.015 ms [mtu: 1500] 11 2001:67c:208c:10::1 20.220 ms [mtu: 1464] traceroute from 78.152.42.69 to 8.8.4.4 1 78.152.42.65 0.230 ms [mtu: 1500] 2 78.152.42.1 0.253 ms [mtu: 1500] 3 78.152.44.89 6.693 ms [mtu: 1500] 4 78.152.34.14 6.906 ms [mtu: 1500] 5 78.152.44.95 6.705 ms [mtu: 1500] 6 195.69.144.247 7.207 ms [mtu: 1500] 7 209.85.248.116 7.183 ms [mtu: 1500] 8 209.85.255.60 7.416 ms [mtu: 1500] 9 216.239.49.28 12.922 ms [mtu: 1500] 10 * 11 8.8.4.4 10.481 ms [mtu: 1500] job at Alice:~$ Kind regards, Job From dot at dotat.at Wed Dec 19 14:25:33 2012 From: dot at dotat.at (Tony Finch) Date: Wed, 19 Dec 2012 14:25:33 +0000 Subject: btw, the itu imploded In-Reply-To: <375240A1-3D24-4563-AD1E-E324356AE371@pch.net> References: <20121214195137.GA83702@mikea.ath.cx> <375240A1-3D24-4563-AD1E-E324356AE371@pch.net> Message-ID: Bill Woodcock wrote: > > The main unfortunate outcome is that the ITU has managed to get Study > Group 3 approved to try to figure out how to override peering agreements > with government-imposed settlements. Do you have any citations for that? I thought they had given up on trying to interfere with Internet peering and settlement. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From jason at lixfeld.ca Wed Dec 19 14:53:26 2012 From: jason at lixfeld.ca (Jason Lixfeld) Date: Wed, 19 Dec 2012 09:53:26 -0500 Subject: Validation of FCS Message-ID: <4D53609B-8772-4B93-A75E-294AD7DB3DF1@lixfeld.ca> Hi all, I'm trying to confirm (or debunk) my current understanding of FCS errors. An FCS error is a layer 2 error. In Ethernet spake, the 4 bytes of FCS data within each Ethernet frame is validated by a CRC check, which is done by the device receiving said frame. If the CRC check fails, an FCS error is reported by that receiving device. If that understanding is true and presuming a "circuit" was made up of many layer 2 devices between the A and Z side of said circuit, it would be impossible for a CRC error somewhere along the path of that circuit to register on the receiving device of either the A or Z side. Perhaps in simpler terms, a CRC error is a localized thing and would never be forwarded from one device to another. Is that fair and/or accurate? Thanks in advance. From saku at ytti.fi Wed Dec 19 15:02:12 2012 From: saku at ytti.fi (Saku Ytti) Date: Wed, 19 Dec 2012 17:02:12 +0200 Subject: Validation of FCS In-Reply-To: <4D53609B-8772-4B93-A75E-294AD7DB3DF1@lixfeld.ca> References: <4D53609B-8772-4B93-A75E-294AD7DB3DF1@lixfeld.ca> Message-ID: <20121219150212.GA11882@pob.ytti.fi> On (2012-12-19 09:53 -0500), Jason Lixfeld wrote: > Perhaps in simpler terms, a CRC error is a localized thing and would > never be forwarded from one device to another. It would be forwarded in cut-through switching. -- ++ytti From jason at lixfeld.ca Wed Dec 19 15:11:04 2012 From: jason at lixfeld.ca (Jason Lixfeld) Date: Wed, 19 Dec 2012 10:11:04 -0500 Subject: Validation of FCS In-Reply-To: <20121219150212.GA11882@pob.ytti.fi> References: <4D53609B-8772-4B93-A75E-294AD7DB3DF1@lixfeld.ca> <20121219150212.GA11882@pob.ytti.fi> Message-ID: On 2012-12-19, at 10:02 AM, Saku Ytti wrote: > On (2012-12-19 09:53 -0500), Jason Lixfeld wrote: > >> Perhaps in simpler terms, a CRC error is a localized thing and would >> never be forwarded from one device to another. > > It would be forwarded in cut-through switching. ... until the bad frame reached the first store-and-forward switch (or most any router) which would log the FCS error, correct? From nick at foobar.org Wed Dec 19 15:12:03 2012 From: nick at foobar.org (Nick Hilliard) Date: Wed, 19 Dec 2012 15:12:03 +0000 Subject: btw, the itu imploded In-Reply-To: References: <20121214195137.GA83702@mikea.ath.cx> <375240A1-3D24-4563-AD1E-E324356AE371@pch.net> Message-ID: <50D1D943.2090408@foobar.org> On 19/12/2012 14:25, Tony Finch wrote: > Do you have any citations for that? I thought they had given up on trying > to interfere with Internet peering and settlement. http://www.itu.int/net/ITU-T/lists/questions.aspx?Group=03&Period=15 ETNO is very keen on introducing sending-party-pays, and recently brought out an opinion piece on their intentions to bring this idea forward at the ITU: http://www.etno.eu/datas/itu-matters/etno-ip-interconnection.pdf > ETNO has introduced its views in Contribution C 109 submitted to the > last meeting of the ITU Council Working Group to prepare for 2012 WCIT. > ETNO?s proposal concerns: [...] > ? the economic background, advocating for an adequate return on > investment based, where appropriate, on the principle of sending party > network pays; The Body of European Regulators for Electronic Communications (i.e. the representative body of all the EU national comms regulators) came out with the following statement: > http://berec.europa.eu/files/document_register_store/2012/11/BoR(12)120rev.1_BEREC_Statement_on_ITR_2012.11.14.pdf ... where they noted among other things: "ETNO?s proposed end-to-end SPNP approach to data transmission is totally antagonistic to the decentralised efficient routing approach to data transmission of the Internet." It's pretty unusual to get language this strong from a regulatory body. Nick From dot at dotat.at Wed Dec 19 15:17:23 2012 From: dot at dotat.at (Tony Finch) Date: Wed, 19 Dec 2012 15:17:23 +0000 Subject: btw, the itu imploded In-Reply-To: <50D1D943.2090408@foobar.org> References: <20121214195137.GA83702@mikea.ath.cx> <375240A1-3D24-4563-AD1E-E324356AE371@pch.net> <50D1D943.2090408@foobar.org> Message-ID: Nick Hilliard wrote: > On 19/12/2012 14:25, Tony Finch wrote: > > > > Do you have any citations for that? I thought they had given up on trying > > to interfere with Internet peering and settlement. > > http://www.itu.int/net/ITU-T/lists/questions.aspx?Group=03&Period=15 Looks vaguely ominous. Do they have a document which gives their definition of "international telecommunications services" and "NGNs"? Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From nick at foobar.org Wed Dec 19 15:18:54 2012 From: nick at foobar.org (Nick Hilliard) Date: Wed, 19 Dec 2012 15:18:54 +0000 Subject: btw, the itu imploded In-Reply-To: References: <20121214195137.GA83702@mikea.ath.cx> <375240A1-3D24-4563-AD1E-E324356AE371@pch.net> <50D1D943.2090408@foobar.org> Message-ID: <50D1DADE.900@foobar.org> On 19/12/2012 15:17, Tony Finch wrote: > Nick Hilliard wrote: >> On 19/12/2012 14:25, Tony Finch wrote: >>> >>> Do you have any citations for that? I thought they had given up on trying >>> to interfere with Internet peering and settlement. >> >> http://www.itu.int/net/ITU-T/lists/questions.aspx?Group=03&Period=15 > > Looks vaguely ominous. Do they have a document which gives their > definition of "international telecommunications services" and "NGNs"? dunno - they look intentionally vague to me. Nick From saku at ytti.fi Wed Dec 19 15:55:36 2012 From: saku at ytti.fi (Saku Ytti) Date: Wed, 19 Dec 2012 17:55:36 +0200 Subject: Validation of FCS In-Reply-To: References: <4D53609B-8772-4B93-A75E-294AD7DB3DF1@lixfeld.ca> <20121219150212.GA11882@pob.ytti.fi> Message-ID: <20121219155536.GA11900@pob.ytti.fi> > ... until the bad frame reached the first store-and-forward switch (or most any router) which would log the FCS error, correct? Log and drop yes. cut-through would log it also, but it would be too late to drop it. -- ++ytti From blake at pfankuch.me Wed Dec 19 19:35:42 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Wed, 19 Dec 2012 19:35:42 +0000 Subject: Check Point Firewall Appliances Message-ID: Howdy, I am just getting into an environment with a large Check Point deployment and I am looking for a little bit of feedback from other real world admins. Looking for what people like, what people don't (why hopefully). Also for those of you who might run Check Point devices in your environments what to dig into first as far as getting more experience on the devices and a better understanding of how not to break them. I am slowly going through all of the official documentation, but would also like to hear a real world opinion. Thanks in advance! Blake From darden at armc.org Wed Dec 19 19:52:56 2012 From: darden at armc.org (Darden, Patrick S.) Date: Wed, 19 Dec 2012 14:52:56 -0500 Subject: Check Point Firewall Appliances In-Reply-To: References: Message-ID: Watch out for licensing gotchyas. In active/active ClusterXL situations (load sharing multicast mode) be careful of multicast--make sure any traversed switches and routers are compatible with Ethernet Multicast (make sure they don't partition ports due to high broadcast traffic). Active/Active clustering can also make troubleshooting a pain--which unit has state for which flow, etc.. Also, minimize lag time between State Synchronization nodes or suffer myriad hard to isolate problems. I advise you to minimize the number of cluster nodes per vlan or you will effectively DOS your attached network--think broadcast storms. If you use unicast active/active clusterxl, you can run into pivot problems. They are great firewalls, but like all systems they have their "opportunities." --Patrick Darden -----Original Message----- From: Blake Pfankuch [mailto:blake at pfankuch.me] Sent: Wednesday, December 19, 2012 2:36 PM To: NANOG (nanog at nanog.org) Subject: Check Point Firewall Appliances Howdy, I am just getting into an environment with a large Check Point deployment and I am looking for a little bit of feedback from other real world admins. Looking for what people like, what people don't (why hopefully). Also for those of you who might run Check Point devices in your environments what to dig into first as far as getting more experience on the devices and a better understanding of how not to break them. I am slowly going through all of the official documentation, but would also like to hear a real world opinion. Thanks in advance! Blake From joquendo at e-fensive.net Wed Dec 19 19:56:24 2012 From: joquendo at e-fensive.net (J. Oquendo) Date: Wed, 19 Dec 2012 13:56:24 -0600 Subject: Google contact Message-ID: <20121219195623.GA17139@e-fensive.net> Can someone from GOOG contact me off-list. After many submissions to have my corp IP space fixed for geolocation, I'm at wits end looking at British news, finding British searches, knowing more about the UK then the US than I care to. Makes for difficult GHDB'ing when searching as well. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF From tom.taylor.stds at gmail.com Wed Dec 19 20:14:04 2012 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Wed, 19 Dec 2012 15:14:04 -0500 Subject: btw, the itu imploded In-Reply-To: References: <20121214195137.GA83702@mikea.ath.cx> <375240A1-3D24-4563-AD1E-E324356AE371@pch.net> Message-ID: <50D2200C.7050000@gmail.com> You can look at the final outcome yourself (no password needed), at http://www.itu.int/en/wcit-12/Documents/final-acts-wcit-12.pdf RESOLUTION PLEN/5 on page 27 (by PDF count, out of 30 pages) describes work to be done by Study Group 3 and cooperating members. Note that the resolution is not part of the preceding treaty text. On 19/12/2012 9:25 AM, Tony Finch wrote: > Bill Woodcock wrote: >> >> The main unfortunate outcome is that the ITU has managed to get Study >> Group 3 approved to try to figure out how to override peering agreements >> with government-imposed settlements. > > Do you have any citations for that? I thought they had given up on trying > to interfere with Internet peering and settlement. > > Tony. > From mehmet at akcin.net Wed Dec 19 20:14:50 2012 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 20 Dec 2012 06:14:50 +1000 Subject: Simple/best tool to verify PMTUD? In-Reply-To: <-500116504420455881@unknownmsgid> References: <-500116504420455881@unknownmsgid> Message-ID: <39A50908-A0E6-434D-A245-A75B5A6B9E33@akcin.net> On Dec 19, 2012, at 3:59 AM, Christopher J. Pilkington wrote: > I'm looking for a simple tool to verify PMTUD is usable along a > particular path. Ideally this tool would be cross-platform, or run on > Linux or Windows. > > I've done some testing of my own by hand, but hoping a tool would help > the admin on the other side be able to test for themselves. > tracepath rocks. mehmet From joquendo at e-fensive.net Wed Dec 19 20:10:39 2012 From: joquendo at e-fensive.net (J. Oquendo) Date: Wed, 19 Dec 2012 14:10:39 -0600 Subject: Google contact In-Reply-To: <20121219195623.GA17139@e-fensive.net> References: <20121219195623.GA17139@e-fensive.net> Message-ID: <20121219201039.GC17139@e-fensive.net> On Wed, 19 Dec 2012, J. Oquendo wrote: > > Can someone from GOOG contact me off-list. After many > submissions to have my corp IP space fixed for geolocation, > I'm at wits end looking at British news, finding British > searches, knowing more about the UK then the US than I care > to. Makes for difficult GHDB'ing when searching as well. Odd responding to my own message. Yes, Maxmind, Neustar and everyone else I can think of sees my space just fine minus Google. (Before someone wastes time telling me to go there) =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF From joe.freeman at Terenine.com Wed Dec 19 18:46:16 2012 From: joe.freeman at Terenine.com (Joe Freeman) Date: Wed, 19 Dec 2012 13:46:16 -0500 Subject: Need a Yahoo network contact Message-ID: <225F609B48882B4D94C1E5D262814D7F02BE588C559D@STRATUSMBX02.Terenine.com> I need a Yahoo contact if anyone is available. I'm having issues with customers on 186.65.92.0/22 (ASN52379) out of Costa Rica being able to reach Yahoo sites (www.yahoo.com/www.flickr.com) with their web browsers, but they can ping them just fine. Thanks- joe ________________________________ This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From job at instituut.net Wed Dec 19 22:39:39 2012 From: job at instituut.net (Job Snijders) Date: Thu, 20 Dec 2012 00:39:39 +0200 Subject: Need a Yahoo network contact In-Reply-To: <225F609B48882B4D94C1E5D262814D7F02BE588C559D@STRATUSMBX02.Terenine.com> References: <225F609B48882B4D94C1E5D262814D7F02BE588C559D@STRATUSMBX02.Terenine.com> Message-ID: On Dec 19, 2012, at 8:46 PM, Joe Freeman wrote: > I need a Yahoo contact if anyone is available. > I'm having issues with customers on 186.65.92.0/22 (ASN52379) out of Costa Rica being able to reach Yahoo sites (www.yahoo.com/www.flickr.com) with their web browsers, but they can ping them just fine. Sounds like MTU is borked up somewhere. Do you have the same issue with http://www.msn.com/ ? Kind regards, Job From joe.freeman at Terenine.com Wed Dec 19 22:41:28 2012 From: joe.freeman at Terenine.com (Joe Freeman) Date: Wed, 19 Dec 2012 17:41:28 -0500 Subject: Need a Yahoo network contact In-Reply-To: References: <225F609B48882B4D94C1E5D262814D7F02BE588C559D@STRATUSMBX02.Terenine.com> Message-ID: <225F609B48882B4D94C1E5D262814D7F02BE588C5680@STRATUSMBX02.Terenine.com> I'll have to check tonight when I get my next window to play with it. -----Original Message----- From: Job Snijders [mailto:job at instituut.net] Sent: Wednesday, December 19, 2012 5:40 PM To: Joe Freeman Cc: nanog at nanog.org Subject: Re: Need a Yahoo network contact On Dec 19, 2012, at 8:46 PM, Joe Freeman wrote: > I need a Yahoo contact if anyone is available. > I'm having issues with customers on 186.65.92.0/22 (ASN52379) out of Costa Rica being able to reach Yahoo sites (www.yahoo.com/www.flickr.com) with their web browsers, but they can ping them just fine. Sounds like MTU is borked up somewhere. Do you have the same issue with http://www.msn.com/ ? Kind regards, Job From pfunix at gmail.com Thu Dec 20 03:09:40 2012 From: pfunix at gmail.com (Beavis) Date: Wed, 19 Dec 2012 21:09:40 -0600 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: +1 for ipplan http://iptrack.sourceforge.net/ -Ed On Thu, Dec 13, 2012 at 4:10 AM, Aftab Siddiqui wrote: > Kindly search the archives for many threads on the same subject, which > should be the normal practice. > > nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The > first one I assume should serve your purpose for both v4 and v6. > > Regards, > > Aftab A. Siddiqui > > > > On Thu, Dec 13, 2012 at 6:22 AM, Eric A Louie wrote: > >> I'm looking for IPAM solutions for a small regional wireless ISP. There >> are 4 >> Tier 2 personnel and 2 NOC technicians who would be using the tool, and a >> small >> staff of engineers. >> >> They have regionalized IP addresses so blocks are local, but there are >> subnets >> that are global. >> >> don't care if it's a linux or windows solution. >> >> Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) >> >> We're not dealing with a lot now, but the potential for growth is pretty >> high. >> >> What are you using and how is it working for you? >> >> Much appreciated, Eric >> -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/ From blake at pfankuch.me Thu Dec 20 03:24:00 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Thu, 20 Dec 2012 03:24:00 +0000 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: I actually was doing research on this today as well. Anyone have any experience with the solutions that implement VLAN management as well like Gestioip? -----Original Message----- From: Beavis [mailto:pfunix at gmail.com] Sent: Wednesday, December 19, 2012 8:10 PM To: Aftab Siddiqui Cc: NANOG Operators' Group Subject: Re: IP Address Management IPAM software for small ISP +1 for ipplan http://iptrack.sourceforge.net/ -Ed On Thu, Dec 13, 2012 at 4:10 AM, Aftab Siddiqui wrote: > Kindly search the archives for many threads on the same subject, which > should be the normal practice. > > nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. > The first one I assume should serve your purpose for both v4 and v6. > > Regards, > > Aftab A. Siddiqui > > > > On Thu, Dec 13, 2012 at 6:22 AM, Eric A Louie wrote: > >> I'm looking for IPAM solutions for a small regional wireless ISP. >> There are 4 Tier 2 personnel and 2 NOC technicians who would be using >> the tool, and a small staff of engineers. >> >> They have regionalized IP addresses so blocks are local, but there >> are subnets that are global. >> >> don't care if it's a linux or windows solution. >> >> Need to be able to migrate from FreeIPdb (yes, I know, it's a >> dinosaur) >> >> We're not dealing with a lot now, but the potential for growth is >> pretty high. >> >> What are you using and how is it working for you? >> >> Much appreciated, Eric >> -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/ From saku at ytti.fi Thu Dec 20 07:11:43 2012 From: saku at ytti.fi (Saku Ytti) Date: Thu, 20 Dec 2012 09:11:43 +0200 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: <20121220071143.GA12392@pob.ytti.fi> On (2012-12-20 03:24 +0000), Blake Pfankuch wrote: > I actually was doing research on this today as well. Anyone have any experience with the solutions that implement VLAN management as well like Gestioip? I'm not remotely interested in externally developed software for this problem. But it's fair question. Generally this tool should not be IP or VLAN based but generic resource reservation tool, IP, VLAN, RD, RT, VPLS-ID, site-id, pseudowireID what have you. For me, humans would not do much directly with the tool. They'd give it large chunk of resource. Then maybe mine it to pools like 'coreLink', 'coreLoop', 'custLink', 'custLAN' etc. Then in your provisioning tools, you'd request resource from specific pool via restful API. Humand would never manually write RD/RT/IP/VLAN in the tool or in the configs. And this type of system is vastly simpler than the IPAMs I see listed, once you get rid of all the UI candy, it gets rather easy problem to solve. -- ++ytti From thilo.bangert at gmail.com Thu Dec 20 09:30:02 2012 From: thilo.bangert at gmail.com (Thilo Bangert) Date: Thu, 20 Dec 2012 10:30:02 +0100 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <20121220071143.GA12392@pob.ytti.fi> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> Message-ID: <2476824.tOcxV55WB6@marsupilami> On Thursday 20 December 2012 09:11:43 Saku Ytti wrote: > On (2012-12-20 03:24 +0000), Blake Pfankuch wrote: > > I actually was doing research on this today as well. Anyone have any > > experience with the solutions that implement VLAN management as well like > > Gestioip? > I'm not remotely interested in externally developed software for this > problem. what do you mean. i'd be fine with an opensource project providing this. > But it's fair question. Generally this tool should not be IP or > VLAN based but generic resource reservation tool, IP, VLAN, RD, RT, > VPLS-ID, site-id, pseudowireID what have you. > > For me, humans would not do much directly with the tool. They'd give it > large chunk of resource. Then maybe mine it to pools like 'coreLink', > 'coreLoop', 'custLink', 'custLAN' etc. > Then in your provisioning tools, you'd request resource from specific pool > via restful API. Humand would never manually write RD/RT/IP/VLAN in the > tool or in the configs. And this type of system is vastly simpler than the > IPAMs I see listed, once you get rid of all the UI candy, it gets rather > easy problem to solve. this is a pretty accurate description of our requirements, as well. off the top of my head we'd also manage phone numbers, key ids, and key box ids, with it, but that would almost be a minor detail. ;-) From david at mailplus.nl Thu Dec 20 09:46:29 2012 From: david at mailplus.nl (MailPlus| David Hofstee) Date: Thu, 20 Dec 2012 10:46:29 +0100 Subject: Contact person for doh.state.fl.us Message-ID: <78C35D6C1A82D243B830523B4193CF5F5E8D751AD6@SBS1.blinker.local> Hi, Does anyone know a contact for doh.state.fl.us? I tried to contact them after we received this interesting line of logfile: "554 5.7.1 46.31.52.10 (in 46.0.0.0/8) is blacklisted." received from mx5201.doh.state.fl.us (74.174.235.12) Thanks in advance, David Hofstee MailPlus B.V. Netherlands From regnauld at nsrc.org Thu Dec 20 09:48:19 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 20 Dec 2012 10:48:19 +0100 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <2476824.tOcxV55WB6@marsupilami> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <2476824.tOcxV55WB6@marsupilami> Message-ID: <20121220094819.GF32358@macbook.bluepipe.net> Thilo Bangert (thilo.bangert) writes: > > Then in your provisioning tools, you'd request resource from specific pool > > via restful API. Humand would never manually write RD/RT/IP/VLAN in the > > tool or in the configs. And this type of system is vastly simpler than the > > IPAMs I see listed, once you get rid of all the UI candy, it gets rather > > easy problem to solve. > > this is a pretty accurate description of our requirements, as well. off the > top of my head we'd also manage phone numbers, key ids, and key box ids, with > it, but that would almost be a minor detail. ;-) I think many of these requirements would be met by Netdot... Cheers, Phil From nick at foobar.org Thu Dec 20 09:54:02 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 20 Dec 2012 09:54:02 +0000 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <20121220094819.GF32358@macbook.bluepipe.net> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <2476824.tOcxV55WB6@marsupilami> <20121220094819.GF32358@macbook.bluepipe.net> Message-ID: <50D2E03A.7070404@foobar.org> On 20/12/2012 09:48, Phil Regnauld wrote: > I think many of these requirements would be met by Netdot... netdot doesn't handle vrfs. This is one of its major drawbacks. Nick From saku at ytti.fi Thu Dec 20 09:58:08 2012 From: saku at ytti.fi (Saku Ytti) Date: Thu, 20 Dec 2012 11:58:08 +0200 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <2476824.tOcxV55WB6@marsupilami> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <2476824.tOcxV55WB6@marsupilami> Message-ID: <20121220095808.GA14042@pob.ytti.fi> On (2012-12-20 10:30 +0100), Thilo Bangert wrote: > > I'm not remotely interested in externally developed software for this > > problem. > > what do you mean. i'd be fine with an opensource project providing this. If exactly what I want exist, of course I'd love to have it. But evaluating options, working with them until you realise it does not work for you might take more time to just build it in-house to fit your needs and integrate to your existing systems. I have same opinion for NMS also. Everything I see offered is terrible and do not even solve easy-to-solve problems correctly. -- ++ytti From regnauld at nsrc.org Thu Dec 20 10:02:59 2012 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 20 Dec 2012 11:02:59 +0100 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <20121220095808.GA14042@pob.ytti.fi> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <2476824.tOcxV55WB6@marsupilami> <20121220095808.GA14042@pob.ytti.fi> Message-ID: <20121220100259.GH32358@macbook.bluepipe.net> Saku Ytti (saku) writes: > > If exactly what I want exist, of course I'd love to have it. But evaluating > options, working with them until you realise it does not work for you might > take more time to just build it in-house to fit your needs and integrate to > your existing systems. http://xkcd.com/927/ > I have same opinion for NMS also. Everything I see offered is terrible and > do not even solve easy-to-solve problems correctly. Right, that's what's great about Open Source :D Phil From saku at ytti.fi Thu Dec 20 10:10:12 2012 From: saku at ytti.fi (Saku Ytti) Date: Thu, 20 Dec 2012 12:10:12 +0200 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <20121220100259.GH32358@macbook.bluepipe.net> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <2476824.tOcxV55WB6@marsupilami> <20121220095808.GA14042@pob.ytti.fi> <20121220100259.GH32358@macbook.bluepipe.net> Message-ID: <20121220101012.GB14042@pob.ytti.fi> On (2012-12-20 11:02 +0100), Phil Regnauld wrote: > > I have same opinion for NMS also. Everything I see offered is terrible and > > do not even solve easy-to-solve problems correctly. > > Right, that's what's great about Open Source :D The comment fully applies to system like HP OV or NNM or what is it called today. It does nothing worth while to you without putting hours and hours of work into it. While it's easy to define what every SP wants out of NMS which can be turn-key, without spamming people with so many alarms that they stop caring about them. You can literally start from 0 and in 2h have software to send traps to IRC/XMPP and get alarms from link up/down, isis up/down, bgp up/down, ldp up/down, hardware inserted/removed, PSU offline/online etc. Which already to my demands is superior I can get out of any system in 2h I've looked into. -- ++ytti From mpetach at netflight.com Thu Dec 20 13:16:20 2012 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 20 Dec 2012 05:16:20 -0800 Subject: Need a Yahoo network contact In-Reply-To: <225F609B48882B4D94C1E5D262814D7F02BE588C559D@STRATUSMBX02.Terenine.com> References: <225F609B48882B4D94C1E5D262814D7F02BE588C559D@STRATUSMBX02.Terenine.com> Message-ID: On Wed, Dec 19, 2012 at 10:46 AM, Joe Freeman wrote: > I need a Yahoo contact if anyone is available. > > I'm having issues with customers on 186.65.92.0/22 (ASN52379) out of Costa Rica being able to reach Yahoo sites (www.yahoo.com/www.flickr.com) with their web browsers, but they can ping them just fine. > > Thanks- > joe when you telnet to port 80, do you get a response from the webserver? If so, it sounds like the network layer is likely doing what it's supposed to, and the issue might lie higher up the stack. can you characterize the nature of the issue a bit more closely? Thanks! Matt > > > ________________________________ > This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. > From amcmillen at sliqua.com Thu Dec 20 14:12:40 2012 From: amcmillen at sliqua.com (Alexander McMillen) Date: Thu, 20 Dec 2012 09:12:40 -0500 Subject: ATLBL Contact Message-ID: <50D31CD8.2080000@sliqua.com> Good morning all, Is there a contact for the ATLBL DNSBL or Network Solutions e-mail that could contact me off-list? The ATLBL blacklist is causing mail delivery issues from 199.58.208.0/21 to all mail servers utilizing the ATLBL blacklist (most notably Network Solutions). I have done some research into the ATLBL blacklist and their website just shows a bunch of advertisements with no relevant content regarding the DNSBL (awesome)... perhaps someone at Network Solutions could address this. Any assistance in getting this rectified would be greatly appreciated. I know NANOG probably isn't the best list for this type of inquiry, but there may be someone that could point me in the right direction. Any recommendations for a related mailing list would also be useful. :-) Thanks! Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 945 bytes Desc: OpenPGP digital signature URL: From jlewis at lewis.org Thu Dec 20 14:21:25 2012 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 20 Dec 2012 09:21:25 -0500 (EST) Subject: ATLBL Contact In-Reply-To: <50D31CD8.2080000@sliqua.com> References: <50D31CD8.2080000@sliqua.com> Message-ID: On Thu, 20 Dec 2012, Alexander McMillen wrote: > Good morning all, > > Is there a contact for the ATLBL DNSBL or Network Solutions e-mail that > could contact me off-list? > > The ATLBL blacklist is causing mail delivery issues from 199.58.208.0/21 > to all mail servers utilizing the ATLBL blacklist (most notably Network > Solutions). I have done some research into the ATLBL blacklist and their > website just shows a bunch of advertisements with no relevant content > regarding the DNSBL (awesome)... perhaps someone at Network Solutions > could address this. atlbl.com doesn't appear to be a DNSBL [anymore]. If you look at the whois, it looks more like domain tasters have taken it over after its registration lapsed. Anyone using it for blocking is resolving all IPs (via a wildcard A record) to 141.8.225.13. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bhm at ufl.edu Thu Dec 20 15:30:54 2012 From: bhm at ufl.edu (Bruce H McIntosh) Date: Thu, 20 Dec 2012 10:30:54 -0500 Subject: Contact person for doh.state.fl.us In-Reply-To: <78C35D6C1A82D243B830523B4193CF5F5E8D751AD6@SBS1.blinker.local> References: <78C35D6C1A82D243B830523B4193CF5F5E8D751AD6@SBS1.blinker.local> Message-ID: <1356017454.8424.2.camel@highlands> On Thu, 2012-12-20 at 10:46 +0100, MailPlus| David Hofstee wrote: > Hi, > > > > Does anyone know a contact for doh.state.fl.us? I tried to contact them after we received this interesting line of logfile: Replied off-list -- ------------------------------------------------------------------------ Bruce H. McIntosh bhm at ufl.edu Senior Network Engineer http://net-services.ufl.edu University of Florida CNS/Network Services 352-273-1066 From josh at zevlag.com Thu Dec 20 16:58:15 2012 From: josh at zevlag.com (Josh Galvez) Date: Thu, 20 Dec 2012 09:58:15 -0700 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <2476824.tOcxV55WB6@marsupilami> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <2476824.tOcxV55WB6@marsupilami> Message-ID: This tool handle most of what you are asking for: http://www.nocproject.org/ -Josh On Thu, Dec 20, 2012 at 2:30 AM, Thilo Bangert wrote: > On Thursday 20 December 2012 09:11:43 Saku Ytti wrote: > > On (2012-12-20 03:24 +0000), Blake Pfankuch wrote: > > > I actually was doing research on this today as well. Anyone have any > > > experience with the solutions that implement VLAN management as well > like > > > Gestioip? > > I'm not remotely interested in externally developed software for this > > problem. > > what do you mean. i'd be fine with an opensource project providing this. > > > But it's fair question. Generally this tool should not be IP or > > VLAN based but generic resource reservation tool, IP, VLAN, RD, RT, > > VPLS-ID, site-id, pseudowireID what have you. > > > > For me, humans would not do much directly with the tool. They'd give it > > large chunk of resource. Then maybe mine it to pools like 'coreLink', > > 'coreLoop', 'custLink', 'custLAN' etc. > > Then in your provisioning tools, you'd request resource from specific > pool > > via restful API. Humand would never manually write RD/RT/IP/VLAN in the > > tool or in the configs. And this type of system is vastly simpler than > the > > IPAMs I see listed, once you get rid of all the UI candy, it gets rather > > easy problem to solve. > > this is a pretty accurate description of our requirements, as well. off the > top of my head we'd also manage phone numbers, key ids, and key box ids, > with > it, but that would almost be a minor detail. ;-) > > > > From mike at mtcc.com Thu Dec 20 18:20:11 2012 From: mike at mtcc.com (Michael Thomas) Date: Thu, 20 Dec 2012 10:20:11 -0800 Subject: why haven't ethernet connectors changed? Message-ID: <50D356DB.5090809@mtcc.com> I was looking at a Raspberry Pi board and was struck with how large the ethernet connector is in comparison to the board as a whole. It strikes me: ethernet connectors haven't changed that I'm aware in pretty much 25 years. Every other cable has changed several times in that time frame. I imaging that if anybody cared, ethernet cables could be many times smaller. Looking at wiring closets, etc, it seems like it might be a big win for density too. So why, oh why, nanog the omniscient do we still use rj45's? Mike From mloftis at wgops.com Thu Dec 20 18:28:52 2012 From: mloftis at wgops.com (Michael Loftis) Date: Thu, 20 Dec 2012 10:28:52 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D356DB.5090809@mtcc.com> References: <50D356DB.5090809@mtcc.com> Message-ID: It's not all about density. You *Must* have positive retention and alignment. None of the USB nor firewire standards provide for positive retention. eSATA does sort of in some variants but the connectors for USB are especially delicate and easy to break off and destroy. There's the size of the Cat5/5e/6 cable to be considered too. Then you must consider that the standard must allow for local termination, the RJ45 (And it's relatives) are pretty good at this. Fast, reliable, repeatable termination with a single simple tool that requires only a little bit of mechanical input from the user of the tool. On Thu, Dec 20, 2012 at 10:20 AM, Michael Thomas wrote: > I was looking at a Raspberry Pi board and was struck with how large the > ethernet > connector is in comparison to the board as a whole. It strikes me: ethernet > connectors haven't changed that I'm aware in pretty much 25 years. Every > other > cable has changed several times in that time frame. I imaging that if > anybody > cared, ethernet cables could be many times smaller. Looking at wiring > closets, > etc, it seems like it might be a big win for density too. > > So why, oh why, nanog the omniscient do we still use rj45's? > > Mike > > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From tech-lists at packet-labs.net Thu Dec 20 18:29:02 2012 From: tech-lists at packet-labs.net (tech-lists at packet-labs.net) Date: Thu, 20 Dec 2012 12:29:02 -0600 Subject: why haven't ethernet connectors =?UTF-8?Q?changed=3F?= In-Reply-To: <50D356DB.5090809@mtcc.com> References: <50D356DB.5090809@mtcc.com> Message-ID: <4fa2d368ac9672074f9681a06a2681e1@packet-labs.net> On 2012-12-20 12:20, Michael Thomas wrote: > I was looking at a Raspberry Pi board and was struck with how large > the ethernet > connector is in comparison to the board as a whole. It strikes me: > ethernet > connectors haven't changed that I'm aware in pretty much 25 years. > Every other > cable has changed several times in that time frame. I imaging that if > anybody > cared, ethernet cables could be many times smaller. Looking at wiring > closets, > etc, it seems like it might be a big win for density too. > > So why, oh why, nanog the omniscient do we still use rj45's? > > Mike The primary reason that pops to mind is backwards compatibility... Ubiquitous availablity of the parts for RJ45 connectors (end connectors, wall plates, panels, etc.) also means that it is more economical to continue using the well established connector. A new connector would drive up costs initially, whereas continuing to use RJ45 is cheap and already works. Jay From woody at pch.net Thu Dec 20 18:29:07 2012 From: woody at pch.net (Bill Woodcock) Date: Thu, 20 Dec 2012 10:29:07 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D356DB.5090809@mtcc.com> References: <50D356DB.5090809@mtcc.com> Message-ID: On Dec 20, 2012, at 10:20 AM, Michael Thomas wrote: > I was looking at a Raspberry Pi board and was struck with how large the ethernet > connector is in comparison to the board as a whole. It strikes me: ethernet > connectors haven't changed that I'm aware in pretty much 25 years. Actually, I was just throwing some away yesterday, and it struck me how much things _had_ changed. http://www.cisco.com/en/US/products/hw/routers/ps214/products_tech_note09186a00801f5d86.shtml -Bill From Vinny_Abello at Dell.com Thu Dec 20 18:34:17 2012 From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com) Date: Thu, 20 Dec 2012 18:34:17 +0000 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> Message-ID: MRJ21 also helps density in some scenarios (like line card and patch panel density), although ultimately you need to go back to RJ45 at some point. -Vinny -----Original Message----- From: Michael Loftis [mailto:mloftis at wgops.com] Sent: Thursday, December 20, 2012 1:29 PM To: Michael Thomas Cc: NANOG list Subject: Re: why haven't ethernet connectors changed? It's not all about density. You *Must* have positive retention and alignment. None of the USB nor firewire standards provide for positive retention. eSATA does sort of in some variants but the connectors for USB are especially delicate and easy to break off and destroy. There's the size of the Cat5/5e/6 cable to be considered too. Then you must consider that the standard must allow for local termination, the RJ45 (And it's relatives) are pretty good at this. Fast, reliable, repeatable termination with a single simple tool that requires only a little bit of mechanical input from the user of the tool. On Thu, Dec 20, 2012 at 10:20 AM, Michael Thomas wrote: > I was looking at a Raspberry Pi board and was struck with how large the > ethernet > connector is in comparison to the board as a whole. It strikes me: ethernet > connectors haven't changed that I'm aware in pretty much 25 years. Every > other > cable has changed several times in that time frame. I imaging that if > anybody > cared, ethernet cables could be many times smaller. Looking at wiring > closets, > etc, it seems like it might be a big win for density too. > > So why, oh why, nanog the omniscient do we still use rj45's? > > Mike > > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From blueneon at gmail.com Thu Dec 20 18:34:13 2012 From: blueneon at gmail.com (Tom Morris) Date: Thu, 20 Dec 2012 13:34:13 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D356DB.5090809@mtcc.com> References: <50D356DB.5090809@mtcc.com> Message-ID: I'm going to go by the "Necessity is the mother of invention" theory here and say that it's basically because the need for a subcompact ethernet connector hasn't shown up in masse yet. It was probably just adopted because it's inexpensive, easy to install using tools already out there in the telecom world, and it works well enough at the required feedline impedance of 100 ohms. That being said, any connector that works for balanced line signalling with a feedline impedance of 100 ohms and a favorable frequency response up to 100mc (100base-T / cat5) or 250mc (1000baseT / cat6) should work just fine. For obvious reasons, standardization of the submini ethernet connector should be present industrywide, so you don't have to start carrying around adapters. Boy would I ever love an ethernet connector that works like Apple's MagSafe... or at least just kinda friction fits like USB... THOSE TABS... On Thu, Dec 20, 2012 at 1:20 PM, Michael Thomas wrote: > I was looking at a Raspberry Pi board and was struck with how large the > ethernet > connector is in comparison to the board as a whole. It strikes me: ethernet > connectors haven't changed that I'm aware in pretty much 25 years. Every > other > cable has changed several times in that time frame. I imaging that if > anybody > cared, ethernet cables could be many times smaller. Looking at wiring > closets, > etc, it seems like it might be a big win for density too. > > So why, oh why, nanog the omniscient do we still use rj45's? > > Mike > -- -- Tom Morris, KG4CYX Mad Scientist For Hire Chairman, South Florida Tropical Hamboree / Miami Hamfest Engineer, WRGP Radiate FM, Florida International University 786-228-7087 151.820 Megacycles From joelja at bogus.com Thu Dec 20 18:34:34 2012 From: joelja at bogus.com (joel jaeggli) Date: Thu, 20 Dec 2012 10:34:34 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D356DB.5090809@mtcc.com> References: <50D356DB.5090809@mtcc.com> Message-ID: <50D35A3A.1040605@bogus.com> the 8p8c connector is durable. The connector predates twisted pair ethernet by a decade or more. you could also ask about 1/4" TRS which is still in use albiet not in phone systems for about 100 years longer. On 12/20/12 10:20 AM, Michael Thomas wrote: > I was looking at a Raspberry Pi board and was struck with how large > the ethernet > connector is in comparison to the board as a whole. It strikes me: > ethernet > connectors haven't changed that I'm aware in pretty much 25 years. > Every other > cable has changed several times in that time frame. I imaging that if > anybody > cared, ethernet cables could be many times smaller. Looking at wiring > closets, > etc, it seems like it might be a big win for density too. > > So why, oh why, nanog the omniscient do we still use rj45's? > > Mike > From kurt at idb-sys.com Thu Dec 20 18:35:45 2012 From: kurt at idb-sys.com (Kurt) Date: Thu, 20 Dec 2012 13:35:45 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> Message-ID: <000101cddee0$d72bb9a0$85832ce0$@idb-sys.com> If you've ever dealt with connections like micro-usb on a day-in-day out plugging and unplugging at not quite head on connections, you know how bad this can be on a hardwired connection. With very few exceptions, its very difficult to have an rj45 go in any way but the way its designed to (well you can, but you have to try reeeeeeeally hard). Add onto it that any replacement would be caught in enough intellectual property rights junk to price it into oblivion and would either require tons of adapters to make it work with legacy hardware (defeat the purpose), or would require replacing all of that legacy hardware entirely. -----Original Message----- From: Michael Loftis [mailto:mloftis at wgops.com] Sent: Thursday, December 20, 2012 1:29 PM To: Michael Thomas Cc: NANOG list Subject: Re: why haven't ethernet connectors changed? It's not all about density. You *Must* have positive retention and alignment. None of the USB nor firewire standards provide for positive retention. eSATA does sort of in some variants but the connectors for USB are especially delicate and easy to break off and destroy. There's the size of the Cat5/5e/6 cable to be considered too. Then you must consider that the standard must allow for local termination, the RJ45 (And it's relatives) are pretty good at this. Fast, reliable, repeatable termination with a single simple tool that requires only a little bit of mechanical input from the user of the tool. On Thu, Dec 20, 2012 at 10:20 AM, Michael Thomas wrote: > I was looking at a Raspberry Pi board and was struck with how large > the ethernet connector is in comparison to the board as a whole. It > strikes me: ethernet connectors haven't changed that I'm aware in > pretty much 25 years. Every other cable has changed several times in > that time frame. I imaging that if anybody cared, ethernet cables > could be many times smaller. Looking at wiring closets, etc, it seems > like it might be a big win for density too. > > So why, oh why, nanog the omniscient do we still use rj45's? > > Mike > > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From aledm at qix.co.uk Thu Dec 20 18:38:05 2012 From: aledm at qix.co.uk (Aled Morris) Date: Thu, 20 Dec 2012 18:38:05 +0000 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D356DB.5090809@mtcc.com> References: <50D356DB.5090809@mtcc.com> Message-ID: On 20 December 2012 18:20, Michael Thomas wrote > ethernet > connectors haven't changed that I'm aware in pretty much 25 years. 15-pin D-type AUI connectors with slide latches? BNC for thinwire? I do agree though, something more like mini-USB would be more appropriate for home Ethernet use. Aled From j at 2600hz.com Thu Dec 20 18:38:56 2012 From: j at 2600hz.com (Joshua Goldbard) Date: Thu, 20 Dec 2012 18:38:56 +0000 Subject: why haven't ethernet connectors changed? In-Reply-To: <4fa2d368ac9672074f9681a06a2681e1@packet-labs.net> References: <50D356DB.5090809@mtcc.com> <4fa2d368ac9672074f9681a06a2681e1@packet-labs.net> Message-ID: They haven't changed for you: http://t3.gstatic.com/images?q=tbn:ANd9GcTzJPvwOhWoL2afxBdl7a-LmYYWwzgQNpiHSXr4ppIMgsZuWP6Oy1NVnrpN Cheers, Joshua On Dec 20, 2012, at 10:29 AM, > wrote: On 2012-12-20 12:20, Michael Thomas wrote: I was looking at a Raspberry Pi board and was struck with how large the ethernet connector is in comparison to the board as a whole. It strikes me: ethernet connectors haven't changed that I'm aware in pretty much 25 years. Every other cable has changed several times in that time frame. I imaging that if anybody cared, ethernet cables could be many times smaller. Looking at wiring closets, etc, it seems like it might be a big win for density too. So why, oh why, nanog the omniscient do we still use rj45's? Mike The primary reason that pops to mind is backwards compatibility... Ubiquitous availablity of the parts for RJ45 connectors (end connectors, wall plates, panels, etc.) also means that it is more economical to continue using the well established connector. A new connector would drive up costs initially, whereas continuing to use RJ45 is cheap and already works. Jay From hcb at netcases.net Thu Dec 20 18:40:51 2012 From: hcb at netcases.net (Howard C. Berkowitz) Date: Thu, 20 Dec 2012 13:40:51 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D356DB.5090809@mtcc.com> References: <50D356DB.5090809@mtcc.com> Message-ID: <50D35BB3.3000800@netcases.net> On 12/20/2012 1:20 PM, Michael Thomas wrote: > I was looking at a Raspberry Pi board and was struck with how large > the ethernet > connector is in comparison to the board as a whole. It strikes me: > ethernet > connectors haven't changed that I'm aware in pretty much 25 years. > Every other > cable has changed several times in that time frame. I imaging that if > anybody > cared, ethernet cables could be many times smaller. Looking at wiring > closets, > etc, it seems like it might be a big win for density too. > > So why, oh why, nanog the omniscient do we still use rj45's? > > Mike > > Seen an AUI or vampire tap recently? Vampires made a certain amount of sense, but the AUI connector seemed to have little purpose other than recycling weak metal from Coors beer cans. IIRC, the inventor apologized. From web at typo.org Thu Dec 20 18:41:04 2012 From: web at typo.org (Wayne E Bouchard) Date: Thu, 20 Dec 2012 11:41:04 -0700 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> Message-ID: <20121220184104.GA46518@wakko.typo.org> There is also the factor that cat5 is the principle desktop to network connection. That being the case, there's very strong motivation for ensuring that construction of that cable can be done very easily by barely trained folks. Otherwise, laying out an office or cube farm becomes considerably more difficult and expensive. RJ45 is and always has been a very easy termination as long as you can tell one color from another. How many people here have gotten good enough that they can cut a cable and pop connectors on each end in under 3 minutes? How many have gotten good enough that the failure rate for *hand made* cables is sub 1:1000? Show me another connector type where that will be true. Really, it will remain that way until the bandwidth needs from the desktop begin to push the GE threshold. Until then, why bother changing anything? When that does happen, it'll pretty well deal with itself. -Wayne On Thu, Dec 20, 2012 at 10:28:52AM -0800, Michael Loftis wrote: > It's not all about density. You *Must* have positive retention and > alignment. None of the USB nor firewire standards provide for positive > retention. eSATA does sort of in some variants but the connectors for USB > are especially delicate and easy to break off and destroy. There's the > size of the Cat5/5e/6 cable to be considered too. > > Then you must consider that the standard must allow for local termination, > the RJ45 (And it's relatives) are pretty good at this. Fast, reliable, > repeatable termination with a single simple tool that requires only a > little bit of mechanical input from the user of the tool. > > > On Thu, Dec 20, 2012 at 10:20 AM, Michael Thomas wrote: > > > I was looking at a Raspberry Pi board and was struck with how large the > > ethernet > > connector is in comparison to the board as a whole. It strikes me: ethernet > > connectors haven't changed that I'm aware in pretty much 25 years. Every > > other > > cable has changed several times in that time frame. I imaging that if > > anybody > > cared, ethernet cables could be many times smaller. Looking at wiring > > closets, > > etc, it seems like it might be a big win for density too. > > > > So why, oh why, nanog the omniscient do we still use rj45's? > > > > Mike > > > > > > > -- > > "Genius might be described as a supreme capacity for getting its possessors > into trouble of all kinds." > -- Samuel Butler --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From mike at mtcc.com Thu Dec 20 18:41:28 2012 From: mike at mtcc.com (Michael Thomas) Date: Thu, 20 Dec 2012 10:41:28 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> Message-ID: <50D35BD8.3030004@mtcc.com> On 12/20/2012 10:28 AM, Michael Loftis wrote: > It's not all about density. You *Must* have positive retention and alignment. None of the USB nor firewire standards provide for positive retention. eSATA does sort of in some variants but the connectors for USB are especially delicate and easy to break off and destroy. There's the size of the Cat5/5e/6 cable to be considered too. > > Then you must consider that the standard must allow for local termination, the RJ45 (And it's relatives) are pretty good at this. Fast, reliable, repeatable termination with a single simple tool that requires only a little bit of mechanical input from the user of the tool. If you look at the Raspberry Pi though, it takes a substantial piece of real estate though. Not everything needs to be industrial strength connectors as witnessed by USB and HDMI -- if they fail I'm just as unhappy as if ethernet fails. Surely we want keep shrinking these cute little purpose built controller-like things and not *have* to rely on wireless as the only other space-saving means? Mike From cmadams at hiwaay.net Thu Dec 20 18:48:25 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 20 Dec 2012 12:48:25 -0600 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> Message-ID: <20121220184824.GE26803@hiwaay.net> Once upon a time, Tom Morris said: > Boy would I ever love an ethernet connector that works like Apple's > MagSafe... or at least just kinda friction fits like USB... THOSE > TABS... Please, NO! Connectors without a positive locking mechanism should just die (and that includes IEC power connectors). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ralph.brandt at pateam.com Thu Dec 20 19:10:13 2012 From: ralph.brandt at pateam.com (Brandt, Ralph) Date: Thu, 20 Dec 2012 14:10:13 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D356DB.5090809@mtcc.com> References: <50D356DB.5090809@mtcc.com> Message-ID: <51C66083768C2949A7EB14910C78B01701BA4BCC@embgsr24.pateam.com> Because MA Bell is still alive and well and they still use them. They have divine right to provide phone service, didn't you know? Ralph Brandt -----Original Message----- From: Michael Thomas [mailto:mike at mtcc.com] Sent: Thursday, December 20, 2012 1:20 PM To: NANOG list Subject: why haven't ethernet connectors changed? I was looking at a Raspberry Pi board and was struck with how large the ethernet connector is in comparison to the board as a whole. It strikes me: ethernet connectors haven't changed that I'm aware in pretty much 25 years. Every other cable has changed several times in that time frame. I imaging that if anybody cared, ethernet cables could be many times smaller. Looking at wiring closets, etc, it seems like it might be a big win for density too. So why, oh why, nanog the omniscient do we still use rj45's? Mike From wingar at team-metro.net Thu Dec 20 19:00:35 2012 From: wingar at team-metro.net (Emily Ozols) Date: Fri, 21 Dec 2012 06:00:35 +1100 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <4fa2d368ac9672074f9681a06a2681e1@packet-labs.net> Message-ID: Is that the infamous Google Pluto switch? On Fri, Dec 21, 2012 at 5:38 AM, Joshua Goldbard wrote: > They haven't changed for you: http://t3.gstatic.com/images?q=tbn:ANd9GcTzJPvwOhWoL2afxBdl7a-LmYYWwzgQNpiHSXr4ppIMgsZuWP6Oy1NVnrpN > > Cheers, > Joshua -- ~Em From ralph.brandt at pateam.com Thu Dec 20 19:12:33 2012 From: ralph.brandt at pateam.com (Brandt, Ralph) Date: Thu, 20 Dec 2012 14:12:33 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> Message-ID: <51C66083768C2949A7EB14910C78B01701BA4BCD@embgsr24.pateam.com> Love those friction fit connectors till they loosen and fall out.... Ralph Brandt -----Original Message----- From: Tom Morris [mailto:blueneon at gmail.com] Sent: Thursday, December 20, 2012 1:34 PM To: Michael Thomas Cc: NANOG list Subject: Re: why haven't ethernet connectors changed? I'm going to go by the "Necessity is the mother of invention" theory here and say that it's basically because the need for a subcompact ethernet connector hasn't shown up in masse yet. It was probably just adopted because it's inexpensive, easy to install using tools already out there in the telecom world, and it works well enough at the required feedline impedance of 100 ohms. That being said, any connector that works for balanced line signalling with a feedline impedance of 100 ohms and a favorable frequency response up to 100mc (100base-T / cat5) or 250mc (1000baseT / cat6) should work just fine. For obvious reasons, standardization of the submini ethernet connector should be present industrywide, so you don't have to start carrying around adapters. Boy would I ever love an ethernet connector that works like Apple's MagSafe... or at least just kinda friction fits like USB... THOSE TABS... On Thu, Dec 20, 2012 at 1:20 PM, Michael Thomas wrote: > I was looking at a Raspberry Pi board and was struck with how large the > ethernet > connector is in comparison to the board as a whole. It strikes me: ethernet > connectors haven't changed that I'm aware in pretty much 25 years. Every > other > cable has changed several times in that time frame. I imaging that if > anybody > cared, ethernet cables could be many times smaller. Looking at wiring > closets, > etc, it seems like it might be a big win for density too. > > So why, oh why, nanog the omniscient do we still use rj45's? > > Mike > -- -- Tom Morris, KG4CYX Mad Scientist For Hire Chairman, South Florida Tropical Hamboree / Miami Hamfest Engineer, WRGP Radiate FM, Florida International University 786-228-7087 151.820 Megacycles From ross.harvey at appfolio.com Thu Dec 20 19:15:41 2012 From: ross.harvey at appfolio.com (Ross Harvey) Date: Thu, 20 Dec 2012 11:15:41 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D35BD8.3030004@mtcc.com> References: <50D356DB.5090809@mtcc.com> <50D35BD8.3030004@mtcc.com> Message-ID: Do note that the 8P8C on the Raspberry Pi has integrated magnetics that you can't see without an x-ray imager. The space is not as wasted as some might think. Nothing stops a mfr from using whatever they want and providing a dongle, but now they need board space for the transformers. From bclark at spectraaccess.com Thu Dec 20 19:24:20 2012 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 20 Dec 2012 14:24:20 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D35BB3.3000800@netcases.net> References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> Message-ID: <50D365E4.7010401@spectraaccess.com> Sort of like saying why haven't we changed from RJ-48's for phones...old habits die hard I guess! For the most part the RJ-45 connector is pretty sturdy...remember those silly dongle cables that were used for pc-card Ethernet adapters in laptops...those things would last about a month before dying! As for the Raspiberry PI (I own one) it was silly to even put Ethernet on that instead of wi-fi, especially for the educational market that the PI was initially developed for; what classroom has Ethernet running to every desk especially in poor nations where copper theft is rampart! On 12/20/2012 01:40 PM, Howard C. Berkowitz wrote: > On 12/20/2012 1:20 PM, Michael Thomas wrote: >> I was looking at a Raspberry Pi board and was struck with how large >> the ethernet >> connector is in comparison to the board as a whole. It strikes me: >> ethernet >> connectors haven't changed that I'm aware in pretty much 25 years. >> Every other >> cable has changed several times in that time frame. I imaging that if >> anybody >> cared, ethernet cables could be many times smaller. Looking at wiring >> closets, >> etc, it seems like it might be a big win for density too. >> >> So why, oh why, nanog the omniscient do we still use rj45's? >> >> Mike >> >> > Seen an AUI or vampire tap recently? Vampires made a certain amount of > sense, but the AUI connector seemed to have little purpose other than > recycling weak metal from Coors beer cans. IIRC, the inventor apologized. > From gary.buhrmaster at gmail.com Thu Dec 20 19:25:24 2012 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 20 Dec 2012 11:25:24 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D356DB.5090809@mtcc.com> References: <50D356DB.5090809@mtcc.com> Message-ID: On Thu, Dec 20, 2012 at 10:20 AM, Michael Thomas wrote: .... > So why, oh why, nanog the omniscient do we still use rj45's? Because 8P8C connectors are well understood (both physically, and electrically)? And inertia matters. On some newer kit, Apple has removed the Ethernet port and uses a Thunderbolt <-> Ethernet dongle. Apple seems to link Ethernet ports are too big. From cjp at 0x1.net Thu Dec 20 19:37:30 2012 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Thu, 20 Dec 2012 14:37:30 -0500 Subject: NOVEC contact? Message-ID: Looking for a contact at NOVEC clueful about their DWDM infrastructure, specifically about delivering TDM circuits from another MPLS provider. Other providers' sales teams need not apply. -cjp From akg1330 at gmail.com Thu Dec 20 19:39:10 2012 From: akg1330 at gmail.com (Andrew Gallo) Date: Thu, 20 Dec 2012 14:39:10 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D356DB.5090809@mtcc.com> References: <50D356DB.5090809@mtcc.com> Message-ID: <50D3695E.7040902@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/20/2012 1:20 PM, Michael Thomas wrote: > I was looking at a Raspberry Pi board and was struck with how large the ethernet > connector is in comparison to the board as a whole. It strikes me: ethernet > connectors haven't changed that I'm aware in pretty much 25 years. Every other > cable has changed several times in that time frame. I imaging that if anybody > cared, ethernet cables could be many times smaller. Looking at wiring closets, > etc, it seems like it might be a big win for density too. > > So why, oh why, nanog the omniscient do we still use rj45's? > > Mike > > The connector is to ubiquitous to change. Other vendors have addressed the space issue by not supporting Ethernet, but forcing the use of a USB dongle (Macbook Air comes to mind). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ02leAAoJEBxhAh+LWUKihLsIAJFiUmoaKxHt0Cz0aDmtZGuT sPh1ET0FcNcblshSnt/Ii0kVbgnFJSxfr4s6FSvwWHJaoNZRpIFLQB5XBMHLX4VZ I61rc44XeQUABFoM+5dKFKUDLGcCTOttlFr9ndNDCJDiE3DYSe8yfel6t+Aq/mVf FXxbBbrPceeXXokugbdoPTdW0dBf7xSn3+xY4l+N56wSgJVpe7UHnXh5+TwWpgsN vQlP/RfVIeTuTLgcDqOUqiv/kj3g3cTQwpnuLSGshrJrepZbrgho/GX8yyf+ub45 KDo/k/uikvX5MTPnfbYGzsU4hloYTia8dSO/pQqz5DYx8kuJPr/dUCC62xUXXx8= =d80Z -----END PGP SIGNATURE----- From bill at herrin.us Thu Dec 20 19:43:04 2012 From: bill at herrin.us (William Herrin) Date: Thu, 20 Dec 2012 14:43:04 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D356DB.5090809@mtcc.com> References: <50D356DB.5090809@mtcc.com> Message-ID: On Thu, Dec 20, 2012 at 1:20 PM, Michael Thomas wrote: > So why, oh why, nanog the omniscient do we still use rj45's? Because they *work*. How much trouble do we have with USB or HDMI connectors coming loose? Also, RJ45 is around the minimum size where you can hand-terminate a cable. How would you go about quickly making a 36.5 foot 8 conductor cable with, say, micro USB ends? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike at mtcc.com Thu Dec 20 19:49:20 2012 From: mike at mtcc.com (Michael Thomas) Date: Thu, 20 Dec 2012 11:49:20 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> Message-ID: <50D36BC0.5050605@mtcc.com> On 12/20/2012 11:43 AM, William Herrin wrote: > Also, RJ45 is around the minimum size where you can hand-terminate a > cable. How would you go about quickly making a 36.5 foot 8 conductor > cable with, say, micro USB ends? > You're assuming that that's a universal requirement. Most people in retail situations just buy the cables, or they are shipped with the widget. They're also pretty used to being screwed over by greedy manufacturers for whom cable churn is a profit center (I'm looking at you, Apple). Mike From bill at herrin.us Thu Dec 20 20:01:38 2012 From: bill at herrin.us (William Herrin) Date: Thu, 20 Dec 2012 15:01:38 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D3695E.7040902@gmail.com> References: <50D356DB.5090809@mtcc.com> <50D3695E.7040902@gmail.com> Message-ID: On Thu, Dec 20, 2012 at 2:39 PM, Andrew Gallo wrote: > The connector is to ubiquitous to change. Other vendors have addressed > the space issue by not supporting Ethernet, but forcing the use of a USB > dongle (Macbook Air comes to mind). Thin net (50 ohm coax w/ BNC connectors) was ubiquitous once too. RJ45 with twisted pair had little trouble displacing it because it was much better. Every alternative I've seen to the RJ45 connector has been deficient in some major way. Hard to field terminate. Pulls loose too easily. Breaks if you look at it wrong. Etc. On the other hand, I wonder if it would be worth asking the 802.3 committee look at defining a single-pair ethernet standard that would interoperate with a normal 4-pair switch. So, you'd have two conductors into some kind of 2P2C micro-RJ connector on one end of the cable but into a full RJ45 connector on the other. A single-pair pair cable would run at best at a quarter of the speed of a four pair cable but for something like the Raspberry Pi that's really not a problem. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mike at mtcc.com Thu Dec 20 20:13:32 2012 From: mike at mtcc.com (Michael Thomas) Date: Thu, 20 Dec 2012 12:13:32 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <50D3695E.7040902@gmail.com> Message-ID: <50D3716C.5090408@mtcc.com> On 12/20/2012 12:01 PM, William Herrin wrote: > On the other hand, I wonder if it would be worth asking the 802.3 committee look at defining a single-pair ethernet standard that would interoperate with a normal 4-pair switch. So, you'd have two conductors into some kind of 2P2C micro-RJ connector on one end of the cable but into a full RJ45 connector on the other. A single-pair pair cable would run at best at a quarter of the speed of a four pair cable but for something like the Raspberry Pi that's really not a problem. Regards, Bill Herrin Yeah, that's kind of along the lines I'm thinking too. In the home of the future, say, I probably would like to have power/network for little sensors, etc, where you already have a gratuitous digital controller now, and then some. Do these things need to have gig-e speeds? Probably not... for a lot even Bluetooth speeds are probably fine. But they do want to be really small and really inexpensive. (Yes, I know about zigbee, but there's room for a variety of solutions depending on the situation.) Mike From jeroen at mompl.net Thu Dec 20 20:34:11 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 20 Dec 2012 12:34:11 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: <20121220184104.GA46518@wakko.typo.org> References: <50D356DB.5090809@mtcc.com> <20121220184104.GA46518@wakko.typo.org> Message-ID: <50D37643.2010705@mompl.net> On 12/20/2012 10:41 AM, Wayne E Bouchard wrote: > How many people here have gotten good enough that they can cut a > cable and pop connectors on each end in under 3 minutes? How many have > gotten good enough that the failure rate for *hand made* cables is sub > 1:1000? Show me another connector type where that will be true. > > Really, it will remain that way until the bandwidth needs from the > desktop begin to push the GE threshold. Until then, why bother > changing anything? When that does happen, it'll pretty well deal with > itself. I fully agree. I think the ethernet connector is pretty much the best and most useful one out there. Anything can be improved, however both from an admin and a user's perspective I can't find anything that works better, easier and is as sturdy. Regards, Jeroen -- Earthquake Magnitude: 4.8 Date: Thursday, December 20, 2012 13:38:05 UTC Location: Kepulauan Babar, Indonesia Latitude: -7.1032; Longitude: 129.2383 Depth: 162.10 km From dedelman at iname.com Thu Dec 20 20:57:09 2012 From: dedelman at iname.com (David Edelman) Date: Thu, 20 Dec 2012 15:57:09 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D35BB3.3000800@netcases.net> References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> Message-ID: <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> I think that you might be describing the DIX connector retaining clamp. Dave Edelman On Dec 20, 2012, at 13:40, "Howard C. Berkowitz" wrote: > On 12/20/2012 1:20 PM, Michael Thomas wrote: >> I was looking at a Raspberry Pi board and was struck with how large the ethernet >> connector is in comparison to the board as a whole. It strikes me: ethernet >> connectors haven't changed that I'm aware in pretty much 25 years. Every other >> cable has changed several times in that time frame. I imaging that if anybody >> cared, ethernet cables could be many times smaller. Looking at wiring closets, >> etc, it seems like it might be a big win for density too. >> >> So why, oh why, nanog the omniscient do we still use rj45's? >> >> Mike > Seen an AUI or vampire tap recently? Vampires made a certain amount of sense, but the AUI connector seemed to have little purpose other than recycling weak metal from Coors beer cans. IIRC, the inventor apologized. > From george.herbert at gmail.com Thu Dec 20 21:13:15 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 20 Dec 2012 13:13:15 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> Message-ID: Having (once) tapped thicknet, done a lot of thinnet termination and cable cut debugging, and then used hubs and switches in 10BT and onwards... Having had one main standard (RJ45) has been a huge benefit to advancing the state of networking to where we are today. But it is probably worth questioning if that's true going forwards. Laptops and Rasberry PI devices and some other device types define a "light" category, where positive retention and self-cable-termination are probably not net positives. Device side space and interconnect insert/remove cycles (along with sufficiently stiff connection retention, but not necessarily mechanical) would be prime drivers for this class. For some users, even more positive than RJ45 is warranted. I at times work in and have a number of friends working in various aerospace and rocketry areas, and RJ45's have been widely known to come loose under acceleration. Those people use more positive connctors (M12, other IP67, etc) for the most part. Those other standards exist already, though it's not unified down to one right answer yet. For datacenters, servers, most desktops, etc., I don't know that there's a good case for change. RJ45 is not broke for those users. The comment upthread a bit about a 2-wire / 1 pair spec, interoperable with 4-wire / 2 pair switches, with a RJ45 at one end and a device connector at the other, makes sense to me. Most of the "light connector" users would not need the full bandwidth. Even if this turns out to not be easy enough to do, a 4-wire mini connector of some sort is not that big of a deal. Whether that's a micro-insert, a magnetic-attached, what details... I see good arguments for magnetic attach, but it's harder to make them small. I see good arguments for small, but those will be mechanical and less positively retained. I don't know that the discussion is a NANOG-centric one from here on in, but it's good to have raised the idea. -- -george william herbert george.herbert at gmail.com From lyndon at orthanc.ca Thu Dec 20 22:14:14 2012 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 20 Dec 2012 14:14:14 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D3716C.5090408@mtcc.com> References: <50D356DB.5090809@mtcc.com> <50D3695E.7040902@gmail.com> <50D3716C.5090408@mtcc.com> Message-ID: <5AFA9626-3E18-4E1F-9226-19F54509BC30@orthanc.ca> On 2012-12-20, at 12:13 PM, Michael Thomas wrote: > Do these > things need to have gig-e speeds? Probably not... for a lot even Bluetooth speeds > are probably fine. But they do want to be really small and really inexpensive. Then run RS-422 or RS-485 over a single twisted pair. You don't even need a connector ? you can solder directly to the PCB. --lyndon From jeroen at mompl.net Thu Dec 20 22:24:53 2012 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 20 Dec 2012 14:24:53 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> Message-ID: <50D39035.903@mompl.net> On 12/20/2012 01:13 PM, George Herbert wrote: > For some users, even more positive than RJ45 is warranted. I at times > work in and have a number of friends working in various aerospace and > rocketry areas, and RJ45's have been widely known to come loose under > acceleration. I found that a spliced toothpick does wonders to prevent that. ;-) -- Earthquake Magnitude: 5.6 Date: Thursday, December 20, 2012 21:47:30 UTC Location: Molucca Sea Latitude: 0.5465; Longitude: 126.2327 Depth: 31.20 km From nick at foobar.org Thu Dec 20 22:28:51 2012 From: nick at foobar.org (Nick Hilliard) Date: Thu, 20 Dec 2012 22:28:51 +0000 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <2476824.tOcxV55WB6@marsupilami> Message-ID: <50D39123.8060100@foobar.org> On 20/12/2012 16:58, Josh Galvez wrote: > This tool handle most of what you are asking for: > > http://www.nocproject.org/ hard to configure though. When it gets to the stage that it's relatively easy to configure and has good quality documentation, it will be awesome. Nick > -Josh > > On Thu, Dec 20, 2012 at 2:30 AM, Thilo Bangert wrote: > >> On Thursday 20 December 2012 09:11:43 Saku Ytti wrote: >>> On (2012-12-20 03:24 +0000), Blake Pfankuch wrote: >>>> I actually was doing research on this today as well. Anyone have any >>>> experience with the solutions that implement VLAN management as well >> like >>>> Gestioip? >>> I'm not remotely interested in externally developed software for this >>> problem. >> >> what do you mean. i'd be fine with an opensource project providing this. >> >>> But it's fair question. Generally this tool should not be IP or >>> VLAN based but generic resource reservation tool, IP, VLAN, RD, RT, >>> VPLS-ID, site-id, pseudowireID what have you. >>> >>> For me, humans would not do much directly with the tool. They'd give it >>> large chunk of resource. Then maybe mine it to pools like 'coreLink', >>> 'coreLoop', 'custLink', 'custLAN' etc. >>> Then in your provisioning tools, you'd request resource from specific >> pool >>> via restful API. Humand would never manually write RD/RT/IP/VLAN in the >>> tool or in the configs. And this type of system is vastly simpler than >> the >>> IPAMs I see listed, once you get rid of all the UI candy, it gets rather >>> easy problem to solve. >> >> this is a pretty accurate description of our requirements, as well. off the >> top of my head we'd also manage phone numbers, key ids, and key box ids, >> with >> it, but that would almost be a minor detail. ;-) >> >> >> >> From wbailey at satelliteintelligencegroup.com Thu Dec 20 22:36:08 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 20 Dec 2012 22:36:08 +0000 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com>, Message-ID: I'm shocked there hasn't been a whisper of amphenol. As an rf guy, I vote all connectors move to sma or bnc. I can then justify the cost of a Walmart 10 foot cable for 25 dollars.. And if we gold plate them, we can charge a premium. ;) >From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: George Herbert Date: 12/20/2012 1:15 PM (GMT-08:00) To: nanog at nanog.org Subject: Re: why haven't ethernet connectors changed? Having (once) tapped thicknet, done a lot of thinnet termination and cable cut debugging, and then used hubs and switches in 10BT and onwards... Having had one main standard (RJ45) has been a huge benefit to advancing the state of networking to where we are today. But it is probably worth questioning if that's true going forwards. Laptops and Rasberry PI devices and some other device types define a "light" category, where positive retention and self-cable-termination are probably not net positives. Device side space and interconnect insert/remove cycles (along with sufficiently stiff connection retention, but not necessarily mechanical) would be prime drivers for this class. For some users, even more positive than RJ45 is warranted. I at times work in and have a number of friends working in various aerospace and rocketry areas, and RJ45's have been widely known to come loose under acceleration. Those people use more positive connctors (M12, other IP67, etc) for the most part. Those other standards exist already, though it's not unified down to one right answer yet. For datacenters, servers, most desktops, etc., I don't know that there's a good case for change. RJ45 is not broke for those users. The comment upthread a bit about a 2-wire / 1 pair spec, interoperable with 4-wire / 2 pair switches, with a RJ45 at one end and a device connector at the other, makes sense to me. Most of the "light connector" users would not need the full bandwidth. Even if this turns out to not be easy enough to do, a 4-wire mini connector of some sort is not that big of a deal. Whether that's a micro-insert, a magnetic-attached, what details... I see good arguments for magnetic attach, but it's harder to make them small. I see good arguments for small, but those will be mechanical and less positively retained. I don't know that the discussion is a NANOG-centric one from here on in, but it's good to have raised the idea. -- -george william herbert george.herbert at gmail.com From streiner at cluebyfour.org Thu Dec 20 23:38:43 2012 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 20 Dec 2012 18:38:43 -0500 (EST) Subject: why haven't ethernet connectors changed? In-Reply-To: <50D356DB.5090809@mtcc.com> References: <50D356DB.5090809@mtcc.com> Message-ID: On Thu, 20 Dec 2012, Michael Thomas wrote: > I was looking at a Raspberry Pi board and was struck with how large the > ethernet > connector is in comparison to the board as a whole. It strikes me: ethernet > connectors haven't changed that I'm aware in pretty much 25 years. Every > other > cable has changed several times in that time frame. I imaging that if anybody > cared, ethernet cables could be many times smaller. Looking at wiring > closets, > etc, it seems like it might be a big win for density too. I've you've ever seen a truly 'dense' wiring closet, they are plenty dense already - dense enough that unplugging a single patch cable in a rack jammed full of switches is already a bit of a chore. > So why, oh why, nanog the omniscient do we still use rj45's? Inertia, for one thing. By that, I mean: 1. There hasn't been any real incentive to make the connectors smaller. 2. The installed base of copper Ethernet ports dwarfs pretty much anything except maybe POTS lines, and even there, different countries sometimes adopted their own standards. The costs of having to make physical changes to even a small portion of the installed cable plant would be unjustifiably prohibitive. There could also be some valid technical reasons: 1. The conductors really can't get any thinner. In fact, with Cat6A, they're somewhat thicker than Cat5E. 2. I would also think that the conductors/pins really can't get much closer together inside the connector shell, without cross-talk becoming more of a problem. I don't have any technical data to back this up at the moment, but it seems reasonable. 3. If assertions 1 and 2 are true, then the cable really can't get any thinner either. Again, if you look at Cat6A cable (especially shielded Cat6A), it is significantly thicker than Cat5E. jms From bedard.phil at gmail.com Fri Dec 21 00:05:42 2012 From: bedard.phil at gmail.com (Phil Bedard) Date: Thu, 20 Dec 2012 16:05:42 -0800 Subject: why haven't ethernet connectors changed? Message-ID: <-3301833184400096577@unknownmsgid> There have been some smaller connectors but nothing with widespread adoption. Tyco has something called RJ point 5 which uses standard UTP cable but looks like a squashed RJ 45 and has double the density. Wouldn't save much space on a Pi thigh its meant more for bulk applications. From: Michael Thomas Sent: 12/20/2012 13:21 To: NANOG list Subject: why haven't ethernet connectors changed? I was looking at a Raspberry Pi board and was struck with how large the ethernet connector is in comparison to the board as a whole. It strikes me: ethernet connectors haven't changed that I'm aware in pretty much 25 years. Every other cable has changed several times in that time frame. I imaging that if anybody cared, ethernet cables could be many times smaller. Looking at wiring closets, etc, it seems like it might be a big win for density too. So why, oh why, nanog the omniscient do we still use rj45's? Mike From deepak at ai.net Fri Dec 21 00:09:36 2012 From: deepak at ai.net (Deepak Jain) Date: Thu, 20 Dec 2012 19:09:36 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> Message-ID: <50D3A8C0.9000005@ai.net> > > There could also be some valid technical reasons: > 1. The conductors really can't get any thinner. In fact, with Cat6A, > they're somewhat thicker than Cat5E. > 2. I would also think that the conductors/pins really can't get much > closer together inside the connector shell, without cross-talk becoming > more of a problem. I don't have any technical data to back this up at > the moment, but it seems reasonable. > 3. If assertions 1 and 2 are true, then the cable really can't get any > thinner either. Again, if you look at Cat6A cable (especially shielded > Cat6A), it is significantly thicker than Cat5E. I'll chime in here. With POTS, where essentially each "circuit" is identical in capacity and usage type, the only way to improve density is via the physical media -- and even then, you are still limited by conductor sizes. With Ethernet, you've seen an evolution from 10MB/s to 10Gb/s. This begs the question of what density you need, and against uh, say, 1000x improvement in capacity, what meaningful change could you make in terms of connector density? Even 10:1 is meaningless noise against a speed improvement at the circuit layer. Lots of Ethernet is still run identically to the way POTS lines are run. Large cable pulls back to central wiring closets. This is part of the problem. If one chose to adopt a model where connections are multiplexed/aggregated closer to their source and the aggregation brings with it higher signalling speeds --- [Think top-of-rack switching vs end-of-row switching]. I'm not saying its useful for everyone, but the idea is that if density were your issue, there are much better physical ways to manage the data requirements than the POTS model. In our office spaces (albeit in data center buildings) we have individual rooms with 24/48 port ethernet switches dedicated to the room. These uplink via a redundant pair of fiber. This represents lots of copper not making it out to the end-of-hall wiring closet which is now just a passive WDM fiber aggregation point. [Consummate savings in copper, weight, complexity, and labor -- at no significantly higher hardware failure risk]. Fiber has solved the density problem in a way that copper hasn't and this may be in part to reduced concerns about cross-talk and thinner media. So with so many options to reduce the amount of copper you need, and the use of fiber to move large amounts of connectivity much longer distances and at higher speeds, why would you still want to implement a wiring closet with 2000 RJ-45s anymore -- and if you have the justification, what's another 5 square feet to make it happen against the costs you're already incurring? DJ From dave at temk.in Fri Dec 21 03:22:38 2012 From: dave at temk.in (David Temkin) Date: Thu, 20 Dec 2012 22:22:38 -0500 Subject: Reminder: NANOG 57 is the first Monday-Wednesday program Message-ID: NANOG Community, Just a reminder that the upcoming NANOG in Orlando, FL will be our first Monday to Wednesday program, beginning with tutorials on Monday morning at 9AM and concluding at approximately 6PM on Wednesday. There will be no program on Sunday. Best Regards, -Dave Temkin For the NANOG Program Committee From mysidia at gmail.com Fri Dec 21 03:48:31 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 20 Dec 2012 21:48:31 -0600 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <20121220071143.GA12392@pob.ytti.fi> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> Message-ID: On 12/20/12, Saku Ytti wrote: > On (2012-12-20 03:24 +0000), Blake Pfankuch wrote: [snip]> > For me, humans would not do much directly with the tool. They'd give it > large chunk of resource. Then maybe mine it to pools like 'coreLink', > 'coreLoop', 'custLink', 'custLAN' etc. > Then in your provisioning tools, you'd request resource from specific pool > via restful API. Humand would never manually write RD/RT/IP/VLAN in the [snip] A CMDB that tracks configuration items. An IP address is just one kind of CI out of thousands. A good CMDBs should ideally provide efficient management, visualization, and reporting for all kinds of CIs Software that tracks such things should understand the internal structure of every kind of CI it tracks, and be able to easily answer simple questions, (eg. Which VLAN ID is assigned to the subnet that IP address Y belongs to. If IP Address Y is part of a static NAT configuration, on a LAN router, what external IP address and external VLAN Id is this IP associated with?). But is there a decently scalable open source application for building a CMDB, that is visually appealing and efficient for humans to use, without a ton of manual development; other than custom building applications and SQL schema by hand, for each kind of CI? I am not aware of one.... -- -JH From george.herbert at gmail.com Fri Dec 21 04:01:07 2012 From: george.herbert at gmail.com (George Herbert) Date: Thu, 20 Dec 2012 20:01:07 -0800 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> Message-ID: On Thu, Dec 20, 2012 at 7:48 PM, Jimmy Hess wrote: ... > > But is there a decently scalable open source application for building > a CMDB, that is visually appealing and efficient for humans to use, > without a ton of manual development; other than custom building > applications and SQL schema by hand, for each kind of CI? > > I am not aware of one.... I have not seen one, and I've been at places that have spent man-years building custom apps and SQL schema by hand in the lack of an available open source tool. -- -george william herbert george.herbert at gmail.com From mysidia at gmail.com Fri Dec 21 05:16:40 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 20 Dec 2012 23:16:40 -0600 Subject: why haven't ethernet connectors changed? In-Reply-To: <20121220184104.GA46518@wakko.typo.org> References: <50D356DB.5090809@mtcc.com> <20121220184104.GA46518@wakko.typo.org> Message-ID: On 12/20/12, Wayne E Bouchard wrote: > Really, it will remain that way until the bandwidth needs from the > desktop begin to push the GE threshold. Until then, why bother > changing anything? When that does happen, it'll pretty well deal with > itself. At which point the 8P8C connectors on desktops and laptops changes from RJ45 to SFP+ cage with LC connector, or direct-attach SFP+ between laptop and "active" fabric extender in the nearby wall jack; fed by fiber, with 10G-SR optical... Because the copper spec for >1gig was 10GBase-CX4; much heavier than Cat5. And there won't be much tolerance for the copper 15 meter distance limit in any case. > -Wayne -- -JH From charles-lists at knownelement.com Fri Dec 21 05:26:52 2012 From: charles-lists at knownelement.com (Charles N Wyble) Date: Thu, 20 Dec 2012 23:26:52 -0600 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> Message-ID: <85fb3201-07f2-4a5b-a682-99507a2ba615@email.android.com> Zenoss works very well as a cmdb. George Herbert wrote: >On Thu, Dec 20, 2012 at 7:48 PM, Jimmy Hess wrote: >... >> >> But is there a decently scalable open source application for building >> a CMDB, that is visually appealing and efficient for humans to use, >> without a ton of manual development; other than custom building >> applications and SQL schema by hand, for each kind of CI? >> >> I am not aware of one.... > >I have not seen one, and I've been at places that have spent man-years >building custom apps and SQL schema by hand in the lack of an >available open source tool. > > >-- >-george william herbert >george.herbert at gmail.com -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From mysidia at gmail.com Fri Dec 21 06:01:08 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 21 Dec 2012 00:01:08 -0600 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <85fb3201-07f2-4a5b-a682-99507a2ba615@email.android.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <85fb3201-07f2-4a5b-a682-99507a2ba615@email.android.com> Message-ID: On 12/20/12, Charles N Wyble wrote: > Zenoss works very well as a cmdb. Zenoss is very visually appealing, but a monitoring system for network hosts, not a CMDB. In particular, except through extensive custom programming, I see no mechanism to manage CIs with it or query for facts... Zenoss doesn't seem to have any way you can represent or, query, or model a fact that a certain IP address terminates in Vlan X, on device Y, with default gateway IP G that has NSAP ID H, and device Y lives in building A room 1 aisle 2 rack 4 rack slot number 5, fed by breakers 186 and 237, with upstream Ethernet cable ID #G296R plugged into port 39 on patch panel 2, which lands on Switch K port Gig8/44. Networks have many "items of importance" that are not hosts, also, and are not readily modelled using SNMP. -- -JH From yuri at yurisk.info Fri Dec 21 07:33:58 2012 From: yuri at yurisk.info (Yuri Slobodyanyuk) Date: Fri, 21 Dec 2012 09:33:58 +0200 Subject: Check Point Firewall Appliances In-Reply-To: References: Message-ID: Having a love-and-hate relationship with Checkpoint firewalls after working for 6 years daily with them I am probably biased :), but will say they are great firewalls once you know to work with them . If you are completely new to it I'd recommend Checkpoint CCSA/CCSE from accredited APT course as the shortest path , Alternatives: - CBT Nuggets CCSA course , but last time I checked it was for NGX R65 that is substantially different from current versions, only if you can get it really cheap - Documentation from Checkpoint site (freely available to everyone) is the start-all end-all source (I did it this way) takes time but in the end you will have a through understanding of the product - Online is a good place once you know the basics. If, on the other hand, you don't know to do manual port-forwarding , Google will only suck your time. But for problems/inconsistencies/debug : http://cpug.org - Independent forum where you can always find advice from many knowledgeable and helpful folks ; http://www.cpshared.com/forums/ Same goes here - people who can configure route-based VPNs with policy-based routing with closed eyes hang around here https://forums.checkpoint.com/ Official support forums from Checkpoint, less active than 2 above HTH Yuri On Wed, Dec 19, 2012 at 9:35 PM, Blake Pfankuch wrote: > Howdy, > I am just getting into an environment with a large Check > Point deployment and I am looking for a little bit of feedback from other > real world admins. Looking for what people like, what people don't (why > hopefully). Also for those of you who might run Check Point devices in > your environments what to dig into first as far as getting more experience > on the devices and a better understanding of how not to break them. I am > slowly going through all of the official documentation, but would also like > to hear a real world opinion. > > Thanks in advance! > > Blake > -- Taking challenges one by one. http://yurisk.info From jasper at pointless.net Fri Dec 21 07:38:17 2012 From: jasper at pointless.net (Jasper Wallace) Date: Fri, 21 Dec 2012 07:38:17 +0000 (GMT) Subject: Gmail and SSL In-Reply-To: References: <50CB49F7.5050304@afxr.net> <50CB4B43.10803@alter3d.ca> <50CBB029.6050107@alter3d.ca> Message-ID: On Fri, 14 Dec 2012, Christopher Morrow wrote: > On Fri, Dec 14, 2012 at 6:03 PM, Peter Kristolaitis wrote: > > In my experience, free/cheap certs "not working" on some clients is, in > > 99.9% of cases, a misconfiguration error where the server isn't presenting > > the cert chain properly (usually omitting the intermediate cert), which > > works on some platforms (often because they include the intermediate certs > > to work around these kinds of problems) but not on others. Fixing the cert > > chain that's presented to the client has ALWAYS resolved these types of > > issues in my experience. > > and in the case of the original topic... if the gmail servers don't > accept StartSSL certs, please let me know I'll see about a fix. Tangentially to this: any chance of supporting TLSA/DANE records for _110._tcp.domain and _995._tcp.domain? (and the IMAP equivalents). That would let people carry on using self signed certs who prefer to and let people who have a cert that chains back to a root CA assert which root CA the cert should chain back to, which would be nice in these days of diginotar and comodo hacks... -- [http://pointless.net/] [0x2ECA0975] From eugen at leitl.org Fri Dec 21 09:59:07 2012 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 21 Dec 2012 10:59:07 +0100 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> Message-ID: <20121221095907.GR9750@leitl.org> On Thu, Dec 20, 2012 at 01:13:15PM -0800, George Herbert wrote: > I don't know that the discussion is a NANOG-centric one from here on > in, but it's good to have raised the idea. Something optical, like a >10 GBit/s SR version of TOSLINK would be nice. From aledm at qix.co.uk Fri Dec 21 12:08:14 2012 From: aledm at qix.co.uk (Aled Morris) Date: Fri, 21 Dec 2012 12:08:14 +0000 Subject: why haven't ethernet connectors changed? In-Reply-To: <20121221095907.GR9750@leitl.org> References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> <20121221095907.GR9750@leitl.org> Message-ID: On 21 December 2012 09:59, Eugen Leitl wrote: > > Something optical, like a >10 GBit/s SR version of TOSLINK > would be nice. > > Good luck with that! :-) Referring back to the original question and the reference to Raspberry Pi... The latest HDMI has Ethernet capability and the connector is already on the Pi, so there's a possible (future) solution that would work for all manner of consumer applications - even ones that don't need video or audio - just use the network capability of HDMI. Aled From jamie at photon.com Fri Dec 21 13:05:17 2012 From: jamie at photon.com (Jamie Bowden) Date: Fri, 21 Dec 2012 13:05:17 +0000 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com>, Message-ID: <465966A5F5B867419F604CD3E604C1E534F30406@PRA-DCA-MAIL.pra.ray.com> > From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] > I'm shocked there hasn't been a whisper of amphenol. As an rf guy, I > vote all connectors move to sma or bnc. I can then justify the cost of > a Walmart 10 foot cable for 25 dollars.. And if we gold plate them, we > can charge a premium. ;) Let's just use MTC thermocouple connectors everywhere and be done with it. Jamie From Matthew.Black at csulb.edu Fri Dec 21 14:53:22 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Fri, 21 Dec 2012 14:53:22 +0000 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D356DB.5090809@mtcc.com> References: <50D356DB.5090809@mtcc.com> Message-ID: Are you talking about the "N" connectors with those 802.3 transceiver cables, BNC connectors (10Base5), or an Type RJ45 (10Base-T) telco style connector? I couldn't find anyone selling multi-step thicknet strippers in the late 1980s, so I had to use a Xacto knife to prepare thicknet cable and then crimp about 20 N connectors. Data General donated 8 workstations and CAD circuit-design software to our University. The workstations used N-style transceivers instead of those with vampire taps. What a nightmare! )-; matthew black california state university, long beach -----Original Message----- From: Michael Thomas [mailto:mike at mtcc.com] Sent: Thursday, December 20, 2012 10:20 AM To: NANOG list Subject: why haven't ethernet connectors changed? I was looking at a Raspberry Pi board and was struck with how large the ethernet connector is in comparison to the board as a whole. It strikes me: ethernet connectors haven't changed that I'm aware in pretty much 25 years. Every other cable has changed several times in that time frame. I imaging that if anybody cared, ethernet cables could be many times smaller. Looking at wiring closets, etc, it seems like it might be a big win for density too. So why, oh why, nanog the omniscient do we still use rj45's? Mike From Matthew.Black at csulb.edu Fri Dec 21 14:57:21 2012 From: Matthew.Black at csulb.edu (Matthew Black) Date: Fri, 21 Dec 2012 14:57:21 +0000 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> Message-ID: http://www.blackbox.com/Store/Detail.aspx/Ethernet-Transceiver-Cable-Office-Environment-PVC-IEEE-802-3-Right-Angle-Connector-3-ft-0-9-m/LCN216%C4%820003 Only $55.95 for a 3-foot transceiver cable. What was more surprising is that Black Box is still around. matthew black california state university, long beach -----Original Message----- From: Michael Thomas [mailto:mike at mtcc.com] Sent: Thursday, December 20, 2012 10:20 AM To: NANOG list Subject: why haven't ethernet connectors changed? I was looking at a Raspberry Pi board and was struck with how large the ethernet connector is in comparison to the board as a whole. It strikes me: ethernet connectors haven't changed that I'm aware in pretty much 25 years. Every other cable has changed several times in that time frame. I imaging that if anybody cared, ethernet cables could be many times smaller. Looking at wiring closets, etc, it seems like it might be a big win for density too. So why, oh why, nanog the omniscient do we still use rj45's? Mike From bruns at 2mbit.com Fri Dec 21 15:15:48 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 21 Dec 2012 08:15:48 -0700 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> Message-ID: <5D6EBDAE-03D1-4D07-B204-9BB99C621873@2mbit.com> Some of us still have a stock of legacy gear and cables - things like v35 cables for connecting to CSU/DSUs, and even the occasional AUI hub. :) You wouldn't believe how much people will pay for legacy computer gear when they need it to keep their business going. -- Brielle Sent from my iPhone On Dec 21, 2012, at 7:57 AM, Matthew Black wrote: > http://www.blackbox.com/Store/Detail.aspx/Ethernet-Transceiver-Cable-Office-Environment-PVC-IEEE-802-3-Right-Angle-Connector-3-ft-0-9-m/LCN216%C4%820003 > > Only $55.95 for a 3-foot transceiver cable. What was more surprising is that Black Box is still around. > > > matthew black > california state university, long beach > > > -----Original Message----- > From: Michael Thomas [mailto:mike at mtcc.com] > Sent: Thursday, December 20, 2012 10:20 AM > To: NANOG list > Subject: why haven't ethernet connectors changed? > > I was looking at a Raspberry Pi board and was struck with how large the ethernet > connector is in comparison to the board as a whole. It strikes me: ethernet > connectors haven't changed that I'm aware in pretty much 25 years. Every other > cable has changed several times in that time frame. I imaging that if anybody > cared, ethernet cables could be many times smaller. Looking at wiring closets, > etc, it seems like it might be a big win for density too. > > So why, oh why, nanog the omniscient do we still use rj45's? > > Mike > > > > > > > From pdagog at gmail.com Fri Dec 21 12:28:52 2012 From: pdagog at gmail.com (Pierre DAVID) Date: Fri, 21 Dec 2012 13:28:52 +0100 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> Message-ID: <20121221122852.GE23371@vagabond.ma.maison> On Wed, Dec 19, 2012 at 09:09:40PM -0600, Beavis wrote: > +1 for ipplan http://iptrack.sourceforge.net/ > May I suggest Netmagis http://netmagis.org ? Pierre P.S.: I'm one of the authors From dot at dotat.at Fri Dec 21 15:19:30 2012 From: dot at dotat.at (Tony Finch) Date: Fri, 21 Dec 2012 15:19:30 +0000 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> Message-ID: Tom Morris wrote: > > Boy would I ever love an ethernet connector that works like Apple's > MagSafe... I guess a magsafe ethernet connector would have too much noise (owing to poor quality connection) to provide decently high bandwidth. This thread reminds me of http://fanf.livejournal.com/96172.html Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From david at mailplus.nl Fri Dec 21 15:26:41 2012 From: david at mailplus.nl (MailPlus| David Hofstee) Date: Fri, 21 Dec 2012 16:26:41 +0100 Subject: Contact person for doh.state.fl.us In-Reply-To: References: <78C35D6C1A82D243B830523B4193CF5F5E8D751AD6@SBS1.blinker.local> Message-ID: <78C35D6C1A82D243B830523B4193CF5F5E8D829B42@SBS1.blinker.local> Hi, Thanks for the contact info. There is a slight detail that you may have missed (I'm pretty sure it is not our reputation that is an issue). 1/256th part of the internet is being blocked. We are not the owner of 46.0.0.0/8. David P.S. The honeypot stuff was a typo by someone at a fair. He entered a .nl domain when it should have been .com ; the .nl domain was given to honeypot. The same contact was also registered later with the .com extension. Sometimes stupidity overcomes malice. -----Oorspronkelijk bericht----- Van: askoorb at gmail.com [mailto:askoorb at gmail.com] Namens Alex Brooks Verzonden: donderdag 20 december 2012 13:54 Aan: MailPlus| David Hofstee Onderwerp: Re: Contact person for doh.state.fl.us Hi, On Thu, Dec 20, 2012 at 9:46 AM, MailPlus| David Hofstee wrote: > Hi, > > > > Does anyone know a contact for doh.state.fl.us? I tried to contact them after we received this interesting line of logfile: > > > > "554 5.7.1 46.31.52.10 (in 46.0.0.0/8) is blacklisted." received from > mx5201.doh.state.fl.us (74.174.235.12) > > Thanks in advance, > > David Hofstee > MailPlus B.V. Netherlands Well, it's InformationTechnology at doh.state.fl.us but if you're blacklisted that's not going to help you. Fist off, this is probably because they think you are spamming. Have a look at http://www.projecthoneypot.org/ip_46.31.52.11 and http://ip.robtex.com/46.31.52.11.html#blacklists Once you have sorted that out, then you can try getting in touch if they haven't unblocked you. Try ringing +1-850-245-4233 and asking to speak to the 'service desk' about an 'email issue'. If that doesn't work, try +1-850-245-4975 then +1-850-245-5813. These are all numbers for their IT service; the first is the main number, then infrastructure support, then application support. If that doesn't work, nicholas.platt at dms.myflorida.com is involved in the management of the Florida Government's links to the Internet; he should be able to forward you to the right people. As a last resort, you can try their IT contractor, Hayes Computer Services on +1-850-297-0551. I wish you the best of luck, do post back and let everyone know if you get in touch. Alex From cabenth at gmail.com Fri Dec 21 15:34:09 2012 From: cabenth at gmail.com (eric clark) Date: Fri, 21 Dec 2012 07:34:09 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: <5D6EBDAE-03D1-4D07-B204-9BB99C621873@2mbit.com> References: <50D356DB.5090809@mtcc.com> <5D6EBDAE-03D1-4D07-B204-9BB99C621873@2mbit.com> Message-ID: You didn't include RJ11 in your question.... it goes back further. One reason is that as we push the limits of cable from CAT3 (10meg) to CAT5 (100meg) to 5E (gig) to 6 (not sure what that was for) to 7 (10gig), the cable doesn't get any smaller. We're dealing with higher and higher frequencies of changes on the wire. This makes cross talk and interference a bigger problem, so the twists and insulation are more important to try to protect from those issues (sometimes shielding). So the cable hasn't gotten any smaller. The connector works well enough and allows for these distances to be maintained. Some vendors have found ways to maintain the twists farther into the RJ45 by essentially using traces and not just lining the 8 wires up in parallel but stacking them in a staggered fashion... Obviously, a new connector could have been found, but why haven't we changed the C13 that HP came up with (at least I think they did) back in the 50s? Its still the defacto standard for all computer input power. As a matter of fact, most NEMA specs haven't changed since they were created... If it ain't broke, don't fix it. The only problem with the RJ45 is the hook. E On Fri, Dec 21, 2012 at 7:15 AM, Brielle Bruns wrote: > Some of us still have a stock of legacy gear and cables - things like v35 > cables for connecting to CSU/DSUs, and even the occasional AUI hub. :) > > You wouldn't believe how much people will pay for legacy computer gear > when they need it to keep their business going. > > -- > Brielle > > Sent from my iPhone > > On Dec 21, 2012, at 7:57 AM, Matthew Black > wrote: > > > > http://www.blackbox.com/Store/Detail.aspx/Ethernet-Transceiver-Cable-Office-Environment-PVC-IEEE-802-3-Right-Angle-Connector-3-ft-0-9-m/LCN216%C4%820003 > > > > Only $55.95 for a 3-foot transceiver cable. What was more surprising is > that Black Box is still around. > > > > > > matthew black > > california state university, long beach > > > > > > -----Original Message----- > > From: Michael Thomas [mailto:mike at mtcc.com] > > Sent: Thursday, December 20, 2012 10:20 AM > > To: NANOG list > > Subject: why haven't ethernet connectors changed? > > > > I was looking at a Raspberry Pi board and was struck with how large the > ethernet > > connector is in comparison to the board as a whole. It strikes me: > ethernet > > connectors haven't changed that I'm aware in pretty much 25 years. Every > other > > cable has changed several times in that time frame. I imaging that if > anybody > > cared, ethernet cables could be many times smaller. Looking at wiring > closets, > > etc, it seems like it might be a big win for density too. > > > > So why, oh why, nanog the omniscient do we still use rj45's? > > > > Mike > > > > > > > > > > > > > > > > From mike at mtcc.com Fri Dec 21 16:04:45 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 21 Dec 2012 08:04:45 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> <20121221095907.GR9750@leitl.org> Message-ID: <50D4889D.1050505@mtcc.com> On 12/21/2012 04:08 AM, Aled Morris wrote: > Good luck with that! :-) Referring back to the original question and the reference to Raspberry Pi... The latest HDMI has Ethernet capability and the connector is already on the Pi, so there's a possible (future) solution that would work for all manner of consumer applications - even ones that don't need video or audio - just use the network capability of HDMI. Aled Interesting. I'd turn this back the other way though: in this day and age, why do we have any interconnection/bus that isn't just ethernet/IP? IP, as we all know, doesn't imply global reachability. What we far too often do with specialized IO channels is recreate networking, usually poorly. That too would solve the Raspberry Pi problem. Mike, naming being one big issue which is getting short-shrift in homenet From george.herbert at gmail.com Fri Dec 21 16:21:45 2012 From: george.herbert at gmail.com (George Herbert) Date: Fri, 21 Dec 2012 08:21:45 -0800 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <85fb3201-07f2-4a5b-a682-99507a2ba615@email.android.com> Message-ID: <989001DE-312E-4A26-ABC0-50F4A65D137F@gmail.com> On Dec 20, 2012, at 10:01 PM, Jimmy Hess wrote: > On 12/20/12, Charles N Wyble wrote: >> Zenoss works very well as a cmdb. > > Zenoss is very visually appealing, but a monitoring system for network > hosts, not a CMDB. > > In particular, except through extensive custom programming, I see no > mechanism to manage CIs with it or query for facts... > > Zenoss doesn't seem to have any way you can represent or, query, or > model a fact that a certain IP address terminates in Vlan X, on > device Y, with default gateway IP G that has NSAP ID H, and device Y > lives in building A room 1 aisle 2 rack 4 rack slot number 5, > fed by breakers 186 and 237, with upstream Ethernet cable ID #G296R > plugged into port 39 on patch panel 2, which lands on Switch K > port Gig8/44. > Networks have many "items of importance" that are not hosts, also, > and are not readily modelled using SNMP. Much less the application layer, physical SW installs or logical groupings layer, or a virtual hosts or internal cloud stack layer. Or tie ins to the release management or DevOps control layer. I know this is NANOG, but configuration control runs a ways up the stack... A proper CMDB will have to be able to take a much bigger picture. Not to slight Zenoss; it's good at what it does do. But that's not a CMDB. That is not to suggest that products that handle a limited slice of the stack in a more organized manner are not valuable. Every little bit helps, in the current absence of a delivered off-the-shelf comprehensive product. But if you've ever watched a comprehensive product run, partnered with a systems deploy tool with all the business logic on physical anti-affinity for power, rack, network layers, ... Provisioning a 1000+ node, 60+ server types app environment into a data center with one command line, selected, booted, network side VLANs allocated and configured, apps installed, apps configured, and ready for traffic... The data to be able to pull that off can be gathered and can be managed and used effectively. That's the power of a real, comprehensive CMDB. George William Herbert Sent from my iPhone From bill at herrin.us Fri Dec 21 16:22:18 2012 From: bill at herrin.us (William Herrin) Date: Fri, 21 Dec 2012 11:22:18 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <20121220184104.GA46518@wakko.typo.org> Message-ID: On Fri, Dec 21, 2012 at 12:16 AM, Jimmy Hess wrote: > At which point the 8P8C connectors on desktops and laptops changes > from RJ45 to > SFP+ cage with LC connector, or direct-attach SFP+ between > laptop and "active" fabric extender in the nearby wall jack; fed > by fiber, with 10G-SR optical... Don't bet on fiber to the desktop making any inroads before Amp's patents on their Lightcrimp Plus system expire. They're the only ones to get close to making field termination of fiber a casual task with a low barrier to entry and they're dead set on making the Iomega mistake. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Fri Dec 21 16:35:51 2012 From: bill at herrin.us (William Herrin) Date: Fri, 21 Dec 2012 11:35:51 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> Message-ID: On Fri, Dec 21, 2012 at 10:19 AM, Tony Finch wrote: > I guess a magsafe ethernet connector would have too much noise (owing to > poor quality connection) to provide decently high bandwidth. I don't see why a magsafe connection would be any more or less noisy than an rj45. They both follow the same principle: spring tension to hold the contacts together. The main issues with magsafe are: 1. You can't have very many pins before the power of the magnet necessary to overcome the spring tension approaches the ridiculous. 2. Past about two magsafe connections to a machine, cable tangle will cause them to frequently pull loose. 3. RJ45 implements spring tension the simple and cheap way. Magsafe does it the complicated and expensive way. You can pretty much forget about field termination. Want some entertainment? Read this article on repairing a magsafe connector: http://www.ifixit.com/Guide/Repairing+MagSafe+Connector/1753/1 Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Fri Dec 21 16:37:28 2012 From: bill at herrin.us (William Herrin) Date: Fri, 21 Dec 2012 11:37:28 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <5D6EBDAE-03D1-4D07-B204-9BB99C621873@2mbit.com> Message-ID: On Fri, Dec 21, 2012 at 10:34 AM, eric clark wrote: > If it ain't broke, don't fix it. The only problem with the RJ45 is the hook. That's what cable boots are for. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From SNaslund at medline.com Fri Dec 21 16:43:13 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 21 Dec 2012 10:43:13 -0600 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> Please, no connectors that do not lock into place. Is plugging in the RJ-45 that much of a task? Most portable devices are going wireless in any case so they are not an issue. The RJ-45 has worked OK for me. The AUI connectors have a special place in networking hell. What an incredibly horrible mechanical design they were? The flip side of the question is why you think the RJ-45 should change. You could argue that you don't usually need all eight wires but every time we tried that argument someone came up with a compelling reason to use more wires. I like that it is very standard. In the fiber world it is a continuous issue of hybrid patch cords dealing with ST,SC,LC and all the other variants out there. It would be a huge nightmare if the same thing happened with copper Ethernet. I am also not a huge fan of the USB connector because I have seen a lot of those break and there is no positive retention. Magnetic is cute but has no place in a datacenter and even with desktops I can picture a lot of support calls because someone bumps a wire that knocks the mag connector out of place. I really hate dongles of all types but I guess you don't really have a choice with devices so physically thin that you can't get the jack in there. I think I will keep the RJ for now. Steven Naslund -----Original Message----- From: Aled Morris [mailto:aledm at qix.co.uk] Sent: Thursday, December 20, 2012 12:38 PM To: Michael Thomas Cc: NANOG list Subject: Re: why haven't ethernet connectors changed? On 20 December 2012 18:20, Michael Thomas wrote > ethernet > connectors haven't changed that I'm aware in pretty much 25 years. 15-pin D-type AUI connectors with slide latches? BNC for thinwire? I do agree though, something more like mini-USB would be more appropriate for home Ethernet use. Aled From matthew at matthew.at Thu Dec 20 23:20:18 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 20 Dec 2012 15:20:18 -0800 Subject: Fiber only in DataCenters? In-Reply-To: <50CF54C0.9010106@bogus.com> References: <50CF54C0.9010106@bogus.com> Message-ID: <50D39D32.4010900@matthew.at> On 12/17/2012 9:22 AM, joel jaeggli wrote: > If the facility is big enough the utility of twisted pair becomes > quite limited, both due to distance and differing electrical > potential, multibuilding campuses in particular make this is a > nonstarter. For twisted-pair Ethernet: Distance yes. Differing electrical potential no. It is a balanced pair, transformer coupled at both ends. As long as AC common-mode pickup doesn't saturate the transformer core, it just works. > > In one facility I'm in, I'm over 300 meters from each of the MMRs, > with the results that the OOB for the serial console server for out > equipment located out there in the MMR's being on serial over fiber > transceivers connected by om4 multimode. RS232 serial is another story. Here the potential difference between the ends is a big deal. (I've even seen burned-through PC boards from what happens when pin 7 has 220 VAC flowing from one device to the other) But you can just run Ethernet out to the console server and plug it in next to the gear with the serial port to fix this. Matthew Kaufman From dot at dotat.at Fri Dec 21 17:29:35 2012 From: dot at dotat.at (Tony Finch) Date: Fri, 21 Dec 2012 17:29:35 +0000 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D4889D.1050505@mtcc.com> References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> <20121221095907.GR9750@leitl.org> <50D4889D.1050505@mtcc.com> Message-ID: Michael Thomas wrote: > > I'd turn this back the other way though: in this day and age, why do we > have any interconnection/bus that isn't just ethernet/IP? The need for isochronous transmission and more bandwidth. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From EWieling at nyigc.com Fri Dec 21 17:30:00 2012 From: EWieling at nyigc.com (Eric Wieling) Date: Fri, 21 Dec 2012 12:30:00 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> Message-ID: <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> The only thing I would change about RJ-45 is a longer tab (but make it optional) for when you care more about ease of removal than cable tangles. Polycom phones are hell to try and unplug the RJ-45, for example. -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Friday, December 21, 2012 11:43 AM To: nanog at nanog.org Subject: RE: why haven't ethernet connectors changed? Please, no connectors that do not lock into place. Is plugging in the RJ-45 that much of a task? Most portable devices are going wireless in any case so they are not an issue. The RJ-45 has worked OK for me. The AUI connectors have a special place in networking hell. What an incredibly horrible mechanical design they were? The flip side of the question is why you think the RJ-45 should change. You could argue that you don't usually need all eight wires but every time we tried that argument someone came up with a compelling reason to use more wires. I like that it is very standard. In the fiber world it is a continuous issue of hybrid patch cords dealing with ST,SC,LC and all the other variants out there. It would be a huge nightmare if the same thing happened with copper Ethernet. I am also not a huge fan of the USB connector because I have seen a lot of those break and there is no positive retention. Magnetic is cute but has no place in a datacenter and even with desktops I can picture a lot of support calls because someone bumps a wire that knocks the mag connector out of place. I really hate dongles of all types but I guess you don't really have a choice with devices so physically thin that you can't get the jack in there. I think I will keep the RJ for now. Steven Naslund -----Original Message----- From: Aled Morris [mailto:aledm at qix.co.uk] Sent: Thursday, December 20, 2012 12:38 PM To: Michael Thomas Cc: NANOG list Subject: Re: why haven't ethernet connectors changed? On 20 December 2012 18:20, Michael Thomas wrote > ethernet > connectors haven't changed that I'm aware in pretty much 25 years. 15-pin D-type AUI connectors with slide latches? BNC for thinwire? I do agree though, something more like mini-USB would be more appropriate for home Ethernet use. Aled From mike at mtcc.com Fri Dec 21 17:51:19 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 21 Dec 2012 09:51:19 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> <20121221095907.GR9750@leitl.org> <50D4889D.1050505@mtcc.com> Message-ID: <50D4A197.4070405@mtcc.com> On 12/21/2012 09:29 AM, Tony Finch wrote: > Michael Thomas wrote: >> I'd turn this back the other way though: in this day and age, why do we >> have any interconnection/bus that isn't just ethernet/IP? > The need for isochronous transmission and more bandwidth. > > That's why G*d invented RTP, of course. And all of these buses are "slow" by the time they're popular enough to worry about. In any case, delete the "ethernet" part if you want to still play with the mac/phy. Mike From lists at beatmixed.com Fri Dec 21 18:03:02 2012 From: lists at beatmixed.com (Matt Hite) Date: Fri, 21 Dec 2012 10:03:02 -0800 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1355421251.52703.YahooMailRC@web181604.mail.ne1.yahoo.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <50C9ACFC.1050004@foobar.org> <1355421251.52703.YahooMailRC@web181604.mail.ne1.yahoo.com> Message-ID: Racktables does support IPv6. http://demo.racktables.org/ Login: admin PW: admin On Thu, Dec 13, 2012 at 9:54 AM, Eric A Louie wrote: > Racktables = no IPv6. Bummer, and it does more than what I need. > > Netdot looks very interesting. It didn't show up when I searched for > "IPAM". > I'll have to evaluate it, to see if it does any kind of wireless > documentation > (frequency, modulation, etc) > > Any Netdot users out there who want to comment? > > Much appreciated, Eric > > > > > ________________________________ > From: Nick Hilliard > To: Aftab Siddiqui > Cc: Eric A Louie ; NANOG Operators' Group < > nanog at nanog.org> > Sent: Thu, December 13, 2012 2:25:10 AM > Subject: Re: IP Address Management IPAM software for small ISP > > On 13/12/2012 10:10, Aftab Siddiqui wrote: > > nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The > > first one I assume should serve your purpose for both v4 and v6. > > I've had a lot more success with Racktables and Netdot, both of which are > really good at what they do. Racktables in particular. > > Nick > From cmadams at hiwaay.net Fri Dec 21 18:22:08 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 21 Dec 2012 12:22:08 -0600 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D4A197.4070405@mtcc.com> References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> <20121221095907.GR9750@leitl.org> <50D4889D.1050505@mtcc.com> <50D4A197.4070405@mtcc.com> Message-ID: <20121221182208.GC13594@hiwaay.net> Once upon a time, Michael Thomas said: > That's why G*d invented RTP, of course. And all of these buses are "slow" > by the time they're popular enough to worry about. In any case, delete > the "ethernet" part if you want to still play with the mac/phy. Well, the reply was sent in response to somebody talking about HDMI. HDMI 1.4 can carry over 8 gigabits per second, so to re-use ethernet PHY (and still be copper) you'd have to go with 10GBaseT. The cheapest 10GBaseT card I see at a glance is over $400, while I can find Blu-Ray players with HDMI 1.4 (and oh yeah, an optical drive, video decoder, etc.) for under $100. I'm sure some of that price difference is related to manufacturing volume, but I don't think it is that big of a percentage. I will say that one nice thing about having different connectors for different protocols (on consumer devices anyway) is that you don't have to worry about somebody plugging the Internet into the "Video 1" port and wondering why they aren't getting a picture. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From george.herbert at gmail.com Fri Dec 21 18:54:23 2012 From: george.herbert at gmail.com (George Herbert) Date: Fri, 21 Dec 2012 10:54:23 -0800 Subject: Fiber only in DataCenters? In-Reply-To: <50D39D32.4010900@matthew.at> References: <50CF54C0.9010106@bogus.com> <50D39D32.4010900@matthew.at> Message-ID: On Thu, Dec 20, 2012 at 3:20 PM, Matthew Kaufman wrote: > On 12/17/2012 9:22 AM, joel jaeggli wrote: >> >> If the facility is big enough the utility of twisted pair becomes quite >> limited, both due to distance and differing electrical potential, >> multibuilding campuses in particular make this is a nonstarter. > > > For twisted-pair Ethernet: Distance yes. Differing electrical potential no. > It is a balanced pair, transformer coupled at both ends. As long as AC > common-mode pickup doesn't saturate the transformer core, it just works. ...Up to certain limits of DC / ground differential between the ends, at which one can cause sparks anyways. Yes, the POTS telcos use 48V in the same or lower quality wire pairs, and the various CatN wires should be able to take it, and the connectors. I'm not sure whether the sparks were from 110 or 220 V of differential, but I saw sparks. >> In one facility I'm in, I'm over 300 meters from each of the MMRs, with >> the results that the OOB for the serial console server for out equipment >> located out there in the MMR's being on serial over fiber transceivers >> connected by om4 multimode. > > > RS232 serial is another story. Here the potential difference between the > ends is a big deal. (I've even seen burned-through PC boards from what > happens when pin 7 has 220 VAC flowing from one device to the other) But you > can just run Ethernet out to the console server and plug it in next to the > gear with the serial port to fix this. > > Matthew Kaufman Ah, yes, those magic smokes. -- -george william herbert george.herbert at gmail.com From cscora at apnic.net Fri Dec 21 18:54:41 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 Dec 2012 04:54:41 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201212211854.qBLIsfn2026888@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 22 Dec, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 438165 Prefixes after maximum aggregation: 180937 Deaggregation factor: 2.42 Unique aggregates announced to Internet: 215621 Total ASes present in the Internet Routing Table: 42906 Prefixes per ASN: 10.21 Origin-only ASes present in the Internet Routing Table: 33973 Origin ASes announcing only one prefix: 15870 Transit ASes present in the Internet Routing Table: 5700 Transit-only ASes present in the Internet Routing Table: 138 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 31 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 1211 Unregistered ASNs in the Routing Table: 437 Number of 32-bit ASNs allocated by the RIRs: 3595 Number of 32-bit ASNs visible in the Routing Table: 3233 Prefixes from 32-bit ASNs in the Routing Table: 8730 Special use prefixes present in the Routing Table: 15 Prefixes being announced from unallocated address space: 175 Number of addresses announced to Internet: 2620290828 Equivalent to 156 /8s, 46 /16s and 119 /24s Percentage of available address space announced: 70.8 Percentage of allocated address space announced: 70.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.1 Total number of prefixes smaller than registry allocations: 154819 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 105281 Total APNIC prefixes after maximum aggregation: 32772 APNIC Deaggregation factor: 3.21 Prefixes being announced from the APNIC address blocks: 106205 Unique aggregates announced from the APNIC address blocks: 43419 APNIC Region origin ASes present in the Internet Routing Table: 4807 APNIC Prefixes per ASN: 22.09 APNIC Region origin ASes announcing only one prefix: 1243 APNIC Region transit ASes present in the Internet Routing Table: 792 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 389 Number of APNIC addresses announced to Internet: 716469376 Equivalent to 42 /8s, 180 /16s and 116 /24s Percentage of available APNIC address space announced: 83.7 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: 156086 Total ARIN prefixes after maximum aggregation: 78438 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 156771 Unique aggregates announced from the ARIN address blocks: 70691 ARIN Region origin ASes present in the Internet Routing Table: 15356 ARIN Prefixes per ASN: 10.21 ARIN Region origin ASes announcing only one prefix: 5800 ARIN Region transit ASes present in the Internet Routing Table: 1591 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 18 Number of ARIN addresses announced to Internet: 1089414016 Equivalent to 64 /8s, 239 /16s and 35 /24s Percentage of available ARIN address space announced: 57.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 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: 112749 Total RIPE prefixes after maximum aggregation: 58303 RIPE Deaggregation factor: 1.93 Prefixes being announced from the RIPE address blocks: 115652 Unique aggregates announced from the RIPE address blocks: 74554 RIPE Region origin ASes present in the Internet Routing Table: 17002 RIPE Prefixes per ASN: 6.80 RIPE Region origin ASes announcing only one prefix: 8144 RIPE Region transit ASes present in the Internet Routing Table: 2761 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 31 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2091 Number of RIPE addresses announced to Internet: 650235364 Equivalent to 38 /8s, 193 /16s and 205 /24s Percentage of available RIPE address space announced: 94.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: 45459 Total LACNIC prefixes after maximum aggregation: 9016 LACNIC Deaggregation factor: 5.04 Prefixes being announced from the LACNIC address blocks: 49029 Unique aggregates announced from the LACNIC address blocks: 23167 LACNIC Region origin ASes present in the Internet Routing Table: 1751 LACNIC Prefixes per ASN: 28.00 LACNIC Region origin ASes announcing only one prefix: 493 LACNIC Region transit ASes present in the Internet Routing Table: 336 Average LACNIC Region AS path length visible: 4.6 Max LACNIC Region AS path length visible: 30 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 729 Number of LACNIC addresses announced to Internet: 120904232 Equivalent to 7 /8s, 52 /16s and 218 /24s Percentage of available LACNIC address space announced: 72.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 9738 Total AfriNIC prefixes after maximum aggregation: 2355 AfriNIC Deaggregation factor: 4.14 Prefixes being announced from the AfriNIC address blocks: 10333 Unique aggregates announced from the AfriNIC address blocks: 3634 AfriNIC Region origin ASes present in the Internet Routing Table: 588 AfriNIC Prefixes per ASN: 17.57 AfriNIC Region origin ASes announcing only one prefix: 190 AfriNIC Region transit ASes present in the Internet Routing Table: 130 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: 42899456 Equivalent to 2 /8s, 142 /16s and 152 /24s Percentage of available AfriNIC address space announced: 42.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2926 11556 908 Korea Telecom (KIX) 17974 2488 829 54 PT TELEKOMUNIKASI INDONESIA 7545 1816 301 89 TPG Internet Pty Ltd 4755 1661 381 174 TATA Communications formerly 9829 1415 1156 42 BSNL National Internet Backbo 9583 1182 88 502 Sify Limited 7552 1148 1070 12 Vietel Corporation 4808 1123 2040 316 CNCGROUP IP network: China169 9498 1038 307 69 BHARTI Airtel Ltd. 24560 1037 385 161 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 7029 3473 1010 215 Windstream Communications Inc 6389 3120 3717 132 bellsouth.net, inc. 18566 2081 382 180 Covad Communications 22773 1947 2932 131 Cox Communications, Inc. 1785 1941 678 125 PaeTec Communications, Inc. 20115 1692 1608 622 Charter Communications 4323 1596 1155 396 Time Warner Telecom 30036 1382 292 716 Mediacom Communications Corp 7018 1293 10533 854 AT&T WorldNet Services 7011 1206 321 685 Citizens Utilities 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 1756 544 16 Corbina telecom 2118 1052 97 15 EUnet/RELCOM Autonomous Syste 34984 884 211 230 BILISIM TELEKOM 12479 869 777 64 Uni2 Autonomous System 13188 765 95 121 Educational Network 31148 743 38 15 FreeNet ISP 20940 725 238 564 Akamai Technologies European 6830 714 2313 435 UPC Distribution Services 58113 633 70 378 LIR DATACENTER TELECOM SRL 8551 619 367 39 Bezeq International 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 10620 2268 387 206 TVCABLE BOGOTA 28573 2249 1298 69 NET Servicos de Comunicao S.A 7303 1674 1139 202 Telecom Argentina Stet-France 8151 1574 2970 352 UniNet S.A. de C.V. 6503 1453 435 67 AVANTEL, S.A. 27947 766 85 94 Telconet S.A 18881 740 716 18 Global Village Telecom 3816 662 309 71 Empresa Nacional de Telecomun 11172 601 86 66 Servicios Alestra S.A de C.V 7738 588 1242 34 Telecomunicacoes da Bahia 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 24863 874 275 36 LINKdotNET AS number 36998 749 48 3 MOBITEL 8452 557 958 13 TEDATA 6713 485 602 20 Itissalat Al-MAGHRIB 24835 291 80 8 RAYA Telecom - Egypt 3741 267 906 225 The Internet Solution 12258 194 28 66 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 181 697 88 MTN Network Solutions 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 7029 3473 1010 215 Windstream Communications Inc 6389 3120 3717 132 bellsouth.net, inc. 4766 2926 11556 908 Korea Telecom (KIX) 17974 2488 829 54 PT TELEKOMUNIKASI INDONESIA 10620 2268 387 206 TVCABLE BOGOTA 28573 2249 1298 69 NET Servicos de Comunicao S.A 18566 2081 382 180 Covad Communications 22773 1947 2932 131 Cox Communications, Inc. 1785 1941 678 125 PaeTec Communications, Inc. 7545 1816 301 89 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3120 2988 bellsouth.net, inc. 17974 2488 2434 PT TELEKOMUNIKASI INDONESIA 28573 2249 2180 NET Servicos de Comunicao S.A 10620 2268 2062 TVCABLE BOGOTA 4766 2926 2018 Korea Telecom (KIX) 18566 2081 1901 Covad Communications 22773 1947 1816 Cox Communications, Inc. 1785 1941 1816 PaeTec Communications, Inc. 8402 1756 1740 Corbina telecom 7545 1816 1727 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 61309 UNALLOCATED 5.1.96.0/21 41562 Host4all Sarl 59505 UNALLOCATED 5.2.65.0/24 50673 Serverius AS 59505 UNALLOCATED 5.2.66.0/24 50673 Serverius AS 59530 UNALLOCATED 5.8.182.0/24 31261 GARS Telecom 61408 UNALLOCATED 5.56.0.0/21 174 Cogent Communication 61395 UNALLOCATED 5.83.56.0/22 3292 TDC Tele Danmark 61395 UNALLOCATED 5.83.60.0/22 3292 TDC Tele Danmark 59414 UNALLOCATED 5.102.144.0/21 15576 Nextra backbone in D 59395 UNALLOCATED 5.133.16.0/21 3549 Global Crossing 59407 UNALLOCATED 5.134.16.0/21 51167 Giga-Hosting GmbH 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.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 >>UNKNOWN<< Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.112.114.0/24 23884 Proimage Engineering and Comm 41.222.80.0/21 37110 Moztel LDA 41.223.108.0/22 36966 >>UNKNOWN<< 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.66.32.0/20 18864 >>UNKNOWN<< 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. 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:18 /9:13 /10:29 /11:87 /12:244 /13:477 /14:858 /15:1544 /16:12488 /17:6566 /18:10963 /19:21629 /20:30998 /21:33005 /22:44366 /23:40789 /24:229935 /25:1310 /26:1688 /27:856 /28:182 /29:81 /30:17 /31:0 /32:22 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2728 3473 Windstream Communications Inc 18566 2031 2081 Covad Communications 6389 1775 3120 bellsouth.net, inc. 8402 1481 1756 Corbina telecom 30036 1285 1382 Mediacom Communications Corp 22773 1279 1947 Cox Communications, Inc. 11492 1156 1193 Cable One 1785 1023 1941 PaeTec Communications, Inc. 6503 980 1453 AVANTEL, S.A. 7011 954 1206 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:694 2:718 3:3 4:13 5:697 6:3 8:488 12:1934 13:3 14:701 15:11 16:3 17:6 20:27 23:220 24:1794 27:1466 31:1339 32:54 33:2 34:2 36:11 37:1140 38:844 39:2 40:142 41:2654 42:179 44:3 46:1717 47:3 49:509 50:652 52:12 54:28 55:8 56:1 57:28 58:1068 59:558 60:237 61:1306 62:1037 63:2019 64:4354 65:2201 66:4497 67:2084 68:1202 69:3334 70:937 71:557 72:1895 74:2626 75:476 76:293 77:1037 78:1025 79:519 80:1207 81:980 82:643 83:536 84:531 85:1158 86:458 87:970 88:354 89:1756 90:304 91:5376 92:610 93:1625 94:1971 95:1610 96:487 97:338 98:969 99:40 100:31 101:287 103:1964 105:501 106:117 107:203 108:508 109:1738 110:833 111:980 112:459 113:744 114:643 115:904 116:891 117:778 118:966 119:1266 120:375 121:708 122:1730 123:1173 124:1320 125:1296 128:808 129:200 130:304 131:643 132:316 133:142 134:255 135:62 136:215 137:235 138:344 139:169 140:182 141:300 142:514 143:351 144:488 145:89 146:517 147:324 148:728 149:334 150:147 151:239 152:399 153:187 154:23 155:444 156:231 157:381 158:257 159:685 160:334 161:416 162:371 163:192 164:577 165:457 166:475 167:570 168:1003 169:133 170:1008 171:164 172:4 173:1654 174:628 175:464 176:879 177:1484 178:1742 180:1357 181:189 182:1116 183:294 184:633 185:135 186:2145 187:1432 188:1889 189:1570 190:6187 192:6085 193:5711 194:4490 195:3596 196:1247 197:291 198:4007 199:5153 200:6046 201:2027 202:8858 203:8744 204:4479 205:2556 206:2827 207:2828 208:4067 209:3655 210:2905 211:1548 212:2108 213:1875 214:862 215:90 216:5186 217:1552 218:595 219:321 220:1259 221:543 222:324 223:374 End of report From owen at delong.com Fri Dec 21 18:58:28 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 21 Dec 2012 10:58:28 -0800 Subject: Fiber only in DataCenters? In-Reply-To: References: <50CF54C0.9010106@bogus.com> <50D39D32.4010900@matthew.at> Message-ID: <1141EC75-506E-4A54-A9AD-823A72858A45@delong.com> On Dec 21, 2012, at 10:54 , George Herbert wrote: > On Thu, Dec 20, 2012 at 3:20 PM, Matthew Kaufman wrote: >> On 12/17/2012 9:22 AM, joel jaeggli wrote: >>> >>> If the facility is big enough the utility of twisted pair becomes quite >>> limited, both due to distance and differing electrical potential, >>> multibuilding campuses in particular make this is a nonstarter. >> >> >> For twisted-pair Ethernet: Distance yes. Differing electrical potential no. >> It is a balanced pair, transformer coupled at both ends. As long as AC >> common-mode pickup doesn't saturate the transformer core, it just works. > > ...Up to certain limits of DC / ground differential between the ends, > at which one can cause sparks anyways. > > Yes, the POTS telcos use 48V in the same or lower quality wire pairs, > and the various CatN wires should be able to take it, and the > connectors. I'm not sure whether the sparks were from 110 or 220 V of > differential, but I saw sparks. > Sparks come from voltage, but wire tolerance is entirely a matter of amperage. A 24ga cat-6 wire can take millions of volts as long as you keep the amperage low enough. Owen From pashdown at xmission.com Fri Dec 21 18:45:24 2012 From: pashdown at xmission.com (Pete Ashdown) Date: Fri, 21 Dec 2012 11:45:24 -0700 Subject: JunOS IPv6 announcements over IPv4 BGP Message-ID: <50D4AE44.2010503@xmission.com> I've got a peer who wishes me to send my IPv6 announcements over IPv4 BGP. I'm running around in circles with JTAC trying to find out how to do this in JunOS. Does anyone have a snippet they can send me? From george.herbert at gmail.com Fri Dec 21 19:15:10 2012 From: george.herbert at gmail.com (George Herbert) Date: Fri, 21 Dec 2012 11:15:10 -0800 Subject: Fiber only in DataCenters? In-Reply-To: <1141EC75-506E-4A54-A9AD-823A72858A45@delong.com> References: <50CF54C0.9010106@bogus.com> <50D39D32.4010900@matthew.at> <1141EC75-506E-4A54-A9AD-823A72858A45@delong.com> Message-ID: On Fri, Dec 21, 2012 at 10:58 AM, Owen DeLong wrote: > > On Dec 21, 2012, at 10:54 , George Herbert wrote: > >> On Thu, Dec 20, 2012 at 3:20 PM, Matthew Kaufman wrote: >>> On 12/17/2012 9:22 AM, joel jaeggli wrote: >>>> >>>> If the facility is big enough the utility of twisted pair becomes quite >>>> limited, both due to distance and differing electrical potential, >>>> multibuilding campuses in particular make this is a nonstarter. >>> >>> >>> For twisted-pair Ethernet: Distance yes. Differing electrical potential no. >>> It is a balanced pair, transformer coupled at both ends. As long as AC >>> common-mode pickup doesn't saturate the transformer core, it just works. >> >> ...Up to certain limits of DC / ground differential between the ends, >> at which one can cause sparks anyways. >> >> Yes, the POTS telcos use 48V in the same or lower quality wire pairs, >> and the various CatN wires should be able to take it, and the >> connectors. I'm not sure whether the sparks were from 110 or 220 V of >> differential, but I saw sparks. >> > Sparks come from voltage, but wire tolerance is entirely a matter of amperage. > > A 24ga cat-6 wire can take millions of volts as long as you keep the amperage > low enough. > > Owen In the ultimate limit, Insulator breakdown voltage is measured in V/mm, but in this case it was almost certainly not that, and merely a case of excessive amps at sufficient volts to give a nice large watts. The subsequent facility power get-well was not cheap. I have also, independently, melted and partly vaporized multiple cubic centimeters of 8 ga wire with a (purely accidental, I assure you) short of 12 volts from a serial stack of D-cell sized NiCd rechargeable batteries. The same works well with an old car 12 V battery and any conductor up to wrenches (not recommended at home...). What's the old saying? Volts hurt, Amps kill? -- -george william herbert george.herbert at gmail.com From harbor235 at gmail.com Fri Dec 21 19:19:26 2012 From: harbor235 at gmail.com (harbor235) Date: Fri, 21 Dec 2012 14:19:26 -0500 Subject: JunOS IPv6 announcements over IPv4 BGP In-Reply-To: <50D4AE44.2010503@xmission.com> References: <50D4AE44.2010503@xmission.com> Message-ID: I would push back on that request, any issues with V4 also impact V6. Segmentation is this case is good. Mike On Fri, Dec 21, 2012 at 1:45 PM, Pete Ashdown wrote: > I've got a peer who wishes me to send my IPv6 announcements over IPv4 BGP. > I'm running around in circles with JTAC trying to find out how to do this > in JunOS. Does anyone have a snippet they can send me? > > From cody at killsudo.info Fri Dec 21 19:21:34 2012 From: cody at killsudo.info (Cody Rose) Date: Fri, 21 Dec 2012 13:21:34 -0600 Subject: JunOS IPv6 announcements over IPv4 BGP In-Reply-To: <50D4AE44.2010503@xmission.com> References: <50D4AE44.2010503@xmission.com> Message-ID: <8eb19fec-da56-4b3f-b44c-2eaacb08356b@email.android.com> http://www.juniper.net/techpubs/software/junos/junos94/swconfig-routing/example-configuring-ipv6-bgp-routes-over-ipv4-transport.html Check out the above for setting both address families under a single peer. Pete Ashdown wrote: >I've got a peer who wishes me to send my IPv6 announcements over IPv4 >BGP. >I'm running around in circles with JTAC trying to find out how to do >this >in JunOS. Does anyone have a snippet they can send me? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From jared at puck.nether.net Fri Dec 21 19:45:38 2012 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 21 Dec 2012 14:45:38 -0500 Subject: JunOS IPv6 announcements over IPv4 BGP In-Reply-To: <50D4AE44.2010503@xmission.com> References: <50D4AE44.2010503@xmission.com> Message-ID: On Dec 21, 2012, at 1:45 PM, Pete Ashdown wrote: > I've got a peer who wishes me to send my IPv6 announcements over IPv4 BGP. > I'm running around in circles with JTAC trying to find out how to do this > in JunOS. Does anyone have a snippet they can send me? I would say don't do this. You are likely to experience software defects that are unique to this configuration which IMHO is far less common than a peer per v4/v6 transport. It will also show they aren't doing any 'kinky' engineering to get you IPv6. While some folks may disagree, the ability to connect you to an edge device that does dual-stack will provide you better service. - Jared From pashdown at xmission.com Fri Dec 21 19:47:30 2012 From: pashdown at xmission.com (Pete Ashdown) Date: Fri, 21 Dec 2012 12:47:30 -0700 Subject: JunOS IPv6 announcements over IPv4 BGP In-Reply-To: References: <50D4AE44.2010503@xmission.com> Message-ID: <50D4BCD2.8060706@xmission.com> Itis just informational rather than real peering. Akamai CDN. On 12/21/2012 12:45 PM, Jared Mauch wrote: > On Dec 21, 2012, at 1:45 PM, Pete Ashdown wrote: > >> I've got a peer who wishes me to send my IPv6 announcements over IPv4 BGP. >> I'm running around in circles with JTAC trying to find out how to do this >> in JunOS. Does anyone have a snippet they can send me? > I would say don't do this. You are likely to experience software defects that are unique to this configuration which IMHO is far less common than a peer per v4/v6 transport. It will also show they aren't doing any 'kinky' engineering to get you IPv6. While some folks may disagree, the ability to connect you to an edge device that does dual-stack will provide you better service. > > - Jared From aledm at qix.co.uk Fri Dec 21 20:00:08 2012 From: aledm at qix.co.uk (Aled Morris) Date: Fri, 21 Dec 2012 20:00:08 +0000 Subject: why haven't ethernet connectors changed? In-Reply-To: <20121221182208.GC13594@hiwaay.net> References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> <20121221095907.GR9750@leitl.org> <50D4889D.1050505@mtcc.com> <50D4A197.4070405@mtcc.com> <20121221182208.GC13594@hiwaay.net> Message-ID: On 21 December 2012 18:22, Chris Adams wrote: > I will say that one nice thing about having different connectors for > different protocols (on consumer devices anyway) is that you don't have > to worry about somebody plugging the Internet into the "Video 1" port > and wondering why they aren't getting a picture. > > > I do agree but I also think that for HDMI Ethernet your TV (which is the device with lots of HDMI sockets) will act as an Ethernet switch, so there shouldn't be any "Ethernet enabled" vs. "Video Enabled" ports. Now of course that means you probably need Spanning Tree in your domestic appliances. Aled From bicknell at ufp.org Fri Dec 21 20:04:13 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 21 Dec 2012 12:04:13 -0800 Subject: JunOS IPv6 announcements over IPv4 BGP In-Reply-To: <50D4AE44.2010503@xmission.com> References: <50D4AE44.2010503@xmission.com> Message-ID: <20121221200413.GA2029@ussenterprise.ufp.org> In a message written on Fri, Dec 21, 2012 at 11:45:24AM -0700, Pete Ashdown wrote: > I've got a peer who wishes me to send my IPv6 announcements over IPv4 BGP. > I'm running around in circles with JTAC trying to find out how to do this > in JunOS. Does anyone have a snippet they can send me? A believe you got the snippet, but I wanted to expand on why this is a bad idea. From a protocol perspective, BGP can create one session over a particular transport (IPv4, or IPv6 typically) and then exchange routes for multiple address families (IPv4 unicast, IPv4 multicast, IPv6 unicast, IPv6 multicast, or even all sorts of fun MPLS stuff). From a network management perspective doing so can complicate things immensely. Today networks want to deploy IPv6 without impacting their IPv4 network. Adding IPv6 AFI to an IPv4 transport session will tear it down, impacting IPv4 customers. Tomorrow, when IPv4 transport fails, IPv6 customers are also impacted by the failure of the transport, even though there may be no IPv6 routing issues. There is also a chance that IPv6 forwarding fails, but the routing information lives on running the traffic into a black hole since the routing information isn't sharing the failed transport. In the future, IPv4 will be removed from the network. If all of the transport is IPv4, those sessions will have to be torn down and new ones built with IPv6 transport before the IPv6 only network can live on. I believe the vast majority, approaching 100% of larger ISP's move IPv4 routes over IPv4 transport, and IPv6 routes over IPv6 transport, treating the two protocols as ships in the night. It elminates all three problems I've listed above at the grand expense of your router having to open/track 2 TCP connections rather than one; a trivial amount of overhead compared to the routes being exchanged. Of course, there are people who like to be different, sometimes for good reasons, often not... :) -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mike at mtcc.com Fri Dec 21 20:04:52 2012 From: mike at mtcc.com (Michael Thomas) Date: Fri, 21 Dec 2012 12:04:52 -0800 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> <20121221095907.GR9750@leitl.org> <50D4889D.1050505@mtcc.com> <50D4A197.4070405@mtcc.com> <20121221182208.GC13594@hiwaay.net> Message-ID: <50D4C0E4.1040309@mtcc.com> On 12/21/2012 12:00 PM, Aled Morris wrote: > On 21 December 2012 18:22, Chris Adams wrote: > >> I will say that one nice thing about having different connectors for >> different protocols (on consumer devices anyway) is that you don't have >> to worry about somebody plugging the Internet into the "Video 1" port >> and wondering why they aren't getting a picture. >> >> >> > I do agree but I also think that for HDMI Ethernet your TV (which is the > device with lots of HDMI sockets) will act as an Ethernet switch, so there > shouldn't be any "Ethernet enabled" vs. "Video Enabled" ports. > > Now of course that means you probably need Spanning Tree in your domestic > appliances. > In this day and age exactly how hard is this? Since it's all linux under the hood, isn't it just a brctl away? Mike From SNaslund at medline.com Fri Dec 21 20:14:29 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 21 Dec 2012 14:14:29 -0600 Subject: Fiber only in DataCenters? In-Reply-To: References: <50CF54C0.9010106@bogus.com> <50D39D32.4010900@matthew.at> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E9E1@MUNEXBE1.medline.com> It takes a lot of voltage to cause an arcing spark. I would suspect static buildup along the way and bad grounding. Even a big facility with a good ground should not have enough voltage differential between grounding points to cause sparks. Having the right size rack grounding should give you a very low resistance to ground from any point. The most common problem I have seen in large facilities is multiple grounds that are not tied together or cables that are grounded at multiple points causing a loop current. It is critical that everything have a single ground, that includes racks, electrical distribution, cable tray, etc. Most Cat X cables are unshielded and do not have a ground conductor so you must have equipment at the same potential at both ends or you will get loop current for sure. As far as voltage in Cat X cables, the real factor is the current carrying capacity of a particular wire gage. It does not really matter whether it is Cat 6 or a coat hanger, current capacity is a function of cable cross section and what material it is made of. Copper has a specific resistance as do all other metals. A copper cable needs to have enough cross section to dissipate the heat generated by its resistance. A less conductive material requires more cross section to dissipate the increased heat. At extremely high voltages things become more complex because of the skin affect that causes the power to move through the outer parts of the cable more than the inner parts. These levels are not a factor in communications cables. The main factor for fiber over copper in data centers is all about cost. Most servers include copper connections and fiber costs something extra. For switches, the cost of the optics is significant. Fiber does help prevent damage due to surges or electrical faults but if these are a problem in your datacenter you have bigger fish to fry. Steven Naslund -----Original Message----- From: George Herbert [mailto:george.herbert at gmail.com] Sent: Friday, December 21, 2012 12:54 PM To: Matthew Kaufman Cc: nanog at nanog.org Subject: Re: Fiber only in DataCenters? On Thu, Dec 20, 2012 at 3:20 PM, Matthew Kaufman wrote: > On 12/17/2012 9:22 AM, joel jaeggli wrote: >> >> If the facility is big enough the utility of twisted pair becomes >> quite limited, both due to distance and differing electrical >> potential, multibuilding campuses in particular make this is a nonstarter. > > > For twisted-pair Ethernet: Distance yes. Differing electrical potential no. > It is a balanced pair, transformer coupled at both ends. As long as AC > common-mode pickup doesn't saturate the transformer core, it just works. ...Up to certain limits of DC / ground differential between the ends, at which one can cause sparks anyways. Yes, the POTS telcos use 48V in the same or lower quality wire pairs, and the various CatN wires should be able to take it, and the connectors. I'm not sure whether the sparks were from 110 or 220 V of differential, but I saw sparks. >> In one facility I'm in, I'm over 300 meters from each of the MMRs, >> with the results that the OOB for the serial console server for out >> equipment located out there in the MMR's being on serial over fiber >> transceivers connected by om4 multimode. > > > RS232 serial is another story. Here the potential difference between > the ends is a big deal. (I've even seen burned-through PC boards from > what happens when pin 7 has 220 VAC flowing from one device to the > other) But you can just run Ethernet out to the console server and > plug it in next to the gear with the serial port to fix this. > > Matthew Kaufman Ah, yes, those magic smokes. -- -george william herbert george.herbert at gmail.com From SNaslund at medline.com Fri Dec 21 20:24:05 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 21 Dec 2012 14:24:05 -0600 Subject: why haven't ethernet connectors changed? In-Reply-To: <20121221182208.GC13594@hiwaay.net> References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> <20121221095907.GR9750@leitl.org> <50D4889D.1050505@mtcc.com> <50D4A197.4070405@mtcc.com> <20121221182208.GC13594@hiwaay.net> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E9F3@MUNEXBE1.medline.com> HDMI is also extremely distance limited. At those kinds of distances you probably would have no problem running 8 gbps over a Cat 6 with RJ-45s as well. I don't know how many people remember it but 1G used to be real expensive as well. In a few years you will see the 10 gbps D-Link switches at Best Buy for $40. Bottom line is that vendor know that people who need 10G speeds can afford to pay for the privilege. The important thing about consumer connectors is that plugging a cable in the wrong place should not blow anything up. You can use an RJ45 for anything you want as long as plugging that into an Ethernet port or console port doesn't smoke anything. There is not much magical about an HDMI cable, it is was just a way for the home entertainment equipment makers to avoid having your mom hooking up multiple component video, multichannel audio, and Ethernet and flooding their support phones. For datacenters there is no such push because there is no telling how many connections you need to a server and there are geeks like us to figure out the piles of wires. Steven Naslund -----Original Message----- From: Chris Adams [mailto:cmadams at hiwaay.net] Sent: Friday, December 21, 2012 12:22 PM To: nanog at nanog.org Subject: Re: why haven't ethernet connectors changed? Once upon a time, Michael Thomas said: > That's why G*d invented RTP, of course. And all of these buses are "slow" > by the time they're popular enough to worry about. In any case, delete > the "ethernet" part if you want to still play with the mac/phy. Well, the reply was sent in response to somebody talking about HDMI. HDMI 1.4 can carry over 8 gigabits per second, so to re-use ethernet PHY (and still be copper) you'd have to go with 10GBaseT. The cheapest 10GBaseT card I see at a glance is over $400, while I can find Blu-Ray players with HDMI 1.4 (and oh yeah, an optical drive, video decoder, etc.) for under $100. I'm sure some of that price difference is related to manufacturing volume, but I don't think it is that big of a percentage. I will say that one nice thing about having different connectors for different protocols (on consumer devices anyway) is that you don't have to worry about somebody plugging the Internet into the "Video 1" port and wondering why they aren't getting a picture. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From SNaslund at medline.com Fri Dec 21 20:30:10 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 21 Dec 2012 14:30:10 -0600 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <50D35BB3.3000800@netcases.net> <4D399CD7-FC47-4813-A0A3-A5361DE2114C@iname.com> <20121221095907.GR9750@leitl.org> <50D4889D.1050505@mtcc.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA09@MUNEXBE1.medline.com> Distance, data rate required, bandwidth (like RF signals), analog signals and timing that Ethernet does not provide. I suppose that you cable box could encode everything as Ethernet/IP to send it to your TV but it would take lots of processing horsepower to encode/decode. Your stereo could take the analog output going to your speakers and encode it as a digital Ethernet/IP signal but then you would need to decode and amplify it at the speaker. Some signals are better off as analog or RF end to end. Your FM radio antenna is going to be pretty expensive if you want to use Ethernet between it and your stereo receiver. Steven Naslund -----Original Message----- From: Tony Finch [mailto:dot at dotat.at] Sent: Friday, December 21, 2012 11:30 AM To: Michael Thomas Cc: nanog at nanog.org Subject: Re: why haven't ethernet connectors changed? Michael Thomas wrote: > > I'd turn this back the other way though: in this day and age, why do > we have any interconnection/bus that isn't just ethernet/IP? The need for isochronous transmission and more bandwidth. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From tom at cloudflare.com Fri Dec 21 20:33:18 2012 From: tom at cloudflare.com (Tom Paseka) Date: Fri, 21 Dec 2012 12:33:18 -0800 Subject: JunOS IPv6 announcements over IPv4 BGP In-Reply-To: <50D4AE44.2010503@xmission.com> References: <50D4AE44.2010503@xmission.com> Message-ID: protocols bgp { group akamai { neighbor x.x.x.x { family inet { unicast; } family inet6 { unicast; } } } } On Fri, Dec 21, 2012 at 10:45 AM, Pete Ashdown wrote: > I've got a peer who wishes me to send my IPv6 announcements over IPv4 BGP. > I'm running around in circles with JTAC trying to find out how to do this > in JunOS. Does anyone have a snippet they can send me? > > From SNaslund at medline.com Fri Dec 21 20:37:02 2012 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 21 Dec 2012 14:37:02 -0600 Subject: why haven't ethernet connectors changed? In-Reply-To: <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> I have noticed that too. However it is not the RJ-45 connector's fault. It is the morons that insist on recessing connectors in places where you can't get your finger on the tab. I like the patch cords that have the kind of loop/spring thing for a tab that does not catch on everything and that way you don't need the boot over the tab. Another pet peeve of mine is connector boots that harden up over time so it is nearly impossible to flex the tab to remove the cable. Also, how about the 48 port 6500 blades and trying to remove the cables near the blade extraction tabs. Grrrr. Steven Naslund -----Original Message----- From: Eric Wieling [mailto:EWieling at nyigc.com] Sent: Friday, December 21, 2012 11:30 AM To: Naslund, Steve; nanog at nanog.org Subject: RE: why haven't ethernet connectors changed? The only thing I would change about RJ-45 is a longer tab (but make it optional) for when you care more about ease of removal than cable tangles. Polycom phones are hell to try and unplug the RJ-45, for example. -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Friday, December 21, 2012 11:43 AM To: nanog at nanog.org Subject: RE: why haven't ethernet connectors changed? Please, no connectors that do not lock into place. Is plugging in the RJ-45 that much of a task? Most portable devices are going wireless in any case so they are not an issue. The RJ-45 has worked OK for me. The AUI connectors have a special place in networking hell. What an incredibly horrible mechanical design they were? The flip side of the question is why you think the RJ-45 should change. You could argue that you don't usually need all eight wires but every time we tried that argument someone came up with a compelling reason to use more wires. I like that it is very standard. In the fiber world it is a continuous issue of hybrid patch cords dealing with ST,SC,LC and all the other variants out there. It would be a huge nightmare if the same thing happened with copper Ethernet. I am also not a huge fan of the USB connector because I have seen a lot of those break and there is no positive retention. Magnetic is cute but has no place in a datacenter and even with desktops I can picture a lot of support calls because someone bumps a wire that knocks the mag connector out of place. I really hate dongles of all types but I guess you don't really have a choice with devices so physically thin that you can't get the jack in there. I think I will keep the RJ for now. Steven Naslund -----Original Message----- From: Aled Morris [mailto:aledm at qix.co.uk] Sent: Thursday, December 20, 2012 12:38 PM To: Michael Thomas Cc: NANOG list Subject: Re: why haven't ethernet connectors changed? On 20 December 2012 18:20, Michael Thomas wrote > ethernet > connectors haven't changed that I'm aware in pretty much 25 years. 15-pin D-type AUI connectors with slide latches? BNC for thinwire? I do agree though, something more like mini-USB would be more appropriate for home Ethernet use. Aled From andre at operations.net Fri Dec 21 20:57:04 2012 From: andre at operations.net (Andre Gironda) Date: Fri, 21 Dec 2012 13:57:04 -0700 Subject: why haven't ethernet connectors changed? In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> Message-ID: Some companies such as Apple have completely removed Ethernet ports from their Pro line laptops. Other vendors, such as ASUS, have thin laptops with collapsing Ethernet ports that tuck into the case. On Fri, Dec 21, 2012 at 1:37 PM, Naslund, Steve wrote: > I have noticed that too. However it is not the RJ-45 connector's fault. > It is the morons that insist on recessing connectors in places where you > can't get your finger on the tab. I like the patch cords that have the > kind of loop/spring thing for a tab that does not catch on everything > and that way you don't need the boot over the tab. Another pet peeve of > mine is connector boots that harden up over time so it is nearly > impossible to flex the tab to remove the cable. Also, how about the 48 > port 6500 blades and trying to remove the cables near the blade > extraction tabs. Grrrr. > > Steven Naslund > > -----Original Message----- > From: Eric Wieling [mailto:EWieling at nyigc.com] > Sent: Friday, December 21, 2012 11:30 AM > To: Naslund, Steve; nanog at nanog.org > Subject: RE: why haven't ethernet connectors changed? > > The only thing I would change about RJ-45 is a longer tab (but make it > optional) for when you care more about ease of removal than cable > tangles. Polycom phones are hell to try and unplug the RJ-45, for > example. > > -----Original Message----- > From: Naslund, Steve [mailto:SNaslund at medline.com] > Sent: Friday, December 21, 2012 11:43 AM > To: nanog at nanog.org > Subject: RE: why haven't ethernet connectors changed? > > Please, no connectors that do not lock into place. Is plugging in the > RJ-45 that much of a task? Most portable devices are going wireless in > any case so they are not an issue. The RJ-45 has worked OK for me. The > AUI connectors have a special place in networking hell. What an > incredibly horrible mechanical design they were? The flip side of the > question is why you think the RJ-45 should change. You could argue that > you don't usually need all eight wires but every time we tried that > argument someone came up with a compelling reason to use more wires. I > like that it is very standard. In the fiber world it is a continuous > issue of hybrid patch cords dealing with ST,SC,LC and all the other > variants out there. It would be a huge nightmare if the same thing > happened with copper Ethernet. > > I am also not a huge fan of the USB connector because I have seen a lot > of those break and there is no positive retention. Magnetic is cute but > has no place in a datacenter and even with desktops I can picture a lot > of support calls because someone bumps a wire that knocks the mag > connector out of place. I really hate dongles of all types but I guess > you don't really have a choice with devices so physically thin that you > can't get the jack in there. > > I think I will keep the RJ for now. > > Steven Naslund > > -----Original Message----- > From: Aled Morris [mailto:aledm at qix.co.uk] > Sent: Thursday, December 20, 2012 12:38 PM > To: Michael Thomas > Cc: NANOG list > Subject: Re: why haven't ethernet connectors changed? > > On 20 December 2012 18:20, Michael Thomas wrote > > > ethernet > > connectors haven't changed that I'm aware in pretty much 25 years. > > > > 15-pin D-type AUI connectors with slide latches? > > BNC for thinwire? > > I do agree though, something more like mini-USB would be more > appropriate for home Ethernet use. > > Aled > > > From randy at psg.com Fri Dec 21 21:15:37 2012 From: randy at psg.com (Randy Bush) Date: Fri, 21 Dec 2012 16:15:37 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> Message-ID: > Some companies such as Apple have completely removed Ethernet ports from > their Pro line laptops. carrying a dongle sucks. but i understand the geometry problem. randy From jakob.heitz at ericsson.com Fri Dec 21 21:19:49 2012 From: jakob.heitz at ericsson.com (Jakob Heitz) Date: Fri, 21 Dec 2012 21:19:49 +0000 Subject: NANOG Digest, Vol 59, Issue 80 In-Reply-To: References: Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E1310D6@eusaamb109.ericsson.se> Voltage causes sparks, but... Maybe you got the spark when you disconneted the wire. In that case, you likely have a ground loop carrying current and a long wire. When you disconnect the wire, the current wants to keep flowing due to loop inductance. This causes the voltage spike and hence the spark. > Date: Fri, 21 Dec 2012 14:14:29 -0600 > From: "Naslund, Steve" > To: "George Herbert" , "Matthew Kaufman" > Cc: nanog at nanog.org > Subject: RE: Fiber only in DataCenters? > Message-ID: > <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E9E1 at MUNEXBE1.medline.com> > Content-Type: text/plain; charset="us-ascii" > > It takes a lot of voltage to cause an arcing spark. I would suspect > static buildup along the way and bad grounding. Even a big facility > with a good ground should not have enough voltage differential between > grounding points to cause sparks. Having the right size rack > grounding should give you a very low resistance to ground from any > point. The most common problem I have seen in large facilities is > multiple grounds > that are not tied together or cables that are grounded at multiple > points causing a loop current. It is critical that everything have a > single ground, that includes racks, electrical distribution, > cable tray, > etc. Most Cat X cables are unshielded and do not have a ground > conductor so you must have equipment at the same potential at > both ends > or you will get loop current for sure. > > As far as voltage in Cat X cables, the real factor is the current > carrying capacity of a particular wire gage. It does not really matter > whether it is Cat 6 or a coat hanger, current capacity is a > function of > cable cross section and what material it is made of. Copper has a > specific resistance as do all other metals. A copper cable needs to > have enough cross section to dissipate the heat generated by its > resistance. A less conductive material requires more cross section to > dissipate the increased heat. At extremely high voltages > things become > more complex because of the skin affect that causes the power to move > through the outer parts of the cable more than the inner parts. These > levels are not a factor in communications cables. > > The main factor for fiber over copper in data centers is all > about cost. > Most servers include copper connections and fiber costs > something extra. > For switches, the cost of the optics is significant. Fiber does help > prevent damage due to surges or electrical faults but if these are a > problem in your datacenter you have bigger fish to fry. > > Steven Naslund -- Jakob Heitz. From jason at thebaughers.com Fri Dec 21 21:48:04 2012 From: jason at thebaughers.com (Jason Baugher) Date: Fri, 21 Dec 2012 15:48:04 -0600 Subject: why haven't ethernet connectors changed? In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> Message-ID: On Fri, Dec 21, 2012 at 2:37 PM, Naslund, Steve wrote: > I have noticed that too. However it is not the RJ-45 connector's fault. > It is the morons that insist on recessing connectors in places where you > can't get your finger on the tab. I like the patch cords that have the > kind of loop/spring thing for a tab that does not catch on everything > and that way you don't need the boot over the tab. Another pet peeve of > mine is connector boots that harden up over time so it is nearly > impossible to flex the tab to remove the cable. Also, how about the 48 > port 6500 blades and trying to remove the cables near the blade > extraction tabs. Grrrr. > > > Yes, the tabs you refer to are the best. I have never done business with this company, but that have a good picture for reference. http://www.computercablestore.com/10_FT_Booted_Cat5e_Networ_PID49403.aspx The full boots can be so thick that they won't fit into a high-density switch. If you're in a cold environment they go from difficult to compress to damn near impossible. More than once I've used a knife to cut a hardened boot off a cable so it's usable again. Jason From cidr-report at potaroo.net Fri Dec 21 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Dec 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201212212200.qBLM00Yh000344@wattle.apnic.net> This report has been generated at Fri Dec 21 21:13:09 2012 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 14-12-12 440081 251672 15-12-12 439802 251907 16-12-12 439907 252026 17-12-12 439983 251974 18-12-12 439300 252062 19-12-12 440076 252503 20-12-12 440600 252771 21-12-12 440351 252566 AS Summary 43021 Number of ASes in routing system 17901 Number of ASes announcing only one prefix 3473 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 115356896 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'). --- 21Dec12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 440782 252620 188162 42.7% All ASes AS6389 3121 137 2984 95.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2249 70 2179 96.9% NET Servicos de Comunicao S.A. AS17974 2488 450 2038 81.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2926 925 2001 68.4% KIXS-AS-KR Korea Telecom AS7029 3473 1608 1865 53.7% WINDSTREAM - Windstream Communications Inc AS22773 1947 171 1776 91.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2081 423 1658 79.7% COVAD - Covad Communications Co. AS10620 2268 651 1617 71.3% Telmex Colombia S.A. AS7303 1674 397 1277 76.3% Telecom Argentina S.A. AS4323 1601 402 1199 74.9% TWTC - tw telecom holdings, inc. AS4755 1660 555 1105 66.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1052 53 999 95.0% RELCOM-AS OOO "NPO Relcom" AS7552 1148 221 927 80.7% VIETEL-AS-AP Vietel Corporation AS7545 1821 945 876 48.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 1017 170 847 83.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1581 738 843 53.3% Uninet S.A. de C.V. AS1785 1940 1157 783 40.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1123 352 771 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 856 118 738 86.2% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS18881 740 40 700 94.6% Global Village Telecom AS855 716 53 663 92.6% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS9808 680 30 650 95.6% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS17676 712 92 620 87.1% GIGAINFRA Softbank BB Corp. AS3356 1118 504 614 54.9% LEVEL3 Level 3 Communications AS3549 1053 444 609 57.8% GBLX Global Crossing Ltd. AS22561 1041 443 598 57.4% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 999 404 595 59.6% VZGNI-TRANSIT - Verizon Online LLC AS24560 1037 452 585 56.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22047 579 22 557 96.2% VTR BANDA ANCHA S.A. AS4804 632 96 536 84.8% MPX-AS Microplex PTY LTD Total 45333 12123 33210 73.3% 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- 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.222.80.0/21 AS37110 moztel-as 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 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 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 68.234.0.0/19 AS40430 COLO4JAX-AS - colo4jax, LLC 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 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 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.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.217.250.0/24 AS43108 GARM-AS Garm Technologies Ltd. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 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.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 185.14.0.0/22 AS41090 E-LIANCE Equation SA 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 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.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 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.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 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 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 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 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.87.96.0/21 AS40638 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. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 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 Dec 21 22:00:02 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 Dec 2012 22:00:02 GMT Subject: BGP Update Report Message-ID: <201212212200.qBLM02Cb000357@wattle.apnic.net> BGP Update Report Interval: 13-Dec-12 -to- 20-Dec-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 39344 2.0% 27.5 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS3909 38045 1.9% 4755.6 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - AS9829 37060 1.9% 42.7 -- BSNL-NIB National Internet Backbone 4 - AS29124 35162 1.8% 1004.6 -- SU29-AS ISP "Gorcom" 5 - AS12768 33148 1.7% 338.2 -- ER-TELECOM-AS CJSC "ER-Telecom Holding" 6 - AS29256 24612 1.3% 1447.8 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 7 - AS23685 22669 1.2% 985.6 -- CAT-HUTCH-AS-AP Hutchison CAT Wireless Multimedia Ltd, 8 - AS1637 17517 0.9% 208.5 -- DNIC-AS-01637 - Headquarters, USAISC 9 - AS7303 17366 0.9% 4.9 -- Telecom Argentina S.A. 10 - AS29614 16767 0.9% 698.6 -- GHANATEL-AS 11 - AS29049 14790 0.8% 45.0 -- DELTA-TELECOM-AS Delta Telecom LTD. 12 - AS4755 14020 0.7% 12.3 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 13 - AS17974 13252 0.7% 7.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 14 - AS5972 12186 0.6% 86.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 15 - AS2708 11439 0.6% 83.5 -- Universidad de Guanajuato 16 - AS9583 10668 0.5% 9.0 -- SIFY-AS-IN Sify Limited 17 - AS24560 10611 0.5% 11.0 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 18 - AS4538 10468 0.5% 22.8 -- ERX-CERNET-BKB China Education and Research Network Center 19 - AS7552 10203 0.5% 9.2 -- VIETEL-AS-AP Vietel Corporation 20 - AS4780 10086 0.5% 17.9 -- SEEDNET Digital United Inc. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS2033 8850 0.5% 8850.0 -- PANIX - Panix Network Information Center 2 - AS24057 8307 0.4% 8307.0 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 3 - AS3909 38045 1.9% 4755.6 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - AS6174 5655 0.3% 2827.5 -- SPRINTLINK8 - Sprint 5 - AS26799 5486 0.3% 2743.0 -- DKR - DKR CAPITAL 6 - AS6197 2633 0.1% 2633.0 -- BATI-ATL - BellSouth Network Solutions, Inc 7 - AS14680 5076 0.3% 1692.0 -- REALE-6 - Auction.com 8 - AS37430 1538 0.1% 1538.0 -- vdctelecom 9 - AS29256 24612 1.3% 1447.8 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 10 - AS6629 5698 0.3% 1424.5 -- NOAA-AS - NOAA 11 - AS41674 1387 0.1% 1387.0 -- ALVARION-AS Alvarion SRL 12 - AS17293 3879 0.2% 1293.0 -- VTXC - VTX Communications 13 - AS1562 2556 0.1% 1278.0 -- DNIC-ASBLK-01550-01601 - DoD Network Information Center 14 - AS57918 1138 0.1% 1138.0 -- ACOD-AS ACOD CJSC 15 - AS4 3192 0.2% 88.0 -- COMUNICALO DE MEXICO S.A. DE C.V 16 - AS29124 35162 1.8% 1004.6 -- SU29-AS ISP "Gorcom" 17 - AS23685 22669 1.2% 985.6 -- CAT-HUTCH-AS-AP Hutchison CAT Wireless Multimedia Ltd, 18 - AS9950 1850 0.1% 925.0 -- PUBNETPLUS2-AS-KR DACOM 19 - AS37263 877 0.0% 877.0 -- UNIVEDU 20 - AS15825 3062 0.2% 765.5 -- UNSPECIFIED TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 151.118.18.0/24 12670 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - 151.118.254.0/24 12645 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.255.0/24 12644 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 209.48.168.0/24 8850 0.4% AS2033 -- PANIX - Panix Network Information Center 5 - 202.14.255.0/24 8307 0.4% AS24057 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 6 - 12.30.238.0/24 5480 0.3% AS26799 -- DKR - DKR CAPITAL 7 - 192.58.232.0/24 5419 0.3% AS6629 -- NOAA-AS - NOAA 8 - 194.63.9.0/24 4558 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 9 - 12.139.133.0/24 4280 0.2% AS14680 -- REALE-6 - Auction.com 10 - 69.38.178.0/24 4173 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 11 - 202.171.192.0/20 3583 0.2% AS4788 -- TMNET-AS-AP TM Net, Internet Service Provider 12 - 81.200.3.0/24 3379 0.2% AS29124 -- SU29-AS ISP "Gorcom" 13 - 81.200.23.0/24 3035 0.1% AS29124 -- SU29-AS ISP "Gorcom" 14 - 81.200.8.0/24 3020 0.1% AS29124 -- SU29-AS ISP "Gorcom" 15 - 81.200.4.0/24 3019 0.1% AS29124 -- SU29-AS ISP "Gorcom" 16 - 81.200.1.0/24 3013 0.1% AS29124 -- SU29-AS ISP "Gorcom" 17 - 81.200.22.0/24 3011 0.1% AS29124 -- SU29-AS ISP "Gorcom" 18 - 81.200.16.0/24 3009 0.1% AS29124 -- SU29-AS ISP "Gorcom" 19 - 81.200.20.0/24 3008 0.1% AS29124 -- SU29-AS ISP "Gorcom" 20 - 81.200.12.0/24 3002 0.1% AS29124 -- SU29-AS ISP "Gorcom" 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 ralph.brandt at pateam.com Fri Dec 21 23:44:00 2012 From: ralph.brandt at pateam.com (Brandt, Ralph) Date: Fri, 21 Dec 2012 18:44:00 -0500 Subject: why haven't ethernet connectors changed? (Ramdom thoughts) In-Reply-To: <5D6EBDAE-03D1-4D07-B204-9BB99C621873@2mbit.com> References: <50D356DB.5090809@mtcc.com> <5D6EBDAE-03D1-4D07-B204-9BB99C621873@2mbit.com> Message-ID: <51C66083768C2949A7EB14910C78B01701BA4C81@embgsr24.pateam.com> I have seen the sixty or so messages about this and have marveled how many can major on the minutia and ignore the obvious which Brielle brings out. First, Ethernet connectors have changed - Thicknet (RG8) with transceiver cables, thinnet, and now CAT series cables. Yep, I have bored in the vampire taps and crimped thinnet. In another venue I work we still have millions maybe billions of lines of COBOL code. Why? Because it works. Because the cost of conversion to something else is prohibitive. It is being done by attrition and I might say, painfully. One organization I am aware of was to have been extracted from the tar baby of its COBOL code that was originally written in 1968 in COBOL D before Y2K had to fix all of that to run properly over the millennium. And one company I am aware of had to convert its COBOL F to COBOL II to get there. I haven't followed it since 2003 but they were still working on getting free from COBOL then when I was offered a job helping them extricate from the mess. I was having too much fun with WAN's. BTW, I am retiring 2/28/13 - if anyone has a COBOL and/or CICS job out there with the right location and situation I may be interested. I am fantastic as translating COBOL into a language JAVA coders can understand. I write JAVA, I do not call JAVA coders programmers. Programming is the next thing to retirement. And RJ-45 has some of the same characteristics. It works. There are trillions of them out there in use and on equipment (the corresponding jacks). There are millions of techs who can put them on. Well, maybe that is going a little too far. I have seen too many techs who claim to know how who should be hung with their cabling. They are used for everything so nearly every wiring discipline knows them. There are millions of sets of tools to attach them. I just saw an installation where a ham radio transmitter was set up in a hospital "in case everything else fails" and they put the transmitter at the roof, ran a 20 foot pre-made coaxial cable with PL259's to the antenna and two CAT-5's down to the operator area where they put the control. The transceiver allows separation of the control head and the transceiver. The one cat 5 carries the controls - the connectors on the units are RJ-45. The other CAT-5? They made one pair out of the CAT5, tied 4 wires together to get enough copper to handle the speaker. Reason? The hospital wiring staff did not know how to put on a PL259 on RG-213. (Similar to RG-8). But they could run CAT-5 and put on RJ-45's. So to change we have to provide training, tools, adapters (another nightmare), labor to convert and for what? There is no other connector I am aware of and I haven't heard of any serious contender from anyone here. That means 30 million dollars development (my estimate) and five years till we get the beta models. And for what? I can't see any way we could get more than a 20% higher density, even ignoring noise and crosstalk issues. And even if we can get 50% more would it be worth it? Answer, MAYBE in some very specialized and/or badly designed situations (concentrating too much copper in one place rather than distributing to "close up switches" with fiber) where a higher density would be of value, yes. But now we create another set of adapters. I am a Ham Radio Operator - Extra Class. I work with Emergency Communications. Having one more connector type is one more big headache. Yes, if there is a real advantage, fine. Most ham hand held transceivers went from the venerable and solid BNC to the SMA a few years ago. They screw a 18 inch antenna on an SMA! Guess what? They break when you are lucky, otherwise they go intermittent. And just to make it more interesting one of the Chinese suppliers of very inferior HT's uses an SMA male on the radio, not an SMA female like everyone else. So now instead of having three antenna connector types in general use, N, PL259, BNC, each with their strengths and weaknesses and reasons to use in certain places, we have 5 with no serous reason for two of them. Note that HT's have used BNC and SMA, mobiles and bases are generally N, PL259 with a few BNC. I have standardized on bas/mobile at PL259 and SMA male for HT to maintain sanity. And to be able to work with others who have a dukes mixture I carry a small box of adapters. The IT industry trail is littered with computer languages that were written to fix some non-existent problem and all that did was create more confusion. Many claimed to allow anyone to code programs, something that is true but when you use people who really do not know how to program you produce tons of shit code that is nasty to make changes to - and maintenance of programs is usually 90% of life cycle costs. It is the same in a wire room when you let someone who doesn't know how to properly place wire do it. PASCAL is one example I can cite. It had absolutely no advantage over several other languages existing at the time but academia thought it was cute and pushed it. A few industries used it and created havoc with it. There were others like Ideal that many of you never heard of because they were never widely used but created a conversion opportunity when they were no longer supported. Ralph Brandt -----Original Message----- From: Brielle Bruns [mailto:bruns at 2mbit.com] Sent: Friday, December 21, 2012 10:16 AM To: NANOG list Subject: Re: why haven't ethernet connectors changed? Some of us still have a stock of legacy gear and cables - things like v35 cables for connecting to CSU/DSUs, and even the occasional AUI hub. :) You wouldn't believe how much people will pay for legacy computer gear when they need it to keep their business going. -- Brielle Sent from my iPhone On Dec 21, 2012, at 7:57 AM, Matthew Black wrote: > http://www.blackbox.com/Store/Detail.aspx/Ethernet-Transceiver-Cable-Off ice-Environment-PVC-IEEE-802-3-Right-Angle-Connector-3-ft-0-9-m/LCN216%C 4%820003 > > Only $55.95 for a 3-foot transceiver cable. What was more surprising is that Black Box is still around. > > > matthew black > california state university, long beach > > > -----Original Message----- > From: Michael Thomas [mailto:mike at mtcc.com] > Sent: Thursday, December 20, 2012 10:20 AM > To: NANOG list > Subject: why haven't ethernet connectors changed? > > I was looking at a Raspberry Pi board and was struck with how large the ethernet > connector is in comparison to the board as a whole. It strikes me: ethernet > connectors haven't changed that I'm aware in pretty much 25 years. Every other > cable has changed several times in that time frame. I imaging that if anybody > cared, ethernet cables could be many times smaller. Looking at wiring closets, > etc, it seems like it might be a big win for density too. > > So why, oh why, nanog the omniscient do we still use rj45's? > > Mike > > > > > > > From web at typo.org Fri Dec 21 23:48:23 2012 From: web at typo.org (Wayne E Bouchard) Date: Fri, 21 Dec 2012 16:48:23 -0700 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> Message-ID: <20121221234823.GA52023@wakko.typo.org> On Fri, Dec 21, 2012 at 03:48:04PM -0600, Jason Baugher wrote: > On Fri, Dec 21, 2012 at 2:37 PM, Naslund, Steve wrote: > > > I have noticed that too. However it is not the RJ-45 connector's fault. > > It is the morons that insist on recessing connectors in places where you > > can't get your finger on the tab. I like the patch cords that have the > > kind of loop/spring thing for a tab that does not catch on everything > > and that way you don't need the boot over the tab. Another pet peeve of > > mine is connector boots that harden up over time so it is nearly > > impossible to flex the tab to remove the cable. Also, how about the 48 > > port 6500 blades and trying to remove the cables near the blade > > extraction tabs. Grrrr. > > > > > > Yes, the tabs you refer to are the best. I have never done business with > this company, but that have a good picture for reference. > > http://www.computercablestore.com/10_FT_Booted_Cat5e_Networ_PID49403.aspx > > The full boots can be so thick that they won't fit into a high-density > switch. If you're in a cold environment they go from difficult to compress > to damn near impossible. More than once I've used a knife to cut a hardened > boot off a cable so it's usable again. > > Jason And that's the main reason I never order cables with boots on them. They're mostly just unnecessary headaches. (BTW, you forgot to mention them slipping loose and just pulling away from the connector or the tab slipping out from under the rubber and making the cable all the more difficult to remove.) -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From ralph.brandt at pateam.com Fri Dec 21 23:50:57 2012 From: ralph.brandt at pateam.com (Brandt, Ralph) Date: Fri, 21 Dec 2012 18:50:57 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> Message-ID: <51C66083768C2949A7EB14910C78B01701BA4C82@embgsr24.pateam.com> Steve, something I hadn't thought about is the fiber mess. I see that in other areas as I mentioned in another answer. In the fiber world it is a continuous issue of hybrid patch cords dealing with ST,SC,LC and all the other variants out there. It would be a huge nightmare if the same thing happened with copper Ethernet. Ralph Brandt -----Original Message----- From: Naslund, Steve [mailto:SNaslund at medline.com] Sent: Friday, December 21, 2012 11:43 AM To: nanog at nanog.org Subject: RE: why haven't ethernet connectors changed? Please, no connectors that do not lock into place. Is plugging in the RJ-45 that much of a task? Most portable devices are going wireless in any case so they are not an issue. The RJ-45 has worked OK for me. The AUI connectors have a special place in networking hell. What an incredibly horrible mechanical design they were? The flip side of the question is why you think the RJ-45 should change. You could argue that you don't usually need all eight wires but every time we tried that argument someone came up with a compelling reason to use more wires. I like that it is very standard. In the fiber world it is a continuous issue of hybrid patch cords dealing with ST,SC,LC and all the other variants out there. It would be a huge nightmare if the same thing happened with copper Ethernet. I am also not a huge fan of the USB connector because I have seen a lot of those break and there is no positive retention. Magnetic is cute but has no place in a datacenter and even with desktops I can picture a lot of support calls because someone bumps a wire that knocks the mag connector out of place. I really hate dongles of all types but I guess you don't really have a choice with devices so physically thin that you can't get the jack in there. I think I will keep the RJ for now. Steven Naslund -----Original Message----- From: Aled Morris [mailto:aledm at qix.co.uk] Sent: Thursday, December 20, 2012 12:38 PM To: Michael Thomas Cc: NANOG list Subject: Re: why haven't ethernet connectors changed? On 20 December 2012 18:20, Michael Thomas wrote > ethernet > connectors haven't changed that I'm aware in pretty much 25 years. 15-pin D-type AUI connectors with slide latches? BNC for thinwire? I do agree though, something more like mini-USB would be more appropriate for home Ethernet use. Aled From owen at delong.com Sat Dec 22 00:07:12 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 21 Dec 2012 16:07:12 -0800 Subject: JunOS IPv6 announcements over IPv4 BGP In-Reply-To: References: <50D4AE44.2010503@xmission.com> Message-ID: I would push back for a slightly different reason... Any inability to forward IPv6 might not impact the IPv4 peering session and you might run into a situation where the peering session stays up and continues exchanging routes, but the traffic cannot pass (or cannot pass in one direction which is even more fun to diagnose). Owen On Dec 21, 2012, at 11:19 , harbor235 wrote: > I would push back on that request, any issues with V4 also impact V6. > Segmentation is this case is good. > > > Mike > > On Fri, Dec 21, 2012 at 1:45 PM, Pete Ashdown wrote: > >> I've got a peer who wishes me to send my IPv6 announcements over IPv4 BGP. >> I'm running around in circles with JTAC trying to find out how to do this >> in JunOS. Does anyone have a snippet they can send me? >> >> From tom at cloudflare.com Sat Dec 22 00:22:21 2012 From: tom at cloudflare.com (Tom Paseka) Date: Fri, 21 Dec 2012 16:22:21 -0800 Subject: JunOS IPv6 announcements over IPv4 BGP In-Reply-To: References: <50D4AE44.2010503@xmission.com> Message-ID: On Fri, Dec 21, 2012 at 4:07 PM, Owen DeLong wrote: > I would push back for a slightly different reason... > > Any inability to forward IPv6 might not impact the IPv4 peering session and > you might run into a situation where the peering session stays up and > continues > exchanging routes, but the traffic cannot pass (or cannot pass in one > direction > which is even more fun to diagnose). > > Owen > > The OP mentioned this was just for Akamai (for their DNS mapping). BGP isn't used for forwarding path. From david at davidswafford.com Sat Dec 22 02:50:24 2012 From: david at davidswafford.com (David Swafford) Date: Fri, 21 Dec 2012 21:50:24 -0500 Subject: JunOS IPv6 announcements over IPv4 BGP In-Reply-To: <20121221200413.GA2029@ussenterprise.ufp.org> References: <50D4AE44.2010503@xmission.com> <20121221200413.GA2029@ussenterprise.ufp.org> Message-ID: One reason that may force others down this track comes from exceeding the # of configurable BGP sessions on a box (think chassis switches). It does add a good bit of complexity in the initial roll-out but it's really not all that bad once you get used to it. The one piece that seems to make it a little easier is that you get a consolidated view on some devices, where the prefix counts are shown for both address families under the same "show ip bgp neighbor" display. david. On Fri, Dec 21, 2012 at 3:04 PM, Leo Bicknell wrote: > In a message written on Fri, Dec 21, 2012 at 11:45:24AM -0700, Pete Ashdown wrote: >> I've got a peer who wishes me to send my IPv6 announcements over IPv4 BGP. >> I'm running around in circles with JTAC trying to find out how to do this >> in JunOS. Does anyone have a snippet they can send me? > > A believe you got the snippet, but I wanted to expand on why this > is a bad idea. From a protocol perspective, BGP can create one > session over a particular transport (IPv4, or IPv6 typically) and > then exchange routes for multiple address families (IPv4 unicast, > IPv4 multicast, IPv6 unicast, IPv6 multicast, or even all sorts of > fun MPLS stuff). From a network management perspective doing so > can complicate things immensely. > > Today networks want to deploy IPv6 without impacting their IPv4 > network. Adding IPv6 AFI to an IPv4 transport session will tear > it down, impacting IPv4 customers. > > Tomorrow, when IPv4 transport fails, IPv6 customers are also impacted > by the failure of the transport, even though there may be no IPv6 > routing issues. There is also a chance that IPv6 forwarding fails, but > the routing information lives on running the traffic into a black hole > since the routing information isn't sharing the failed transport. > > In the future, IPv4 will be removed from the network. If all of > the transport is IPv4, those sessions will have to be torn down and > new ones built with IPv6 transport before the IPv6 only network can > live on. > > I believe the vast majority, approaching 100% of larger ISP's move > IPv4 routes over IPv4 transport, and IPv6 routes over IPv6 transport, > treating the two protocols as ships in the night. It elminates all > three problems I've listed above at the grand expense of your router > having to open/track 2 TCP connections rather than one; a trivial > amount of overhead compared to the routes being exchanged. > > Of course, there are people who like to be different, sometimes for good > reasons, often not... :) > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ From cmadams at hiwaay.net Sat Dec 22 05:56:22 2012 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 21 Dec 2012 23:56:22 -0600 Subject: why haven't ethernet connectors changed? In-Reply-To: <20121221234823.GA52023@wakko.typo.org> References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> <20121221234823.GA52023@wakko.typo.org> Message-ID: <20121222055622.GA9297@hiwaay.net> Once upon a time, Wayne E Bouchard said: > And that's the main reason I never order cables with boots on them. > They're mostly just unnecessary headaches. (BTW, you forgot to mention > them slipping loose and just pulling away from the connector or the > tab slipping out from under the rubber and making the cable all the > more difficult to remove.) I have seen one good use for boots. Somebody had a cable (that was in a position that made it difficult to replace or re-crimp) that had a RJ45 with a bad tab. It wasn't broken off, but it wouldn't really latch into the jack. So, they pulled the boot back slightly and slipped the "bump" of the boot _under_ the tab, and that held it up and the cable stayed in. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mysidia at gmail.com Sat Dec 22 06:50:52 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 22 Dec 2012 00:50:52 -0600 Subject: why haven't ethernet connectors changed? In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> Message-ID: On 12/21/12, Naslund, Steve wrote: > I have noticed that too. However it is not the RJ-45 connector's fault. > It is the morons that insist on recessing connectors in places where you > can't get your finger on the tab. I like the patch cords that have the Likely any connector with a latching retention mechanism requiring a manual release will have this kind of problem in space-constrained situations. A small flat edge screwdriver, spudger, or similar instrument can work wonders, since they are much longer than fingers. I suppose a fancier connector would involve a more robust metal spring, and a push-button release; or unlock through some method such as push in and slide. The terminal connectors are tiny; human hands are large by comparison, so when clearances are tight, in a recessed area, or in the case of a densely populated panel with many terminal ports, operating the retention mechanism by hand won't be fun. It could have been avoided by eliminating tabs in the connector design, and requiring a spring-loaded mechanism to release the connector, such as that done with USB and thunderbolt ports. This would also get rid of the problem of connector Tabs accidentally getting broken off, when the tab becomes snagged; which "boots" solve, but create other problems in the process. The ubiquity of the modular connector... has pluses such as low cost; no patent owner charging a mint per unit to license the connector; industry familiarity; device compatibility; (more or less) compatibility with older Cat5 media; 10/100/1000 nics. > kind of loop/spring thing for a tab that does not catch on everything > and that way you don't need the boot over the tab. Another pet peeve of > mine is connector boots that harden up over time so it is nearly > impossible to flex the tab to remove the cable. Also, how about the 48 Prefab patch cables with a boot that is permanently attached to the connector, and cannot be easily pulled off if necessary to get at the tab.... someone should ban those cables from the market. Until they do... you may sometimes just have to cut off the 'nub' on the boot, with angle cutters to get at the tab; or apply pliers/other forceful tools to the boot/connector (at risk of damaging the actual port). A nice thing about the 8P8C terminal connectors is that the connectors are cheap, so the cabling can be reterminated, or prefab cable replaced with a fresh one later, to solve booting issues. I would still say they make sense and shouldn't be redesigned just for one kind of device; wherever 8-pair UTP cabling is the physical media. > Steven Naslund -- -JH From jra at baylink.com Sat Dec 22 14:30:48 2012 From: jra at baylink.com (Jay Ashworth) Date: Sat, 22 Dec 2012 09:30:48 -0500 (EST) Subject: WW: Imminent Death Of USENET predicted; film at... wait; what? Message-ID: <692444.39252.1356186648416.JavaMail.root@benjamin.baylink.com> http://craphound.com/overclocked/Cory_Doctorow_-_Overclocked_-_When_Sysadmins_Ruled_the_Earth.html Happy Apocalypse, everybody. 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 jra at baylink.com Sat Dec 22 16:07:18 2012 From: jra at baylink.com (Jay Ashworth) Date: Sat, 22 Dec 2012 11:07:18 -0500 (EST) Subject: why haven't ethernet connectors changed? In-Reply-To: Message-ID: <8099764.39254.1356192438639.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > On 12/21/12, Naslund, Steve wrote: > > I have noticed that too. However it is not the RJ-45 connector's fault. > > It is the morons that insist on recessing connectors in places where you > > can't get your finger on the tab. I like the patch cords that have > > the > > Likely any connector with a latching retention mechanism requiring a > manual release will have this kind of problem in space-constrained > situations. A small flat edge screwdriver, spudger, or similar > instrument can work wonders, since they are much longer than > fingers. I, too, have had to peel patch cables with boots off the front of a 4506; it is indeed no fun. That's not really where they belong, though; they belong on 6-12'+ *drop* cables, not on patch cables. There, they're useful in saving you having to reconnectorize a cable when you pull the clip off, while back-fishing it. You can -- and should -- order frame patch cables without the boots. 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 web at typo.org Sun Dec 23 01:07:16 2012 From: web at typo.org (Wayne E Bouchard) Date: Sat, 22 Dec 2012 18:07:16 -0700 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> Message-ID: <20121223010716.GA56257@wakko.typo.org> On Sat, Dec 22, 2012 at 12:50:52AM -0600, Jimmy Hess wrote: > On 12/21/12, Naslund, Steve wrote: > > I have noticed that too. However it is not the RJ-45 connector's fault. > > It is the morons that insist on recessing connectors in places where you > > can't get your finger on the tab. I like the patch cords that have the > > Likely any connector with a latching retention mechanism requiring a > manual release will have this kind of problem in space-constrained > situations. A small flat edge screwdriver, spudger, or similar > instrument can work wonders, since they are much longer than > fingers. Usually car keys are what are most readily at hand for me. :) They serve quite well until I get to a switch that some douchebag mounted rear facing on the front posts of the rack with servers above and below and I just stand there cursing for a while as I scratch my head trying to figure out how the hell to even get to the tab in the first place... -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From ben at bencarleton.com Sun Dec 23 05:31:51 2012 From: ben at bencarleton.com (Ben Carleton) Date: Sun, 23 Dec 2012 00:31:51 -0500 Subject: Hurricane Electric Tunnelbroker staff? Message-ID: <50D69747.2060806@bencarleton.com> Hi folks, I am seeing an IPv6-connected host on my network (which is on a HE.net tunnel) apparently being portscanned by an HE server at 2001:470:0:64::2 for about the last hour or so. It is trying to hit several different ports four times each before moving on and eventually repeating itself. If anyone from HE can shed some light on what's going on here it would be greatly appreciated, I can provide the IP of the host in question off-list if needed. Thanks, -- Ben From aledm at qix.co.uk Sun Dec 23 12:44:55 2012 From: aledm at qix.co.uk (Aled Morris) Date: Sun, 23 Dec 2012 12:44:55 +0000 Subject: why haven't ethernet connectors changed? In-Reply-To: <20121223010716.GA56257@wakko.typo.org> References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> <20121223010716.GA56257@wakko.typo.org> Message-ID: On 23 December 2012 01:07, Wayne E Bouchard wrote: > They serve quite well until I get to a switch that some douchebag > mounted rear facing on the front posts of the rack I see this all the time with low-end Cisco ISR products (2... and 3... routers) since CIsco insist on having a "pretty" plastic fascia with their logo, model number, power LED etc. on the unuseful side. Less experienced installers (being generous with my terminology) assume this is therefore the "front" and mount it facing on the front rails, leaving the connector side buried half way into the rack where only a proctologist can reach the plugs. I use this as a gauge of experience in interviews for engineers... "Here's a new router and here's the rack mount ears. Show me where they go." Aled From bruns at 2mbit.com Sun Dec 23 17:21:16 2012 From: bruns at 2mbit.com (Brielle Bruns) Date: Sun, 23 Dec 2012 10:21:16 -0700 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> <20121223010716.GA56257@wakko.typo.org> Message-ID: <50D73D8C.2050201@2mbit.com> On 12/23/12 5:44 AM, Aled Morris wrote: > On 23 December 2012 01:07, Wayne E Bouchard wrote: > >> They serve quite well until I get to a switch that some douchebag >> mounted rear facing on the front posts of the rack > > > > I see this all the time with low-end Cisco ISR products (2... and 3... > routers) since CIsco insist on having a "pretty" plastic fascia with their > logo, model number, power LED etc. on the unuseful side. Less experienced > installers (being generous with my terminology) assume this is therefore > the "front" and mount it facing on the front rails, leaving the connector > side buried half way into the rack where only a proctologist can reach the > plugs. > And this would be one of the many reasons why nearly all of the 1900s 2900s, 2600s and even the behemoth 7507 we have sitting around the shop have no more plastic bezels on them. :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From hcb at netcases.net Sun Dec 23 18:03:09 2012 From: hcb at netcases.net (Howard C. Berkowitz) Date: Sun, 23 Dec 2012 13:03:09 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> <20121223010716.GA56257@wakko.typo.org> Message-ID: <50D7475D.5060301@netcases.net> On 12/23/2012 7:44 AM, Aled Morris wrote: > On 23 December 2012 01:07, Wayne E Bouchard wrote: > >> They serve quite well until I get to a switch that some douchebag >> mounted rear facing on the front posts of the rack > > > I see this all the time with low-end Cisco ISR products (2... and 3... > routers) since CIsco insist on having a "pretty" plastic fascia with their > logo, model number, power LED etc. on the unuseful side. Such routers have two fronts: a suit side and an operational side. > Less experienced > installers (being generous with my terminology) assume this is therefore > the "front" and mount it facing on the front rails, leaving the connector > side buried half way into the rack where only a proctologist can reach the > plugs. For further detail about the latter: http://f2.org/humour/songs/crs.html > > I use this as a gauge of experience in interviews for engineers... "Here's > a new router and here's the rack mount ears. Show me where they go." > > Aled > From nick at pelagiris.org Sun Dec 23 19:05:24 2012 From: nick at pelagiris.org (Nick B) Date: Sun, 23 Dec 2012 14:05:24 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: <50D7475D.5060301@netcases.net> References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> <20121223010716.GA56257@wakko.typo.org> <50D7475D.5060301@netcases.net> Message-ID: The "Nonfunctional" side is critical for the LPI obsessed C?O demographic, and is therefor mandatory for most products. I wish I didn't know that. Nick On Sun, Dec 23, 2012 at 1:03 PM, Howard C. Berkowitz wrote: > On 12/23/2012 7:44 AM, Aled Morris wrote: > >> On 23 December 2012 01:07, Wayne E Bouchard wrote: >> >> They serve quite well until I get to a switch that some douchebag >>> mounted rear facing on the front posts of the rack >>> >> >> >> I see this all the time with low-end Cisco ISR products (2... and 3... >> routers) since CIsco insist on having a "pretty" plastic fascia with their >> logo, model number, power LED etc. on the unuseful side. >> > > Such routers have two fronts: a suit side and an operational side. > > Less experienced >> installers (being generous with my terminology) assume this is therefore >> the "front" and mount it facing on the front rails, leaving the connector >> side buried half way into the rack where only a proctologist can reach the >> plugs. >> > For further detail about the latter: http://f2.org/humour/songs/**crs.html > > >> I use this as a gauge of experience in interviews for engineers... >> "Here's >> a new router and here's the rack mount ears. Show me where they go." >> >> Aled >> >> > > From nanog at afxr.net Sun Dec 23 22:06:52 2012 From: nanog at afxr.net (Randy) Date: Sun, 23 Dec 2012 16:06:52 -0600 Subject: Hurricane Electric Tunnelbroker staff? In-Reply-To: <50D74458.3010106@afxr.net> References: <50D74458.3010106@afxr.net> Message-ID: <50D7807C.4010308@afxr.net> > Hi folks, > > I am seeing an IPv6-connected host on my network (which is on a HE.net > tunnel) apparently being portscanned by an HE server at > 2001:470:0:64::2 for about the last hour or so. It is trying to hit > several different ports four times each before moving on and > eventually repeating itself. > > If anyone from HE can shed some light on what's going on here it would > be greatly appreciated, I can provide the IP of the host in question > off-list if needed. > > Thanks, > -- Ben Their contact is ipv6 at he.net Pretty quick response last time I contacted them. The port scans are usually the result of the initiator of the tunnel activating a simple security scanner. As far as I know it works only on an address that is bound to their account. It shouldn't be repeating itself unless there is some sort of error. From ben at bencarleton.com Sun Dec 23 22:15:44 2012 From: ben at bencarleton.com (Ben Carleton) Date: Sun, 23 Dec 2012 17:15:44 -0500 Subject: Hurricane Electric Tunnelbroker staff? In-Reply-To: <50D69747.2060806@bencarleton.com> References: <50D69747.2060806@bencarleton.com> Message-ID: <50D78290.4000209@bencarleton.com> On 12/23/2012 12:31 AM, Ben Carleton wrote: > Hi folks, > > I am seeing an IPv6-connected host on my network (which is on a HE.net > tunnel) apparently being portscanned by an HE server at > 2001:470:0:64::2 for about the last hour or so. It is trying to hit > several different ports four times each before moving on and > eventually repeating itself. > > If anyone from HE can shed some light on what's going on here it would > be greatly appreciated, I can provide the IP of the host in question > off-list if needed. > > Thanks, > -- Ben > Thank you to everyone who responded on and off-list, we've got this resolved. -- Ben From baconzombie at gmail.com Sun Dec 23 22:18:02 2012 From: baconzombie at gmail.com (Bacon Zombie) Date: Sun, 23 Dec 2012 22:18:02 +0000 Subject: Hurricane Electric Tunnelbroker staff? In-Reply-To: <50D69747.2060806@bencarleton.com> References: <50D69747.2060806@bencarleton.com> Message-ID: Can I ask why you count a port scan at something bad? Or is it just the length of time it has been running for and it re-running the same scan repetitively? ???????????????????? ?????????????????????????????? ?????????????????????????????? On 23 December 2012 05:31, Ben Carleton wrote: > Hi folks, > > I am seeing an IPv6-connected host on my network (which is on a HE.net > tunnel) apparently being portscanned by an HE server at 2001:470:0:64::2 > for about the last hour or so. It is trying to hit several different ports > four times each before moving on and eventually repeating itself. > > If anyone from HE can shed some light on what's going on here it would be > greatly appreciated, I can provide the IP of the host in question off-list > if needed. > > Thanks, > -- Ben > > -- BaconZombie LOAD "*",8,1 From ben at bencarleton.com Sun Dec 23 22:32:06 2012 From: ben at bencarleton.com (Ben Carleton) Date: Sun, 23 Dec 2012 17:32:06 -0500 Subject: Hurricane Electric Tunnelbroker staff? In-Reply-To: References: <50D69747.2060806@bencarleton.com> <50D78290.4000209@bencarleton.com> Message-ID: <50D78666.8080909@bencarleton.com> On 12/23/2012 5:23 PM, Constantine A. Murenin wrote: > On 23 December 2012 14:15, Ben Carleton wrote: >> On 12/23/2012 12:31 AM, Ben Carleton wrote: >>> Hi folks, >>> >>> I am seeing an IPv6-connected host on my network (which is on a HE.net >>> tunnel) apparently being portscanned by an HE server at 2001:470:0:64::2 for >>> about the last hour or so. It is trying to hit several different ports four >>> times each before moving on and eventually repeating itself. >>> >>> If anyone from HE can shed some light on what's going on here it would be >>> greatly appreciated, I can provide the IP of the host in question off-list >>> if needed. >>> >>> Thanks, >>> -- Ben >>> >> Thank you to everyone who responded on and off-list, we've got this >> resolved. > Don't worry, we don't care for what the resolution is; no need to post > it to the list, either, the next person can just re-post this question > anyways! > > Thank you for wasting everyone's time! > > C. I actually have no idea what the resolution was. All I know is that when I checked again a few hours later, the traffic had stopped, which, to be honest, is good enough for me. -- Ben From wbailey at satelliteintelligencegroup.com Sun Dec 23 23:32:31 2012 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 23 Dec 2012 23:32:31 +0000 Subject: Hurricane Electric Tunnelbroker staff? In-Reply-To: References: <50D69747.2060806@bencarleton.com>, Message-ID: Be aware.. There have been reports of bacon zombies port scanning lately. >From my Galaxy Note II, please excuse any mistakes. -------- Original message -------- From: Bacon Zombie Date: 12/23/2012 3:20 PM (GMT-07:00) To: Cc: nanog at nanog.org Subject: Re: Hurricane Electric Tunnelbroker staff? Can I ask why you count a port scan at something bad? Or is it just the length of time it has been running for and it re-running the same scan repetitively? ???????????????????? ?????????????????????????????? ?????????????????????????????? On 23 December 2012 05:31, Ben Carleton wrote: > Hi folks, > > I am seeing an IPv6-connected host on my network (which is on a HE.net > tunnel) apparently being portscanned by an HE server at 2001:470:0:64::2 > for about the last hour or so. It is trying to hit several different ports > four times each before moving on and eventually repeating itself. > > If anyone from HE can shed some light on what's going on here it would be > greatly appreciated, I can provide the IP of the host in question off-list > if needed. > > Thanks, > -- Ben > > -- BaconZombie LOAD "*",8,1 From joelja at bogus.com Mon Dec 24 00:39:34 2012 From: joelja at bogus.com (joel jaeggli) Date: Sun, 23 Dec 2012 16:39:34 -0800 Subject: Validation of FCS In-Reply-To: <20121219150212.GA11882@pob.ytti.fi> References: <4D53609B-8772-4B93-A75E-294AD7DB3DF1@lixfeld.ca> <20121219150212.GA11882@pob.ytti.fi> Message-ID: <50D7A446.6070300@bogus.com> On 12/19/12 7:02 AM, Saku Ytti wrote: > On (2012-12-19 09:53 -0500), Jason Lixfeld wrote: > >> Perhaps in simpler terms, a CRC error is a localized thing and would >> never be forwarded from one device to another. > It would be forwarded in cut-through switching. > I have cut-through switches (arista) that log these as TX errors, they have already left the barn at that point. From nick at foobar.org Mon Dec 24 10:14:53 2012 From: nick at foobar.org (Nick Hilliard) Date: Mon, 24 Dec 2012 10:14:53 +0000 Subject: Validation of FCS In-Reply-To: <50D7A446.6070300@bogus.com> References: <4D53609B-8772-4B93-A75E-294AD7DB3DF1@lixfeld.ca> <20121219150212.GA11882@pob.ytti.fi> <50D7A446.6070300@bogus.com> Message-ID: <50D82B1D.3010403@foobar.org> On 24/12/2012 00:39, joel jaeggli wrote: > I have cut-through switches (arista) that log these as TX errors, they have > already left the barn at that point. it's a real pain when this happens because you have no idea of the ingress port and consequently the source of the data corruption source. The same happens for regular packet drops on some cut-thru switches (e.g. brocade ti-24x). Annoying. Nick From Valdis.Kletnieks at vt.edu Mon Dec 24 12:53:26 2012 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 24 Dec 2012 07:53:26 -0500 Subject: why haven't ethernet connectors changed? In-Reply-To: Your message of "Sat, 22 Dec 2012 18:07:16 -0700." <20121223010716.GA56257@wakko.typo.org> References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> <20121223010716.GA56257@wakko.typo.org> Message-ID: <155727.1356353606@turing-police.cc.vt.edu> On Sat, 22 Dec 2012 18:07:16 -0700, Wayne E Bouchard said: > They serve quite well until I get to a switch that some douchebag > mounted rear facing on the front posts of the rack with servers above > and below and I just stand there cursing for a while as I scratch my > head trying to figure out how the hell to even get to the tab in the > first place... Has anybody ever seen this with a switch that's 2U or thicker? I've only seen it perpetrated with 1U switches, a situation that usually results in my lapsing into Russian.... (For the record, my knowledge of Russian is limited to those words that Latvian carpenters reserve for hammers that aim at thumbs. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jra at baylink.com Mon Dec 24 16:52:54 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 24 Dec 2012 11:52:54 -0500 (EST) Subject: Fun With Plasma (Re: Fiber only in DataCenters?) In-Reply-To: Message-ID: <15857013.39410.1356367974131.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "George Herbert" > I have also, independently, melted and partly vaporized multiple cubic > centimeters of 8 ga wire with a (purely accidental, I assure you) > short of 12 volts from a serial stack of D-cell sized NiCd > rechargeable batteries. The same works well with an old car 12 V > battery and any conductor up to wrenches (not recommended at home...). > > What's the old saying? Volts hurt, Amps kill? Yep. Back in... this would have had to be 1994 or 5, the St Petersburg Main GTE CO (SPBFLXA89F, I think) was off the air for about 12 hours. Completely off the air. As I understood the story later, some New Guy went into the battery room to do some work, and had not yet gotten the memo about vinyl-dipped tools. He supposedly got a 12" crescent wrench across the main bussbars. Now, to properly appreciate this, you have to know that while the load *at that time* was 30k lines of GTD5 and 2 50k line 5ESS remotes... the building was 7 stories tall... and was originally all crossbar. That battery room was rated, I was told, for about 8000A continuous at -52VDC nominal. The wrench flashed over into plasma on the spot; they never found any of it. Just zits on the bussbars where it hit. The guy was deaf for about a week. I never did hear if he lost his job or not. They probably took the cost of deploying all of St Pete's Police out to strategic street corners to take emergency reports out of his paycheck, though. 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 jra at baylink.com Mon Dec 24 16:55:02 2012 From: jra at baylink.com (Jay Ashworth) Date: Mon, 24 Dec 2012 11:55:02 -0500 (EST) Subject: Fiber only in DataCenters? In-Reply-To: <1141EC75-506E-4A54-A9AD-823A72858A45@delong.com> Message-ID: <28666166.39412.1356368102886.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > A 24ga cat-6 wire can take millions of volts as long as you keep the > amperage low enough. No it can't; the insulation's only rated for 250V or so. You get much past a kilovolt and it will flash over. 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 web at typo.org Mon Dec 24 23:18:00 2012 From: web at typo.org (Wayne E Bouchard) Date: Mon, 24 Dec 2012 16:18:00 -0700 Subject: why haven't ethernet connectors changed? In-Reply-To: <155727.1356353606@turing-police.cc.vt.edu> References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> <20121223010716.GA56257@wakko.typo.org> <155727.1356353606@turing-police.cc.vt.edu> Message-ID: <20121224231800.GA63276@wakko.typo.org> On Mon, Dec 24, 2012 at 07:53:26AM -0500, Valdis.Kletnieks at vt.edu wrote: > On Sat, 22 Dec 2012 18:07:16 -0700, Wayne E Bouchard said: > > > They serve quite well until I get to a switch that some douchebag > > mounted rear facing on the front posts of the rack with servers above > > and below and I just stand there cursing for a while as I scratch my > > head trying to figure out how the hell to even get to the tab in the > > first place... > > Has anybody ever seen this with a switch that's 2U or thicker? I've > only seen it perpetrated with 1U switches, a situation that usually > results in my lapsing into Russian.... 2U seems possible (can't say for certain) but larger, seems like you'd have a fair chance of being able to make something work since you can at least get your hands where they need to be... unless you can't find a ladder. > (For the record, my knowledge of Russian is limited to those words that > Latvian carpenters reserve for hammers that aim at thumbs. :) An appropriate quote: "Profanity is the one language all programmers know." Works well for engineers too. :-) -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From jrhett at netconsonance.com Tue Dec 25 06:38:08 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 24 Dec 2012 22:38:08 -0800 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <85fb3201-07f2-4a5b-a682-99507a2ba615@email.android.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <85fb3201-07f2-4a5b-a682-99507a2ba615@email.android.com> Message-ID: On Dec 20, 2012, at 9:26 PM, Charles N Wyble wrote: > Zenoss works very well Um... you lost me after the first 4 words. Zenoss might work acceptably for very, very small organizations with very small amounts of data. Zenoss is incapable of scaling to even moderate-sized data sets with tens of thousands of data sources, nevermind medium sized data sets with millions of data sources. I work at a very small shop with three total engineers and Zenoss was unable to scale beyond 1/4 of our data sources with dozens of cores and hundreds of gigabytes of RAM on numerous systems. It doesn't actually use any of these, the internal deadlocks in the architecture make it impossible for it to scale. That Zenoss might make a better IP management tool than what it is purported and sold to do... amuses. -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From eyeronic.design at gmail.com Tue Dec 25 06:48:39 2012 From: eyeronic.design at gmail.com (Mike Hale) Date: Mon, 24 Dec 2012 22:48:39 -0800 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <85fb3201-07f2-4a5b-a682-99507a2ba615@email.android.com> Message-ID: Very small shop with millions of data sources? lol? On Mon, Dec 24, 2012 at 10:38 PM, Jo Rhett wrote: > On Dec 20, 2012, at 9:26 PM, Charles N Wyble wrote: > > Zenoss works very well > > Um... you lost me after the first 4 words. Zenoss might work acceptably > for very, very small organizations with very small amounts of data. Zenoss > is incapable of scaling to even moderate-sized data sets with tens of > thousands of data sources, nevermind medium sized data sets with millions > of data sources. I work at a very small shop with three total engineers and > Zenoss was unable to scale beyond 1/4 of our data sources with dozens of > cores and hundreds of gigabytes of RAM on numerous systems. It doesn't > actually use any of these, the internal deadlocks in the architecture make > it impossible for it to scale. > > That Zenoss might make a better IP management tool than what it is > purported and sold to do... amuses. > > -- > Jo Rhett > Net Consonance : net philanthropy to improve open source and internet > projects. > > > > > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From jrhett at netconsonance.com Tue Dec 25 06:53:11 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 24 Dec 2012 22:53:11 -0800 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <85fb3201-07f2-4a5b-a682-99507a2ba615@email.android.com> Message-ID: <1084BBA1-BAAC-4EA4-9FF8-BC972E7F35D9@netconsonance.com> Small shop people wise with millions of customers and tens of thousands of application and log-derived data sources. We use Zenoss extensively and mostly we keep having to make decisions what data to pull out of it so it can function. I have previously worked at larger enterprises which had millions of data sources, and Zenoss couldn't dream of handling that, no matter how much hardware we threw at it. On Dec 24, 2012, at 10:48 PM, Mike Hale wrote: > Very small shop with millions of data sources? > > lol? > > > On Mon, Dec 24, 2012 at 10:38 PM, Jo Rhett wrote: > On Dec 20, 2012, at 9:26 PM, Charles N Wyble wrote: > > Zenoss works very well > > Um... you lost me after the first 4 words. Zenoss might work acceptably for very, very small organizations with very small amounts of data. Zenoss is incapable of scaling to even moderate-sized data sets with tens of thousands of data sources, nevermind medium sized data sets with millions of data sources. I work at a very small shop with three total engineers and Zenoss was unable to scale beyond 1/4 of our data sources with dozens of cores and hundreds of gigabytes of RAM on numerous systems. It doesn't actually use any of these, the internal deadlocks in the architecture make it impossible for it to scale. > > That Zenoss might make a better IP management tool than what it is purported and sold to do... amuses. > > -- > Jo Rhett > Net Consonance : net philanthropy to improve open source and internet projects. > > > > > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. From eyeronic.design at gmail.com Tue Dec 25 06:57:50 2012 From: eyeronic.design at gmail.com (Mike Hale) Date: Mon, 24 Dec 2012 22:57:50 -0800 Subject: IP Address Management IPAM software for small ISP In-Reply-To: <1084BBA1-BAAC-4EA4-9FF8-BC972E7F35D9@netconsonance.com> References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <85fb3201-07f2-4a5b-a682-99507a2ba615@email.android.com> <1084BBA1-BAAC-4EA4-9FF8-BC972E7F35D9@netconsonance.com> Message-ID: Ahhh. That sucks. I've never put our Zenoss installs through quite that much traffic. That's a shame to hear. On Mon, Dec 24, 2012 at 10:53 PM, Jo Rhett wrote: > Small shop people wise with millions of customers and tens of thousands of > application and log-derived data sources. We use Zenoss extensively and > mostly we keep having to make decisions what data to pull out of it so it > can function. > > I have previously worked at larger enterprises which had millions of data > sources, and Zenoss couldn't dream of handling that, no matter how much > hardware we threw at it. > > > On Dec 24, 2012, at 10:48 PM, Mike Hale wrote: > > Very small shop with millions of data sources? > > lol? > > > On Mon, Dec 24, 2012 at 10:38 PM, Jo Rhett wrote: > >> On Dec 20, 2012, at 9:26 PM, Charles N Wyble wrote: >> > Zenoss works very well >> >> Um... you lost me after the first 4 words. Zenoss might work acceptably >> for very, very small organizations with very small amounts of data. Zenoss >> is incapable of scaling to even moderate-sized data sets with tens of >> thousands of data sources, nevermind medium sized data sets with millions >> of data sources. I work at a very small shop with three total engineers and >> Zenoss was unable to scale beyond 1/4 of our data sources with dozens of >> cores and hundreds of gigabytes of RAM on numerous systems. It doesn't >> actually use any of these, the internal deadlocks in the architecture make >> it impossible for it to scale. >> >> That Zenoss might make a better IP management tool than what it is >> purported and sold to do... amuses. >> >> -- >> Jo Rhett >> Net Consonance : net philanthropy to improve open source and internet >> projects. >> >> >> >> >> > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > > > -- > Jo Rhett > Net Consonance : net philanthropy to improve open source and internet > projects. > > > > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From eugen at imacandi.net Wed Dec 26 21:32:07 2012 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Wed, 26 Dec 2012 23:32:07 +0200 Subject: why haven't ethernet connectors changed? In-Reply-To: <20121224231800.GA63276@wakko.typo.org> References: <50D356DB.5090809@mtcc.com> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3E812@MUNEXBE1.medline.com> <616B4ECE1290D441AD56124FEBB03D080E5E262492@mailserver2007.nyigc.globe> <2A76E400AC84B845AAC35AA19F8E7A5D0DB3EA1E@MUNEXBE1.medline.com> <20121223010716.GA56257@wakko.typo.org> <155727.1356353606@turing-police.cc.vt.edu> <20121224231800.GA63276@wakko.typo.org> Message-ID: You should give Apple a hint about designing a new Ethernet connector :)) They'll give you few tens of million users wanting new network equipment :)) From positivelyoptimistic at gmail.com Wed Dec 26 21:43:55 2012 From: positivelyoptimistic at gmail.com (Positively Optimistic) Date: Wed, 26 Dec 2012 15:43:55 -0600 Subject: regions.com down?? Message-ID: Is http://www.regions.com down globally? From j at 2600hz.com Wed Dec 26 21:46:17 2012 From: j at 2600hz.com (Joshua Goldbard) Date: Wed, 26 Dec 2012 21:46:17 +0000 Subject: regions.com down?? In-Reply-To: References: Message-ID: Http://www.downforeveryoneorjustme.com/regions.com Down. Sent from my iPad On Dec 26, 2012, at 1:45 PM, "Positively Optimistic" wrote: > Is http://www.regions.com down globally? From jake at nobistech.net Wed Dec 26 21:46:25 2012 From: jake at nobistech.net (Jake Mertel) Date: Wed, 26 Dec 2012 21:46:25 +0000 Subject: [HMS-SPAM] regions.com down?? In-Reply-To: References: Message-ID: Confirmed down from my site in Los Angeles via nLayer. Chrome says "Error 101 (net::ERR_CONNECTION_RESET): The connection was reset". C:\Users\jake>tracert regions.com Tracing route to regions.com [205.255.243.11] over a maximum of 30 hops: 1 24 ms 14 ms 5 ms v403.er01.lax.ubiquity.io [72.37.224.129] 2 1 ms 1 ms 4 ms xe-1-0-3.ar1.lax2.us.nlayer.net [69.31.127.45] 3 <1 ms <1 ms <1 ms ae1-80g.cr1.lax1.us.nlayer.net [69.31.127.129] 4 9 ms 1 ms 1 ms ae2-50g.ar1.lax1.us.nlayer.net [69.31.127.142] 5 <1 ms <1 ms <1 ms as3549.xe-9-0-0.ar1.lax1.us.nlayer.net [69.31.127.190] 6 <1 ms 1 ms <1 ms ae1.scr3.LAX1.gblx.net [67.16.162.173] 7 131 ms 146 ms 131 ms xe2-2-0-10G.scr3.LON3.gblx.net [67.16.165.66] 8 132 ms 141 ms 132 ms lag1.ar9.LON3.gblx.net [67.17.72.21] 9 141 ms 160 ms 142 ms HIGHWINDS-NETWORK-GROUP.TenGigabitEthernet9-1.ar4.LON3.gblx.net [64.210.29.54] 10 * * * Request timed out. 11 * * * Request timed out. 12 --Jake -----Original Message----- From: Positively Optimistic [mailto:positivelyoptimistic at gmail.com] Sent: Wednesday, December 26, 2012 2:44 PM To: nanog list Subject: [HMS-SPAM] regions.com down?? Is http://www.regions.com down globally? From scott at doc.net.au Wed Dec 26 21:50:54 2012 From: scott at doc.net.au (Scott Howard) Date: Wed, 26 Dec 2012 13:50:54 -0800 Subject: regions.com down?? In-Reply-To: References: Message-ID: But only over HTTP. Working fine over HTTPS for me. Scott On Wed, Dec 26, 2012 at 1:46 PM, Joshua Goldbard wrote: > Http://www.downforeveryoneorjustme.com/regions.com > > Down. > > Sent from my iPad > > On Dec 26, 2012, at 1:45 PM, "Positively Optimistic" < > positivelyoptimistic at gmail.com> wrote: > > > Is http://www.regions.com down globally? > > From christopher.morrow at gmail.com Wed Dec 26 22:01:06 2012 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 26 Dec 2012 17:01:06 -0500 Subject: regions.com down?? In-Reply-To: References: Message-ID: Most ddos games On Dec 26, 2012 4:53 PM, "Scott Howard" wrote: > But only over HTTP. Working fine over HTTPS for me. > > Scott > > > > On Wed, Dec 26, 2012 at 1:46 PM, Joshua Goldbard wrote: > > > Http://www.downforeveryoneorjustme.com/regions.com > > > > Down. > > > > Sent from my iPad > > > > On Dec 26, 2012, at 1:45 PM, "Positively Optimistic" < > > positivelyoptimistic at gmail.com> wrote: > > > > > Is http://www.regions.com down globally? > > > > > From g at 1337.io Thu Dec 27 02:50:58 2012 From: g at 1337.io (g at 1337.io) Date: Wed, 26 Dec 2012 18:50:58 -0800 Subject: regions.com down?? In-Reply-To: References: Message-ID: <50DBB792.8010704@1337.io> Looks like walmart.com is down as well >.> http://www.downforeveryoneorjustme.com/www.walmart.com On 12/26/12 1:50 PM, Scott Howard wrote: > But only over HTTP. Working fine over HTTPS for me. > > Scott > > > > On Wed, Dec 26, 2012 at 1:46 PM, Joshua Goldbard wrote: > >> Http://www.downforeveryoneorjustme.com/regions.com >> >> Down. >> >> Sent from my iPad >> >> On Dec 26, 2012, at 1:45 PM, "Positively Optimistic" < >> positivelyoptimistic at gmail.com> wrote: >> >>> Is http://www.regions.com down globally? >> >> -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From lyle at lcrcomputer.net Thu Dec 27 03:28:37 2012 From: lyle at lcrcomputer.net (Lyle Giese) Date: Wed, 26 Dec 2012 21:28:37 -0600 Subject: regions.com down?? In-Reply-To: <50DBB792.8010704@1337.io> References: <50DBB792.8010704@1337.io> Message-ID: <50DBC065.2040802@lcrcomputer.net> Looks like ultradns is hosed. If you ask pdns193.ultradns.net or .com for root, it sends back a non answer quickly. But ask the same servers for www.walmart.com and they don't answer at all. Lyle Giese LCR Computer Services, Inc. ncc1701b:~ # dig +trace www.walmart.com ; <<>> DiG 9.8.4-P1 <<>> +trace www.walmart.com ;; global options: +cmd . 310180 IN NS g.root-servers.net. . 310180 IN NS i.root-servers.net. . 310180 IN NS k.root-servers.net. . 310180 IN NS a.root-servers.net. . 310180 IN NS e.root-servers.net. . 310180 IN NS c.root-servers.net. . 310180 IN NS h.root-servers.net. . 310180 IN NS l.root-servers.net. . 310180 IN NS j.root-servers.net. . 310180 IN NS f.root-servers.net. . 310180 IN NS d.root-servers.net. . 310180 IN NS b.root-servers.net. . 310180 IN NS m.root-servers.net. ;; Received 512 bytes from 209.172.152.2#53(209.172.152.2) in 10 ms com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. ;; Received 505 bytes from 198.41.0.4#53(198.41.0.4) in 122 ms walmart.com. 172800 IN NS pdns193.ultradns.net. walmart.com. 172800 IN NS pdns193.ultradns.com. walmart.com. 172800 IN NS pdns193.ultradns.org. walmart.com. 172800 IN NS pdns193.ultradns.info. walmart.com. 172800 IN NS pdns193.ultradns.biz. walmart.com. 172800 IN NS pdns193.ultradns.co.uk. ;; Received 325 bytes from 192.41.162.30#53(192.41.162.30) in 74 ms Halts here and I ctrl-C out ncc1701b:~ # dig @pdns193.ultradns.net ; <<>> DiG 9.8.4-P1 <<>> @pdns193.ultradns.net ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36432 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS ;; Query time: 48 msec ;; SERVER: 156.154.65.193#53(156.154.65.193) ;; WHEN: Wed Dec 26 21:25:29 2012 ;; MSG SIZE rcvd: 17 ncc1701b:~ # dig @pdns193.ultradns.net www.walmart.com ; <<>> DiG 9.8.4-P1 <<>> @pdns193.ultradns.net www.walmart.com ; (2 servers found) ;; global options: +cmd ;; connection timed out; no servers could be reached ncc1701b: On 12/26/12 20:50, g at 1337.io wrote: > Looks like walmart.com is down as well >.> > > http://www.downforeveryoneorjustme.com/www.walmart.com > > On 12/26/12 1:50 PM, Scott Howard wrote: >> But only over HTTP. Working fine over HTTPS for me. >> >> Scott >> >> >> >> On Wed, Dec 26, 2012 at 1:46 PM, Joshua Goldbard wrote: >> >>> Http://www.downforeveryoneorjustme.com/regions.com >>> >>> Down. >>> >>> Sent from my iPad >>> >>> On Dec 26, 2012, at 1:45 PM, "Positively Optimistic" < >>> positivelyoptimistic at gmail.com> wrote: >>> >>>> Is http://www.regions.com down globally? >>> From bill at herrin.us Thu Dec 27 04:03:57 2012 From: bill at herrin.us (William Herrin) Date: Wed, 26 Dec 2012 23:03:57 -0500 Subject: regions.com down?? In-Reply-To: <50DBB792.8010704@1337.io> References: <50DBB792.8010704@1337.io> Message-ID: On Wed, Dec 26, 2012 at 9:50 PM, g at 1337.io wrote: > Looks like walmart.com is down as well >.> > > http://www.downforeveryoneorjustme.com/www.walmart.com www.vonage.com too. Very slow DNS resolution and then when it finally does resolve, tcp 80 doesn't connect. -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From frnkblk at iname.com Thu Dec 27 04:10:46 2012 From: frnkblk at iname.com (Frank Bulk (iname.com)) Date: Wed, 26 Dec 2012 22:10:46 -0600 Subject: regions.com down?? In-Reply-To: References: <50DBB792.8010704@1337.io> Message-ID: <003801cde3e8$25d05320$7170f960$@iname.com> Looks like an operational issue: Frank -----Original Message----- From: William Herrin [mailto:bill at herrin.us] Sent: Wednesday, December 26, 2012 10:04 PM To: g at 1337.io Cc: nanog at nanog.org Subject: Re: regions.com down?? On Wed, Dec 26, 2012 at 9:50 PM, g at 1337.io < g at 1337.io> wrote: > Looks like walmart.com is down as well >.> > > http://www.downforeveryoneorjustme.com/www.walmart.com www.vonage.com too. Very slow DNS resolution and then when it finally does resolve, tcp 80 doesn't connect. -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: < http://bill.herrin.us/> Falls Church, VA 22042-3004 -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 14209 bytes Desc: not available URL: From eric at roxanne.org Thu Dec 27 13:01:11 2012 From: eric at roxanne.org (Eric) Date: Thu, 27 Dec 2012 08:01:11 -0500 Subject: IP Address Management IPAM software for small ISP In-Reply-To: References: <1355361756.78848.YahooMailRC@web181606.mail.ne1.yahoo.com> <20121220071143.GA12392@pob.ytti.fi> <85fb3201-07f2-4a5b-a682-99507a2ba615@email.android.com> <1084BBA1-BAAC-4EA4-9FF8-BC972E7F35D9@netconsonance.com> Message-ID: I ran Zenoss for a network with about 5k - 7k switches/APs, about 100 L3 devices (routers, firewalls), and about 50 servers/appliances without any polling problems. This was a few years ago on the open source product. With that said, we were reluctant to expand this to monitor the rest of our enterprise as the open source version didn't support distributed polling/collection, which might be the scaling issue Jo mentioned... That, unfortunately, was only available in the paid "enterprise" one. Other than that, we really liked it. On Dec 25, 2012, at 1:57 AM, Mike Hale wrote: > Ahhh. > > That sucks. I've never put our Zenoss installs through quite that much > traffic. That's a shame to hear. > > > On Mon, Dec 24, 2012 at 10:53 PM, Jo Rhett wrote: > >> Small shop people wise with millions of customers and tens of thousands of >> application and log-derived data sources. We use Zenoss extensively and >> mostly we keep having to make decisions what data to pull out of it so it >> can function. >> >> I have previously worked at larger enterprises which had millions of data >> sources, and Zenoss couldn't dream of handling that, no matter how much >> hardware we threw at it. >> >> >> On Dec 24, 2012, at 10:48 PM, Mike Hale wrote: >> >> Very small shop with millions of data sources? >> >> lol? >> >> >> On Mon, Dec 24, 2012 at 10:38 PM, Jo Rhett wrote: >> >>> On Dec 20, 2012, at 9:26 PM, Charles N Wyble wrote: >>>> Zenoss works very well >>> >>> Um... you lost me after the first 4 words. Zenoss might work acceptably >>> for very, very small organizations with very small amounts of data. Zenoss >>> is incapable of scaling to even moderate-sized data sets with tens of >>> thousands of data sources, nevermind medium sized data sets with millions >>> of data sources. I work at a very small shop with three total engineers and >>> Zenoss was unable to scale beyond 1/4 of our data sources with dozens of >>> cores and hundreds of gigabytes of RAM on numerous systems. It doesn't >>> actually use any of these, the internal deadlocks in the architecture make >>> it impossible for it to scale. >>> >>> That Zenoss might make a better IP management tool than what it is >>> purported and sold to do... amuses. >>> >>> -- >>> Jo Rhett >>> Net Consonance : net philanthropy to improve open source and internet >>> projects. >> >> >> -- >> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 >> >> >> -- >> Jo Rhett >> Net Consonance : net philanthropy to improve open source and internet >> projects. > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From mike at mtcc.com Thu Dec 27 17:04:33 2012 From: mike at mtcc.com (mike) Date: Thu, 27 Dec 2012 09:04:33 -0800 Subject: really facebook? Message-ID: <50DC7FA1.6080504@mtcc.com> I reloaded their app (yes, I know... sew me) and got this warning: IP address: 2600:100f:b119:c6bc:bd6f:fabb:ff30:2a3d Estimated location: Livingston, NJ, US Which seems pretty bizarre. I'm guessing they must be getting it from whois or something based on the address block for Verizon. The reverse map according to host 2600:100f:b119:c6bc:bd6f:fabb:ff30:2a3d comes back with NXDOMAIN. I suppose the real issue here is with Vz and why they don't have v6 reverse maps, but it did throw me thinking that somebody in New Jersey might have hacked my account. Mike From joelja at bogus.com Thu Dec 27 17:25:58 2012 From: joelja at bogus.com (joel jaeggli) Date: Thu, 27 Dec 2012 09:25:58 -0800 Subject: really facebook? In-Reply-To: <50DC7FA1.6080504@mtcc.com> References: <50DC7FA1.6080504@mtcc.com> Message-ID: <50DC84A6.2090505@bogus.com> On 12/27/12 9:04 AM, mike wrote: > > I reloaded their app (yes, I know... sew me) and got this warning: > > IP address: 2600:100f:b119:c6bc:bd6f:fabb:ff30:2a3d > Estimated location: Livingston, NJ, US That's a rather good estimation of where many verizon wireless customers appear to come from. > Which seems pretty bizarre. I'm guessing they must be getting it from > whois or something based on the address block for Verizon. The reverse > map according to > > host 2600:100f:b119:c6bc:bd6f:fabb:ff30:2a3d one assumes they have a an geoip database like they have for ipv4 > > comes back with NXDOMAIN. I suppose the real issue here is with Vz > and why they don't have v6 reverse maps, but it did throw me thinking > that > somebody in New Jersey might have hacked my account. Well could certainly wildcard their responses, not sure that dynamic dns updates would be either scalable or appropiate. > > Mike > From nanog at data102.com Thu Dec 27 18:19:52 2012 From: nanog at data102.com (randal k) Date: Thu, 27 Dec 2012 11:19:52 -0700 Subject: Netflix transit preference? Message-ID: Hey NANOG! I work at a datacenter in southern Colorado that is the upstream bandwidth provider for several regional ISPs. We have been investigating our ever-growing bandwidth usage and have found that out of transits (Level3,Cogent,HE) that Netflix always seems to come in via Hurricane Electric. (We move ~1.4gbps to Netflix, and are thus not a candidate for peering. And they have no POP close.) I tested this by advertising a /24 across all providers, then selectively removed the advertisement to certain carriers to see where the bandwidth goes. In order, it appears that if there is a HE route, Netflix uses it, period. If there isn't, it prefers Level3, and Cogent comes last. Since Netflix is a big hunk of our bandwidth (and obviously makes our customers happy), we are included to buy some more HE. However, if Netflix decides that they want to randomly switch to, say, Cogent, we may be under a year-long bandwidth contract that isn't particularly valuable anymore. With all of that, I am interested in finding out of any knowledge about Netflix transit preferences, be it inside information, anecdotal, or otherwise. I did email peering@ but haven't heard back, thus the public question. Thanks! Randal From patrick at ianai.net Thu Dec 27 18:26:39 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 27 Dec 2012 13:26:39 -0500 Subject: Netflix transit preference? In-Reply-To: References: Message-ID: <3650991A-1AF5-4089-8236-38A440C13C06@ianai.net> On Dec 27, 2012, at 13:19 , randal k wrote: > I work at a datacenter in southern Colorado that is the upstream bandwidth > provider for several regional ISPs. We have been investigating our > ever-growing bandwidth usage and have found that out of transits > (Level3,Cogent,HE) that Netflix always seems to come in via Hurricane > Electric. (We move ~1.4gbps to Netflix, and are thus not a candidate for > peering. And they have no POP close.) Your statement about peering makes no sense. You are trying to engineer where their traffic comes and yet you refuse to have a direct connection which would give you full control? Weird....... > I tested this by advertising a /24 across all providers, then selectively > removed the advertisement to certain carriers to see where the bandwidth > goes. In order, it appears that if there is a HE route, Netflix uses it, > period. If there isn't, it prefers Level3, and Cogent comes last. Completely unsurprising. > Since Netflix is a big hunk of our bandwidth (and obviously makes our > customers happy), we are included to buy some more HE. However, if Netflix > decides that they want to randomly switch to, say, Cogent, we may be under > a year-long bandwidth contract that isn't particularly valuable anymore. > > With all of that, I am interested in finding out of any knowledge about > Netflix transit preferences, be it inside information, anecdotal, or > otherwise. I did email peering@ but haven't heard back, thus the public > question. Why don't you ask Netflix? And why not ask them for kit to put on-net? -- TTFN, patrick From mike at mtcc.com Thu Dec 27 18:29:22 2012 From: mike at mtcc.com (mike) Date: Thu, 27 Dec 2012 10:29:22 -0800 Subject: really facebook? In-Reply-To: <50DC84A6.2090505@bogus.com> References: <50DC7FA1.6080504@mtcc.com> <50DC84A6.2090505@bogus.com> Message-ID: <50DC9382.30908@mtcc.com> On 12/27/12 9:25 AM, joel jaeggli wrote: > On 12/27/12 9:04 AM, mike wrote: >> >> I reloaded their app (yes, I know... sew me) and got this warning: >> >> IP address: 2600:100f:b119:c6bc:bd6f:fabb:ff30:2a3d >> Estimated location: Livingston, NJ, US > That's a rather good estimation of where many verizon wireless customers appear to come from. This can't mean that all of their v6 traffic is backhauled to NJ, right? > >> Which seems pretty bizarre. I'm guessing they must be getting it from >> whois or something based on the address block for Verizon. The reverse >> map according to >> >> host 2600:100f:b119:c6bc:bd6f:fabb:ff30:2a3d > one assumes they have a an geoip database like they have for ipv4 >> >> comes back with NXDOMAIN. I suppose the real issue here is with Vz >> and why they don't have v6 reverse maps, but it did throw me thinking that >> somebody in New Jersey might have hacked my account. > Well could certainly wildcard their responses, not sure that dynamic dns updates would be either scalable or appropiate. Right, brain fart on my part. Reverse map has nothing to do with a geoip database. It's still strange that it has no reverse map though. I wonder what might break because of that assumption :) Mike >> >> Mike >> From jeff-kell at utc.edu Thu Dec 27 18:33:18 2012 From: jeff-kell at utc.edu (Jeff Kell) Date: Thu, 27 Dec 2012 13:33:18 -0500 Subject: Netflix transit preference? In-Reply-To: <3650991A-1AF5-4089-8236-38A440C13C06@ianai.net> References: <3650991A-1AF5-4089-8236-38A440C13C06@ianai.net> Message-ID: <50DC946E.7000600@utc.edu> On 12/27/2012 1:26 PM, Patrick W. Gilmore wrote: > On Dec 27, 2012, at 13:19 , randal k wrote: > >> (We move ~1.4gbps to Netflix, and are thus not a candidate for >> peering. And they have no POP close.) > Why don't you ask Netflix? And why not ask them for kit to put on-net? > The last time we asked, their criteria was ~2.0gbps, so he doesn't have enough qualifying traffic. Has anyone looked at a Qwilt? http://www.qwilt.com/ Jeff From david at davidswafford.com Thu Dec 27 18:34:22 2012 From: david at davidswafford.com (David Swafford) Date: Thu, 27 Dec 2012 13:34:22 -0500 Subject: really facebook? In-Reply-To: <50DC9382.30908@mtcc.com> References: <50DC7FA1.6080504@mtcc.com> <50DC84A6.2090505@bogus.com> <50DC9382.30908@mtcc.com> Message-ID: "This can't mean that all of their v6 traffic is backhauled to NJ, right?" Nah, that would be really lame for performance -- I'm pretty sure they treat V4/V6 equally :-D. david. On Thu, Dec 27, 2012 at 1:29 PM, mike wrote: > On 12/27/12 9:25 AM, joel jaeggli wrote: >> >> On 12/27/12 9:04 AM, mike wrote: >>> >>> >>> I reloaded their app (yes, I know... sew me) and got this warning: >>> >>> IP address: 2600:100f:b119:c6bc:bd6f:fabb:ff30:2a3d >>> Estimated location: Livingston, NJ, US >> >> That's a rather good estimation of where many verizon wireless customers >> appear to come from. > > > This can't mean that all of their v6 traffic is backhauled to NJ, right? > > >> >>> Which seems pretty bizarre. I'm guessing they must be getting it from >>> whois or something based on the address block for Verizon. The reverse >>> map according to >>> >>> host 2600:100f:b119:c6bc:bd6f:fabb:ff30:2a3d >> >> one assumes they have a an geoip database like they have for ipv4 >>> >>> >>> comes back with NXDOMAIN. I suppose the real issue here is with Vz >>> and why they don't have v6 reverse maps, but it did throw me thinking >>> that >>> somebody in New Jersey might have hacked my account. >> >> Well could certainly wildcard their responses, not sure that dynamic dns >> updates would be either scalable or appropiate. > > > Right, brain fart on my part. Reverse map has nothing to do with a geoip > database. > It's still strange that it has no reverse map though. I wonder what might > break because > of that assumption :) > > Mike >>> >>> >>> Mike >>> > > From joelja at bogus.com Thu Dec 27 18:40:27 2012 From: joelja at bogus.com (joel jaeggli) Date: Thu, 27 Dec 2012 10:40:27 -0800 Subject: really facebook? In-Reply-To: <50DC9382.30908@mtcc.com> References: <50DC7FA1.6080504@mtcc.com> <50DC84A6.2090505@bogus.com> <50DC9382.30908@mtcc.com> Message-ID: <50DC961B.7000204@bogus.com> On 12/27/12 10:29 AM, mike wrote: > On 12/27/12 9:25 AM, joel jaeggli wrote: >> On 12/27/12 9:04 AM, mike wrote: >>> >>> I reloaded their app (yes, I know... sew me) and got this warning: >>> >>> IP address: 2600:100f:b119:c6bc:bd6f:fabb:ff30:2a3d >>> Estimated location: Livingston, NJ, US >> That's a rather good estimation of where many verizon wireless >> customers appear to come from. > > This can't mean that all of their v6 traffic is backhauled to NJ, right? Wireless carriers have a limited number of PDN gateways in their networks. it is entirely plausible that your packets visited new jersey. >> >>> Which seems pretty bizarre. I'm guessing they must be getting it from >>> whois or something based on the address block for Verizon. The reverse >>> map according to >>> >>> host 2600:100f:b119:c6bc:bd6f:fabb:ff30:2a3d >> one assumes they have a an geoip database like they have for ipv4 >>> >>> comes back with NXDOMAIN. I suppose the real issue here is with Vz >>> and why they don't have v6 reverse maps, but it did throw me >>> thinking that >>> somebody in New Jersey might have hacked my account. >> Well could certainly wildcard their responses, not sure that dynamic >> dns updates would be either scalable or appropiate. > > Right, brain fart on my part. Reverse map has nothing to do with a > geoip database. > It's still strange that it has no reverse map though. I wonder what > might break because > of that assumption :) > > Mike >>> >>> Mike >>> > From nanog at data102.com Thu Dec 27 18:46:36 2012 From: nanog at data102.com (randal k) Date: Thu, 27 Dec 2012 11:46:36 -0700 Subject: Netflix transit preference? In-Reply-To: <3650991A-1AF5-4089-8236-38A440C13C06@ianai.net> References: <3650991A-1AF5-4089-8236-38A440C13C06@ianai.net> Message-ID: Hey Patrick, Thanks for your prompt response. Yes, we are trying to determine where/how we receive it ... not necessarily influence it, as there isn't so much we can do there as Netflix' egress policy is theirs and theirs alone (interestingly, nobody has communities to influence Netflix' AS2906 traffic). We cannot peer directly with Netflix as their openconnect statement requires 2gbps minimum, and mentions elsewhere that the like 5+. We aren't at 2gbps yet, and we are nowhere near one of their POPs -- it is way cheaper to buy 2-3gbps of cheap transit than it is to buy 2-3gbps of transport from Denver to LA. As mentioned, my notes to peering at netflix.com have gone unanswered for the holidays (not unexpected), so I thought I'd ping the hive mind for some info in the meantime. Cheers, Randal On Thu, Dec 27, 2012 at 11:26 AM, Patrick W. Gilmore wrote: > On Dec 27, 2012, at 13:19 , randal k wrote: > > > I work at a datacenter in southern Colorado that is the upstream > bandwidth > > provider for several regional ISPs. We have been investigating our > > ever-growing bandwidth usage and have found that out of transits > > (Level3,Cogent,HE) that Netflix always seems to come in via Hurricane > > Electric. (We move ~1.4gbps to Netflix, and are thus not a candidate for > > peering. And they have no POP close.) > > Your statement about peering makes no sense. You are trying to engineer > where their traffic comes and yet you refuse to have a direct connection > which would give you full control? Weird....... > > > > I tested this by advertising a /24 across all providers, then selectively > > removed the advertisement to certain carriers to see where the bandwidth > > goes. In order, it appears that if there is a HE route, Netflix uses it, > > period. If there isn't, it prefers Level3, and Cogent comes last. > > Completely unsurprising. > > > > Since Netflix is a big hunk of our bandwidth (and obviously makes our > > customers happy), we are included to buy some more HE. However, if > Netflix > > decides that they want to randomly switch to, say, Cogent, we may be > under > > a year-long bandwidth contract that isn't particularly valuable anymore. > > > > With all of that, I am interested in finding out of any knowledge about > > Netflix transit preferences, be it inside information, anecdotal, or > > otherwise. I did email peering@ but haven't heard back, thus the public > > question. > > Why don't you ask Netflix? > > And why not ask them for kit to put on-net? < > https://signup.netflix.com/openconnect> > > -- > TTFN, > patrick > > > From patrick at ianai.net Thu Dec 27 18:54:09 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 27 Dec 2012 13:54:09 -0500 Subject: Netflix transit preference? In-Reply-To: References: <3650991A-1AF5-4089-8236-38A440C13C06@ianai.net> Message-ID: <1CCA6C18-16C5-48B2-86B6-396DF310A53A@ianai.net> On Dec 27, 2012, at 13:46 , randal k wrote: > Thanks for your prompt response. Yes, we are trying to determine where/how we receive it ... not necessarily influence it, as there isn't so much we can do there as Netflix' egress policy is theirs and theirs alone (interestingly, nobody has communities to influence Netflix' AS2906 traffic). We cannot peer directly with Netflix as their openconnect statement requires 2gbps minimum, and mentions elsewhere that the like 5+. We aren't at 2gbps yet, and we are nowhere near one of their POPs -- it is way cheaper to buy 2-3gbps of cheap transit than it is to buy 2-3gbps of transport from Denver to LA. Ah, I misunderstood. Mea Culpa. I thought you were saying since they only had 1.4 Gbps to you, you wouldn't peer with them. Silly of me. The 2 Gbps is only for PNI, but yeah, I can see how paying to get to LA or Denver may be expensive. Although once you did, you could peer with a lot more than just Netflix. On the other hand, how much is it to get to Atlanta? Looks relatively close (miles-wise, don't know fiber routes in Tennessee). Anyway, while their egress decisions are theirs (as is true of everyone), they probably will be happy to discuss with you - once the holidays are over. -- TTFN, patrick > As mentioned, my notes to peering at netflix.com have gone unanswered for the holidays (not unexpected), so I thought I'd ping the hive mind for some info in the meantime. > > Cheers, > Randal > > > On Thu, Dec 27, 2012 at 11:26 AM, Patrick W. Gilmore wrote: > On Dec 27, 2012, at 13:19 , randal k wrote: > > > I work at a datacenter in southern Colorado that is the upstream bandwidth > > provider for several regional ISPs. We have been investigating our > > ever-growing bandwidth usage and have found that out of transits > > (Level3,Cogent,HE) that Netflix always seems to come in via Hurricane > > Electric. (We move ~1.4gbps to Netflix, and are thus not a candidate for > > peering. And they have no POP close.) > > Your statement about peering makes no sense. You are trying to engineer where their traffic comes and yet you refuse to have a direct connection which would give you full control? Weird....... > > > > I tested this by advertising a /24 across all providers, then selectively > > removed the advertisement to certain carriers to see where the bandwidth > > goes. In order, it appears that if there is a HE route, Netflix uses it, > > period. If there isn't, it prefers Level3, and Cogent comes last. > > Completely unsurprising. > > > > Since Netflix is a big hunk of our bandwidth (and obviously makes our > > customers happy), we are included to buy some more HE. However, if Netflix > > decides that they want to randomly switch to, say, Cogent, we may be under > > a year-long bandwidth contract that isn't particularly valuable anymore. > > > > With all of that, I am interested in finding out of any knowledge about > > Netflix transit preferences, be it inside information, anecdotal, or > > otherwise. I did email peering@ but haven't heard back, thus the public > > question. > > Why don't you ask Netflix? > > And why not ask them for kit to put on-net? > > -- > TTFN, > patrick > > > From patrick at ianai.net Thu Dec 27 19:08:50 2012 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 27 Dec 2012 14:08:50 -0500 Subject: Netflix transit preference? In-Reply-To: <1CCA6C18-16C5-48B2-86B6-396DF310A53A@ianai.net> References: <3650991A-1AF5-4089-8236-38A440C13C06@ianai.net> <1CCA6C18-16C5-48B2-86B6-396DF310A53A@ianai.net> Message-ID: <0798CA30-D7AA-41F8-8407-607B5E91E2CF@ianai.net> More silliness was pointed out to me. I was looking at Jeff Kell's from: address and looked up UTC.edu to get your location, forgetting you mentioned Colorado in your original post. I'm going to sign off and enjoy the holidays since I clearly am not doing anyone any good here. -- TTFN, patrick On Dec 27, 2012, at 13:54 , Patrick W. Gilmore wrote: > On Dec 27, 2012, at 13:46 , randal k wrote: > >> Thanks for your prompt response. Yes, we are trying to determine where/how we receive it ... not necessarily influence it, as there isn't so much we can do there as Netflix' egress policy is theirs and theirs alone (interestingly, nobody has communities to influence Netflix' AS2906 traffic). We cannot peer directly with Netflix as their openconnect statement requires 2gbps minimum, and mentions elsewhere that the like 5+. We aren't at 2gbps yet, and we are nowhere near one of their POPs -- it is way cheaper to buy 2-3gbps of cheap transit than it is to buy 2-3gbps of transport from Denver to LA. > > Ah, I misunderstood. Mea Culpa. I thought you were saying since they only had 1.4 Gbps to you, you wouldn't peer with them. Silly of me. > > The 2 Gbps is only for PNI, but yeah, I can see how paying to get to LA or Denver may be expensive. Although once you did, you could peer with a lot more than just Netflix. On the other hand, how much is it to get to Atlanta? Looks relatively close (miles-wise, don't know fiber routes in Tennessee). > > Anyway, while their egress decisions are theirs (as is true of everyone), they probably will be happy to discuss with you - once the holidays are over. > > -- > TTFN, > patrick > > >> As mentioned, my notes to peering at netflix.com have gone unanswered for the holidays (not unexpected), so I thought I'd ping the hive mind for some info in the meantime. >> >> Cheers, >> Randal >> >> >> On Thu, Dec 27, 2012 at 11:26 AM, Patrick W. Gilmore wrote: >> On Dec 27, 2012, at 13:19 , randal k wrote: >> >>> I work at a datacenter in southern Colorado that is the upstream bandwidth >>> provider for several regional ISPs. We have been investigating our >>> ever-growing bandwidth usage and have found that out of transits >>> (Level3,Cogent,HE) that Netflix always seems to come in via Hurricane >>> Electric. (We move ~1.4gbps to Netflix, and are thus not a candidate for >>> peering. And they have no POP close.) >> >> Your statement about peering makes no sense. You are trying to engineer where their traffic comes and yet you refuse to have a direct connection which would give you full control? Weird....... >> >> >>> I tested this by advertising a /24 across all providers, then selectively >>> removed the advertisement to certain carriers to see where the bandwidth >>> goes. In order, it appears that if there is a HE route, Netflix uses it, >>> period. If there isn't, it prefers Level3, and Cogent comes last. >> >> Completely unsurprising. >> >> >>> Since Netflix is a big hunk of our bandwidth (and obviously makes our >>> customers happy), we are included to buy some more HE. However, if Netflix >>> decides that they want to randomly switch to, say, Cogent, we may be under >>> a year-long bandwidth contract that isn't particularly valuable anymore. >>> >>> With all of that, I am interested in finding out of any knowledge about >>> Netflix transit preferences, be it inside information, anecdotal, or >>> otherwise. I did email peering@ but haven't heard back, thus the public >>> question. >> >> Why don't you ask Netflix? >> >> And why not ask them for kit to put on-net? >> >> -- >> TTFN, >> patrick >> >> >> > From steve.dodd at vision.net Thu Dec 27 18:39:14 2012 From: steve.dodd at vision.net (Steve Dodd) Date: Thu, 27 Dec 2012 11:39:14 -0700 Subject: Netflix transit preference? In-Reply-To: <50DC946E.7000600@utc.edu> References: <3650991A-1AF5-4089-8236-38A440C13C06@ianai.net> <50DC946E.7000600@utc.edu> Message-ID: <2a2af40d-a436-4903-aff7-afea7b80b7d1@vision.net> Perhaps you could get some subset of RMIX to approach Netflix collectively. -Steve -----Original Message----- From: Jeff Kell [mailto:jeff-kell at utc.edu] Sent: Thursday, December 27, 2012 11:33 AM To: Patrick W. Gilmore Cc: NANOG list Subject: Re: Netflix transit preference? On 12/27/2012 1:26 PM, Patrick W. Gilmore wrote: > On Dec 27, 2012, at 13:19 , randal k wrote: > >> (We move ~1.4gbps to Netflix, and are thus not a candidate for >> peering. And they have no POP close.) > Why don't you ask Netflix? And why not ask them for kit to put on-net? > The last time we asked, their criteria was ~2.0gbps, so he doesn't have enough qualifying traffic. Has anyone looked at a Qwilt? http://www.qwilt.com/ Jeff From carlos at race.com Thu Dec 27 19:28:25 2012 From: carlos at race.com (Carlos Alcantar) Date: Thu, 27 Dec 2012 19:28:25 +0000 Subject: Netflix transit preference? In-Reply-To: Message-ID: I'M they would be more then willing to work with you on the open connect appliance, specifically if you offered to pay for the hardware which I'M sure would come in a lot cheaper then transport/transit over 12 months. Carlos Alcantar Race Communications / Race Team Member 1325 Howard Ave. #604, Burlingame, CA. 94010 Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com -----Original Message----- From: randal k Date: Thursday, December 27, 2012 10:46 AM To: "Patrick W. Gilmore" Cc: "nanog at nanog.org" Subject: Re: Netflix transit preference? Hey Patrick, Thanks for your prompt response. Yes, we are trying to determine where/how we receive it ... not necessarily influence it, as there isn't so much we can do there as Netflix' egress policy is theirs and theirs alone (interestingly, nobody has communities to influence Netflix' AS2906 traffic). We cannot peer directly with Netflix as their openconnect statement requires 2gbps minimum, and mentions elsewhere that the like 5+. We aren't at 2gbps yet, and we are nowhere near one of their POPs -- it is way cheaper to buy 2-3gbps of cheap transit than it is to buy 2-3gbps of transport from Denver to LA. As mentioned, my notes to peering at netflix.com have gone unanswered for the holidays (not unexpected), so I thought I'd ping the hive mind for some info in the meantime. Cheers, Randal On Thu, Dec 27, 2012 at 11:26 AM, Patrick W. Gilmore wrote: > On Dec 27, 2012, at 13:19 , randal k wrote: > > > I work at a datacenter in southern Colorado that is the upstream > bandwidth > > provider for several regional ISPs. We have been investigating our > > ever-growing bandwidth usage and have found that out of transits > > (Level3,Cogent,HE) that Netflix always seems to come in via Hurricane > > Electric. (We move ~1.4gbps to Netflix, and are thus not a candidate >for > > peering. And they have no POP close.) > > Your statement about peering makes no sense. You are trying to engineer > where their traffic comes and yet you refuse to have a direct connection > which would give you full control? Weird....... > > > > I tested this by advertising a /24 across all providers, then >selectively > > removed the advertisement to certain carriers to see where the >bandwidth > > goes. In order, it appears that if there is a HE route, Netflix uses >it, > > period. If there isn't, it prefers Level3, and Cogent comes last. > > Completely unsurprising. > > > > Since Netflix is a big hunk of our bandwidth (and obviously makes our > > customers happy), we are included to buy some more HE. However, if > Netflix > > decides that they want to randomly switch to, say, Cogent, we may be > under > > a year-long bandwidth contract that isn't particularly valuable >anymore. > > > > With all of that, I am interested in finding out of any knowledge about > > Netflix transit preferences, be it inside information, anecdotal, or > > otherwise. I did email peering@ but haven't heard back, thus the public > > question. > > Why don't you ask Netflix? > > And why not ask them for kit to put on-net? < > https://signup.netflix.com/openconnect> > > -- > TTFN, > patrick > > > From blake at pfankuch.me Thu Dec 27 19:47:59 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Thu, 27 Dec 2012 19:47:59 +0000 Subject: SSL Certificates and ... Providers Message-ID: Ok, so this might be a little off topic but I am trying to validate something a vendor is telling me and hoping some people here have expertise in this area... I am working with a SSL certificate provider. I am trying to purchase a quantity of wildcard SSL certificates to cover about 60 FQDN's across 4 domains. Vendor is telling me that the Wildcard certificates are licensed per physical device it is installed on. This means instead of using a single wildcard across 20 servers, I would have to buy 20 wildcard certs for 20 servers. This does not compute in my brain and also in my mind completely defeats the purpose of a wildcard cert as I know it. Has anyone run into this before? Thanks Blake From alter3d at alter3d.ca Thu Dec 27 19:52:51 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Thu, 27 Dec 2012 14:52:51 -0500 Subject: SSL Certificates and ... Providers In-Reply-To: References: Message-ID: <50DCA713.8000701@alter3d.ca> Yes, some SSL providers (mostly the overpriced ones) like to "license" their certs on a per-server basis. If you read the contract language, this is how it's written. However, this is strictly a contractual issue, not a technical one. It's just a way to squeeze more money out of people who don't know any better. Speaking strictly from a technical standpoint, there is nothing at all stopping you from using the same cert/keys on as many servers as you'd like. There are SSL providers out there that are reasonable about the whole thing and sell you a cert, not a single-device-license. - Pete On 12/27/2012 2:47 PM, Blake Pfankuch wrote: > Ok, so this might be a little off topic but I am trying to validate something a vendor is telling me and hoping some people here have expertise in this area... > > I am working with a SSL certificate provider. I am trying to purchase a quantity of wildcard SSL certificates to cover about 60 FQDN's across 4 domains. Vendor is telling me that the Wildcard certificates are licensed per physical device it is installed on. This means instead of using a single wildcard across 20 servers, I would have to buy 20 wildcard certs for 20 servers. > > This does not compute in my brain and also in my mind completely defeats the purpose of a wildcard cert as I know it. Has anyone run into this before? > > Thanks > Blake From jna at retina.net Thu Dec 27 19:53:58 2012 From: jna at retina.net (John Adams) Date: Thu, 27 Dec 2012 11:53:58 -0800 Subject: SSL Certificates and ... Providers In-Reply-To: References: Message-ID: <7F62341C-F8BD-4A89-A979-9C586D0A8EEB@retina.net> Many vendors do this and I highly recommend someone like Digicert that won't play the per-machine licensing game with you. Sent from my iPhone On Dec 27, 2012, at 11:47 AM, Blake Pfankuch wrote: > Ok, so this might be a little off topic but I am trying to validate something a vendor is telling me and hoping some people here have expertise in this area... > > I am working with a SSL certificate provider. I am trying to purchase a quantity of wildcard SSL certificates to cover about 60 FQDN's across 4 domains. Vendor is telling me that the Wildcard certificates are licensed per physical device it is installed on. This means instead of using a single wildcard across 20 servers, I would have to buy 20 wildcard certs for 20 servers. > > This does not compute in my brain and also in my mind completely defeats the purpose of a wildcard cert as I know it. Has anyone run into this before? > > Thanks > Blake From lathama at gmail.com Thu Dec 27 19:54:53 2012 From: lathama at gmail.com (Andrew Latham) Date: Thu, 27 Dec 2012 14:54:53 -0500 Subject: SSL Certificates and ... Providers In-Reply-To: References: Message-ID: On Thu, Dec 27, 2012 at 2:47 PM, Blake Pfankuch wrote: > Ok, so this might be a little off topic but I am trying to validate something a vendor is telling me and hoping some people here have expertise in this area... > > I am working with a SSL certificate provider. I am trying to purchase a quantity of wildcard SSL certificates to cover about 60 FQDN's across 4 domains. Vendor is telling me that the Wildcard certificates are licensed per physical device it is installed on. This means instead of using a single wildcard across 20 servers, I would have to buy 20 wildcard certs for 20 servers. > > This does not compute in my brain and also in my mind completely defeats the purpose of a wildcard cert as I know it. Has anyone run into this before? > > Thanks > Blake Blake Many vendors assign to a single IP address. When you send your CSR it is for one server only. Look at some of the public/free CAs to find some unbiased info. You could hide everything behind a proxy/loadbalancer if you want. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From llabas at gmail.com Thu Dec 27 19:56:50 2012 From: llabas at gmail.com (Larry LaBas) Date: Thu, 27 Dec 2012 11:56:50 -0800 Subject: SSL Certificates and ... Providers In-Reply-To: References: Message-ID: I did and it was vendor dependent which is why I switched a year and a half ago. TTFN, Larry ------------------------------------ http://www.linkedin.com/in/llabas On Dec 27, 2012, at 11:47, Blake Pfankuch wrote: > Ok, so this might be a little off topic but I am trying to validate something a vendor is telling me and hoping some people here have expertise in this area... > > I am working with a SSL certificate provider. I am trying to purchase a quantity of wildcard SSL certificates to cover about 60 FQDN's across 4 domains. Vendor is telling me that the Wildcard certificates are licensed per physical device it is installed on. This means instead of using a single wildcard across 20 servers, I would have to buy 20 wildcard certs for 20 servers. > > This does not compute in my brain and also in my mind completely defeats the purpose of a wildcard cert as I know it. Has anyone run into this before? > > Thanks > Blake From bill at herrin.us Thu Dec 27 19:58:26 2012 From: bill at herrin.us (William Herrin) Date: Thu, 27 Dec 2012 14:58:26 -0500 Subject: SSL Certificates and ... Providers In-Reply-To: References: Message-ID: On Thu, Dec 27, 2012 at 2:47 PM, Blake Pfankuch wrote: > Vendor is telling me that the Wildcard certificates are licensed > per physical device it is installed on. If you stay at a $200 hotel, you pay an extra $10 for Internet access. If you stay at a $40 motel, Internet is included. Same difference. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From blake at pfankuch.me Thu Dec 27 20:37:52 2012 From: blake at pfankuch.me (Blake Pfankuch) Date: Thu, 27 Dec 2012 20:37:52 +0000 Subject: SSL Certificates and ... Providers In-Reply-To: References: Message-ID: Thanks everyone for the quick responses. Our stuff is currently through Verisign because of the "reliability of the name" and the nature of the industry. Any suggestions for who I should look at to replace them with? I know I will be saving money, but looking to keep the name reliability as well. Thawte and GeoTrust have the same "per server" model, and looking to get away from that. Thanks! Blake -----Original Message----- From: Blake Pfankuch [mailto:blake at pfankuch.me] Sent: Thursday, December 27, 2012 12:48 PM To: NANOG (nanog at nanog.org) Subject: SSL Certificates and ... Providers Ok, so this might be a little off topic but I am trying to validate something a vendor is telling me and hoping some people here have expertise in this area... I am working with a SSL certificate provider. I am trying to purchase a quantity of wildcard SSL certificates to cover about 60 FQDN's across 4 domains. Vendor is telling me that the Wildcard certificates are licensed per physical device it is installed on. This means instead of using a single wildcard across 20 servers, I would have to buy 20 wildcard certs for 20 servers. This does not compute in my brain and also in my mind completely defeats the purpose of a wildcard cert as I know it. Has anyone run into this before? Thanks Blake From nanog at data102.com Thu Dec 27 20:42:24 2012 From: nanog at data102.com (randal k) Date: Thu, 27 Dec 2012 13:42:24 -0700 Subject: Netflix transit preference? In-Reply-To: <2a2af40d-a436-4903-aff7-afea7b80b7d1@vision.net> References: <3650991A-1AF5-4089-8236-38A440C13C06@ianai.net> <50DC946E.7000600@utc.edu> <2a2af40d-a436-4903-aff7-afea7b80b7d1@vision.net> Message-ID: Steve, Yep, we are a member of the RMIX already incidentally, and we have an email in to the maintainer, CoreSite, to see if they can talk to Netflix about perhaps setting up shop in Denver. Or even about linking the Denver exchange to the LA or NY exchanges? I'm certain that a LOT of the west would really benefit from having Netflix in Denver. We'll see! Cheers, Randal On Thu, Dec 27, 2012 at 11:39 AM, Steve Dodd wrote: > Perhaps you could get some subset of RMIX to approach Netflix collectively. > > -Steve > > -----Original Message----- > From: Jeff Kell [mailto:jeff-kell at utc.edu] > Sent: Thursday, December 27, 2012 11:33 AM > To: Patrick W. Gilmore > Cc: NANOG list > Subject: Re: Netflix transit preference? > > On 12/27/2012 1:26 PM, Patrick W. Gilmore wrote: > > On Dec 27, 2012, at 13:19 , randal k wrote: > > > >> (We move ~1.4gbps to Netflix, and are thus not a candidate for > >> peering. And they have no POP close.) > > Why don't you ask Netflix? And why not ask them for kit to put on-net? > > > > The last time we asked, their criteria was ~2.0gbps, so he doesn't have > enough qualifying traffic. > > Has anyone looked at a Qwilt? http://www.qwilt.com/ > > Jeff > > > > > From ka at pacific.net Thu Dec 27 20:53:09 2012 From: ka at pacific.net (Ken A) Date: Thu, 27 Dec 2012 14:53:09 -0600 Subject: SSL Certificates and ... Providers In-Reply-To: References: Message-ID: <50DCB535.6050807@pacific.net> I've found rapidssl wildcards are generally the cheapest (~$120), and are not limited to a number of servers. In practice, neither are the other brands. Ken On 12/27/2012 1:47 PM, Blake Pfankuch wrote: > Ok, so this might be a little off topic but I am trying to validate something a vendor is telling me and hoping some people here have expertise in this area... > > I am working with a SSL certificate provider. I am trying to purchase a quantity of wildcard SSL certificates to cover about 60 FQDN's across 4 domains. Vendor is telling me that the Wildcard certificates are licensed per physical device it is installed on. This means instead of using a single wildcard across 20 servers, I would have to buy 20 wildcard certs for 20 servers. > > This does not compute in my brain and also in my mind completely defeats the purpose of a wildcard cert as I know it. Has anyone run into this before? > > Thanks > Blake > > -- Ken Anderson From rs at seastrom.com Thu Dec 27 23:00:20 2012 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 27 Dec 2012 18:00:20 -0500 Subject: Netflix transit preference? In-Reply-To: <50DC946E.7000600@utc.edu> (Jeff Kell's message of "Thu, 27 Dec 2012 13:33:18 -0500") References: <3650991A-1AF5-4089-8236-38A440C13C06@ianai.net> <50DC946E.7000600@utc.edu> Message-ID: <86ip7nje2j.fsf@seastrom.com> Jeff Kell writes: > On 12/27/2012 1:26 PM, Patrick W. Gilmore wrote: >> On Dec 27, 2012, at 13:19 , randal k wrote: >> >>> (We move ~1.4gbps to Netflix, and are thus not a candidate for >>> peering. And they have no POP close.) >> Why don't you ask Netflix? And why not ask them for kit to put on-net? >> > > The last time we asked, their criteria was ~2.0gbps, so he doesn't have > enough qualifying traffic. > > Has anyone looked at a Qwilt? http://www.qwilt.com/ MiM-ing streaming media providers is filed under "encourage my competitors to do this". It's likely to make your phone ring. -r From mysidia at gmail.com Fri Dec 28 01:42:33 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 27 Dec 2012 19:42:33 -0600 Subject: SSL Certificates and ... Providers In-Reply-To: References: Message-ID: On 12/27/12, Blake Pfankuch wrote: It does make no sense, and I would say it is an unusual restriction, but a CA can put any certificate usage restriction they want in their policy, and technically, they have likely included a right to audit and issue out a revokation/CRL for any certificates not following their usage policy: a common example would be a SSL cert used to facilitate phishing. Make your X509 vendor take the language out of the agreement against the use on multiple servers, or buy from one of the many dozens of other certificate providers who issues wildcards and has no such special restriction on certificate usage in the certificate signing/usage policies. :) > Ok, so this might be a little off topic but I am trying to validate > something a vendor is telling me and hoping some people here have expertise > in this area... > > I am working with a SSL certificate provider. I am trying to purchase a > quantity of wildcard SSL certificates to cover about 60 FQDN's across 4 [snip] -- -JH From morrowc.lists at gmail.com Fri Dec 28 03:41:40 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 27 Dec 2012 22:41:40 -0500 Subject: SSL Certificates and ... Providers In-Reply-To: References: Message-ID: On Thu, Dec 27, 2012 at 3:37 PM, Blake Pfankuch wrote: > Our stuff is currently through Verisign because of the "reliability of the name" and the nature of the industry. verisign sold this business (like 2+ years ago?), maybe it's time to find someone else with a reliable name? (who hasn't sold the business out from under you) From shortdudey123 at gmail.com Fri Dec 28 04:07:19 2012 From: shortdudey123 at gmail.com (Grant Ridder) Date: Thu, 27 Dec 2012 22:07:19 -0600 Subject: SSL Certificates and ... Providers In-Reply-To: References: Message-ID: Yes the Verisign auth stuff is done by Symantic as of 2010. -Grant On Thursday, December 27, 2012, Christopher Morrow wrote: > On Thu, Dec 27, 2012 at 3:37 PM, Blake Pfankuch > > wrote: > > Our stuff is currently through Verisign because of the "reliability of > the name" and the nature of the industry. > > verisign sold this business (like 2+ years ago?), maybe it's time to > find someone else with a reliable name? (who hasn't sold the business > out from under you) > > From kauto at huopio.fi Fri Dec 28 08:20:30 2012 From: kauto at huopio.fi (Kauto Huopio) Date: Fri, 28 Dec 2012 10:20:30 +0200 Subject: Level3/GC: IMMEDIATE: Trace request on TCP SYN attack traffic towards 217.149.58.35 Message-ID: Greetings, (my work hat @ CERT-FI on, work email kauto.huopio at ficora.fi) Several Finnish media sites (www.yle.fi, www.mtv3.fi, www.hs.fi etc) have been attacked since Dec 25th. Current target is www.ampparit.com (217.149.58.35). ISP reports traffic originating from Level3 transit. Traffic is > 2 Mpps TCP SYN. I'd like to request immediate trace support - we suspect this is a very small source footprint DOS. All observations to cert at ficora.fi, cc: to me at work address above. -- Kauto Huopio - kauto at huopio.fi From achatz at forthnetgroup.gr Fri Dec 28 09:49:06 2012 From: achatz at forthnetgroup.gr (Tassos Chatzithomaoglou) Date: Fri, 28 Dec 2012 11:49:06 +0200 Subject: looking glass for Level 3 Message-ID: <50DD6B12.4030106@forthnetgroup.gr> Anyone have any looking glass for Level 3? The following seem not to be working http://www.level3.com/LookingGlass/ http://lg.level3.net/bgp/bgp.cgi http://lookingglass.level3.net/ -- Tassos From peterehiwe at gmail.com Fri Dec 28 10:23:38 2012 From: peterehiwe at gmail.com (Peter Ehiwe) Date: Fri, 28 Dec 2012 11:23:38 +0100 Subject: looking glass for Level 3 In-Reply-To: <50DD6B12.4030106@forthnetgroup.gr> References: <50DD6B12.4030106@forthnetgroup.gr> Message-ID: I normally use the 3rd one you mentioned but they seem to be down at the moment. Rgds Peter, Sent from my Asus Transformer Pad On Dec 28, 2012 1:51 AM, "Tassos Chatzithomaoglou" wrote: > Anyone have any looking glass for Level 3? > > The following seem not to be working > > http://www.level3.com/LookingGlass/ > http://lg.level3.net/bgp/bgp.cgi > http://lookingglass.level3.net/ > > -- > Tassos > > > From kemp at network-services.uoregon.edu Fri Dec 28 10:52:57 2012 From: kemp at network-services.uoregon.edu (John Kemp) Date: Fri, 28 Dec 2012 02:52:57 -0800 Subject: looking glass for Level 3 In-Reply-To: References: <50DD6B12.4030106@forthnetgroup.gr> Message-ID: <50DD7A09.5090401@network-services.uoregon.edu> Session is up on telnet:route-views.routeviews.org username rviews John Kemp (kemp at routeviews.org) On 12/28/2012 2:23 AM, Peter Ehiwe wrote: > I normally use the 3rd one you mentioned but they seem to be down at the > moment. > > Rgds Peter, > Sent from my Asus Transformer Pad > On Dec 28, 2012 1:51 AM, "Tassos Chatzithomaoglou" > wrote: > >> Anyone have any looking glass for Level 3? >> >> The following seem not to be working >> >> http://www.level3.com/LookingGlass/ >> http://lg.level3.net/bgp/bgp.cgi >> http://lookingglass.level3.net/ >> >> -- >> Tassos >> >> >> From job.snijders at atrato-ip.com Fri Dec 28 11:04:59 2012 From: job.snijders at atrato-ip.com (Job Snijders) Date: Fri, 28 Dec 2012 12:04:59 +0100 Subject: State of the RING 2012 Message-ID: Hi, Here is the yearly update regarding the NLNOG RING project, this year's update includes some links to tools that might be of interest to the broader community. More information about the RING can be found here: https://ring.nlnog.net/ Kind regards, Job ============================================================ State of the NLNOG RING 2012 A yearly newsletter about the best debugging project ever Edition 2, 28 Dec 2012 ============================================================ Contents ============================================================ 1. Introduction: growth 2. New services 4. Into the future! 5. Testimonials & conference exposure 6. Closing notes ============================================================ 1. Introduction: growth ============================================================ Today, 28th of december 2012, the RING turns 2 years old! The project's origins can be traced back to the following line on IRC (translated): [28 Dec 2010/10:26 CET - #NLNOG] "hey, maybe we should create a #nlnog test platform" And now here we are, 2 years later: 188 machines provided by 165 organisations in 39 countries. Compared to 2011 we have more than doubled in size! From our usage statistics we gather that 65% of organisations actively makes use of the RING through SSH. Other statistics gathered from our code repositories: - 1111 commits were made (doubled since last year!) - Most code commits happened, again, on Tuesdays - Lines of code: 20267 insertions(+), 5774 deletions(-) We could not have sustained this level of growth without the continuing support of our infrastructure sponsors and the 2012 fundraiser contributors: XS4ALL, Amazon Web Services, Leaseweb, Atrato IP Networks, Gossamer Threads, BIT, PCextreme, SoftLayer, Snijders IT, Solido Hosting, Duocast, A2B Internet, Nedzone, Tetaneutral, LCHost, Previder, Triple IT and eBay Classifieds Group. A full overview of all supporters can be found here: https://ring.nlnog.net/patrons/ ============================================================ 2. New services ============================================================ AMP (Active Measurement Project): --------------------------------- One of the biggest changes this year was moving from a distributed master/slave smokeping setup to something much better: AMP. The AMP software performs measurements from every RING node to every other RING node, and reports the results to central collectors which in turn feed a web interface. AMP as a tool offers us insight in end-to-end MTU, jitter, latency, packetloss and historic traceroutes both for IPv4 and IPv6 between all RING nodes. URL: http://amp.ring.nlnog.net/ BGP Looking glass: ------------------ Due to popular request we set up a BGP looking glass, which currently receives full IPv4 and IPv6 tables from 35+ participants. The LG uses the BIRD BGP daemon with a web interface written by one of the RING participants! We currently are exploring if we can use the collected data for a monitoring and alerting system to help participants gain insight in prefix visibility and, for instance hijack events. Stay tuned! URL: http://lg.ring.nlnog.net/ IRR/RPLS services: ------------------ Although the IRR system and RPSL have been around for a long time, there still is a lot of room for improvement in terms of performance, ease of use and standardised methods and tools. We believe that the RING community can make a difference in the popularity of proper filtering. One of the first things we offer (in beta) is a web service to expand RPSL object such as AS-SET, AUTNUM and RS-SETs and expose the data in JSON. URL: http://irr.ring.nlnog.net/ ============================================================ 3. Into the future! ============================================================ In 2013 we will continue to automate as many aspects of the RING as possible. But more importantly, the RING has to become the best swiss army knife a network engineer can imagine so we will focus on usability, more advanced tools and security. We are making a lot of progress towards publication of all kinds of RING related information in an easy accessible database, we imagine this will accelerate the development of a new generation of tools! We also started talks with other debugging projects such as RIPE Atlas to explore if cooperation and exchange of information can further such projects. As the RING is a community effort, we can only become more valuable to our members by help from the community. We need you for new creative ideas, high quality code, and of course more RING nodes. If you can help out in our efforts, don't hesitate to contact us! ============================================================ 4. Testimonials & Exposure ============================================================ Two debugging cases have been documented, where the RING proved to be of vital importance when debugging an issue at hand. Route leak: ----------- A root-cause analysis based on historic data collected by the RING. URL: https://ring.nlnog.net/news/root-cause-analysis-using-amp/ The IPv4 address that ended with .255: -------------------------------------- How the variety in RING nodes helped locate an ancient, dysfunctional ACL. URL: https://ring.nlnog.net/news/ring-success-the-ipv4-255-problem/ Conference exposure: -------------------- Various RING participants have spoken at Internet oriented conferences around the world. The following meetings made a presentation slot available to the RING: eduPERT, LINX79, MENOG11, NANOG56 and RIPE65. All of these presentations have helped the RING grow, as in the days after such a presentation we saw a spike in RING participant applications. If you want to present about the RING at a meeting in your region or local operator community, please contact us. We have great slides available for this purpose! ============================================================ 5. Closing notes ============================================================ We conclude this newsletter by saying to you, the participants, THANK YOU! Without the continued support from lots of participants the RING would not be where it is today. We are proud to be playing a small role in making the Internet an easier thing to debug and research. Again, thank you! Kind regards, Job Snijders Martin Pels Peter van Dijk Edwin Hermans ringthing From cdaniel at nurve.com.au Fri Dec 28 11:18:25 2012 From: cdaniel at nurve.com.au (Cameron Daniel) Date: Fri, 28 Dec 2012 21:18:25 +1000 Subject: looking glass for Level 3 In-Reply-To: References: <50DD6B12.4030106@forthnetgroup.gr> Message-ID: <0c9ee62f4b24abf453152acf8d5a62b8@nurve.com.au> I've had issues getting to it for a week or so. Their NOC was unresponsive when queried. On 2012-12-28 8:23 pm, Peter Ehiwe wrote: > I normally use the 3rd one you mentioned but they seem to be down at > the > moment. > > Rgds Peter, > Sent from my Asus Transformer Pad > On Dec 28, 2012 1:51 AM, "Tassos Chatzithomaoglou" > > wrote: > >> Anyone have any looking glass for Level 3? >> >> The following seem not to be working >> >> http://www.level3.com/LookingGlass/ >> http://lg.level3.net/bgp/bgp.cgi >> http://lookingglass.level3.net/ >> >> -- >> Tassos >> >> >> From nmaxpierson at gmail.com Fri Dec 28 18:06:01 2012 From: nmaxpierson at gmail.com (N. Max Pierson) Date: Fri, 28 Dec 2012 12:06:01 -0600 Subject: looking glass for Level 3 In-Reply-To: <0c9ee62f4b24abf453152acf8d5a62b8@nurve.com.au> References: <50DD6B12.4030106@forthnetgroup.gr> <0c9ee62f4b24abf453152acf8d5a62b8@nurve.com.au> Message-ID: Same here. http://lg.level3.net has been down for over a week for me. I know someone in operations I can open a ticket with. On Fri, Dec 28, 2012 at 5:18 AM, Cameron Daniel wrote: > I've had issues getting to it for a week or so. Their NOC was unresponsive > when queried. > > > On 2012-12-28 8:23 pm, Peter Ehiwe wrote: > >> I normally use the 3rd one you mentioned but they seem to be down at the >> moment. >> >> Rgds Peter, >> Sent from my Asus Transformer Pad >> On Dec 28, 2012 1:51 AM, "Tassos Chatzithomaoglou" < >> achatz at forthnetgroup.gr> >> wrote: >> >> Anyone have any looking glass for Level 3? >>> >>> The following seem not to be working >>> >>> http://www.level3.com/**LookingGlass/ >>> http://lg.level3.net/bgp/bgp.**cgi >>> http://lookingglass.level3.**net/ >>> >>> -- >>> Tassos >>> >>> >>> >>> > > From cscora at apnic.net Fri Dec 28 18:58:58 2012 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 Dec 2012 04:58:58 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201212281858.qBSIwwB0028716@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 29 Dec, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 438252 Prefixes after maximum aggregation: 181041 Deaggregation factor: 2.42 Unique aggregates announced to Internet: 215672 Total ASes present in the Internet Routing Table: 42943 Prefixes per ASN: 10.21 Origin-only ASes present in the Internet Routing Table: 33998 Origin ASes announcing only one prefix: 15900 Transit ASes present in the Internet Routing Table: 5694 Transit-only ASes present in the Internet Routing Table: 137 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 31 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 373 Unregistered ASNs in the Routing Table: 132 Number of 32-bit ASNs allocated by the RIRs: 3609 Number of 32-bit ASNs visible in the Routing Table: 3251 Prefixes from 32-bit ASNs in the Routing Table: 8795 Special use prefixes present in the Routing Table: 15 Prefixes being announced from unallocated address space: 173 Number of addresses announced to Internet: 2620507916 Equivalent to 156 /8s, 49 /16s and 199 /24s Percentage of available address space announced: 70.8 Percentage of allocated address space announced: 70.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.1 Total number of prefixes smaller than registry allocations: 154887 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 105461 Total APNIC prefixes after maximum aggregation: 32809 APNIC Deaggregation factor: 3.21 Prefixes being announced from the APNIC address blocks: 106390 Unique aggregates announced from the APNIC address blocks: 43557 APNIC Region origin ASes present in the Internet Routing Table: 4810 APNIC Prefixes per ASN: 22.12 APNIC Region origin ASes announcing only one prefix: 1248 APNIC Region transit ASes present in the Internet Routing Table: 798 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: 393 Number of APNIC addresses announced to Internet: 716761856 Equivalent to 42 /8s, 184 /16s and 235 /24s Percentage of available APNIC address space announced: 83.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: 155868 Total ARIN prefixes after maximum aggregation: 78374 ARIN Deaggregation factor: 1.99 Prefixes being announced from the ARIN address blocks: 156536 Unique aggregates announced from the ARIN address blocks: 70647 ARIN Region origin ASes present in the Internet Routing Table: 15348 ARIN Prefixes per ASN: 10.20 ARIN Region origin ASes announcing only one prefix: 5807 ARIN Region transit ASes present in the Internet Routing Table: 1591 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 25 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1089154688 Equivalent to 64 /8s, 235 /16s and 46 /24s Percentage of available ARIN address space announced: 57.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 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: 112934 Total RIPE prefixes after maximum aggregation: 58409 RIPE Deaggregation factor: 1.93 Prefixes being announced from the RIPE address blocks: 115880 Unique aggregates announced from the RIPE address blocks: 74516 RIPE Region origin ASes present in the Internet Routing Table: 17011 RIPE Prefixes per ASN: 6.81 RIPE Region origin ASes announcing only one prefix: 8152 RIPE Region transit ASes present in the Internet Routing Table: 2755 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 31 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2104 Number of RIPE addresses announced to Internet: 650459748 Equivalent to 38 /8s, 197 /16s and 58 /24s Percentage of available RIPE address space announced: 94.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 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: 45330 Total LACNIC prefixes after maximum aggregation: 9040 LACNIC Deaggregation factor: 5.01 Prefixes being announced from the LACNIC address blocks: 48936 Unique aggregates announced from the LACNIC address blocks: 23162 LACNIC Region origin ASes present in the Internet Routing Table: 1766 LACNIC Prefixes per ASN: 27.71 LACNIC Region origin ASes announcing only one prefix: 503 LACNIC Region transit ASes present in the Internet Routing Table: 338 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 731 Number of LACNIC addresses announced to Internet: 120924712 Equivalent to 7 /8s, 53 /16s and 42 /24s Percentage of available LACNIC address space announced: 72.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 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: 9744 Total AfriNIC prefixes after maximum aggregation: 2356 AfriNIC Deaggregation factor: 4.14 Prefixes being announced from the AfriNIC address blocks: 10337 Unique aggregates announced from the AfriNIC address blocks: 3636 AfriNIC Region origin ASes present in the Internet Routing Table: 589 AfriNIC Prefixes per ASN: 17.55 AfriNIC Region origin ASes announcing only one prefix: 190 AfriNIC Region transit ASes present in the Internet Routing Table: 130 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: 42905088 Equivalent to 2 /8s, 142 /16s and 174 /24s Percentage of available AfriNIC address space announced: 42.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2946 11556 914 Korea Telecom (KIX) 17974 2485 829 54 PT TELEKOMUNIKASI INDONESIA 7545 1815 301 88 TPG Internet Pty Ltd 4755 1658 381 174 TATA Communications formerly 9829 1416 1156 42 BSNL National Internet Backbo 9583 1183 88 501 Sify Limited 7552 1147 1070 12 Vietel Corporation 4808 1123 2040 316 CNCGROUP IP network: China169 9498 1051 309 74 BHARTI Airtel Ltd. 24560 1037 385 161 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 7029 3468 1010 215 Windstream Communications Inc 6389 3118 3717 132 bellsouth.net, inc. 18566 2081 382 180 Covad Communications 22773 1947 2932 131 Cox Communications, Inc. 1785 1941 678 124 PaeTec Communications, Inc. 20115 1688 1603 618 Charter Communications 4323 1597 1155 397 Time Warner Telecom 30036 1356 287 705 Mediacom Communications Corp 7018 1294 10534 854 AT&T WorldNet Services 7011 1206 321 685 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1731 544 16 Corbina telecom 2118 1052 97 15 EUnet/RELCOM Autonomous Syste 34984 895 211 232 BILISIM TELEKOM 12479 869 777 64 Uni2 Autonomous System 13188 768 96 115 Educational Network 31148 743 38 15 FreeNet ISP 20940 734 241 571 Akamai Technologies European 6830 714 2313 435 UPC Distribution Services 8551 637 367 39 Bezeq International 58113 633 70 378 LIR DATACENTER TELECOM 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 10620 2270 387 207 TVCABLE BOGOTA 28573 2252 1299 70 NET Servicos de Comunicao S.A 7303 1674 1139 202 Telecom Argentina Stet-France 8151 1547 2936 352 UniNet S.A. de C.V. 6503 1454 435 67 AVANTEL, S.A. 27947 745 86 89 Telconet S.A 18881 740 716 18 Global Village Telecom 3816 672 309 71 Empresa Nacional de Telecomun 11172 601 86 66 Servicios Alestra S.A de C.V 7738 588 1242 34 Telecomunicacoes da Bahia 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 24863 872 275 36 LINKdotNET AS number 36998 749 48 3 MOBITEL 8452 549 958 13 TEDATA 6713 499 602 20 Itissalat Al-MAGHRIB 24835 291 80 8 RAYA Telecom - Egypt 3741 267 906 225 The Internet Solution 12258 193 28 67 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 181 697 88 MTN Network Solutions 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 7029 3468 1010 215 Windstream Communications Inc 6389 3118 3717 132 bellsouth.net, inc. 4766 2946 11556 914 Korea Telecom (KIX) 17974 2485 829 54 PT TELEKOMUNIKASI INDONESIA 10620 2270 387 207 TVCABLE BOGOTA 28573 2252 1299 70 NET Servicos de Comunicao S.A 18566 2081 382 180 Covad Communications 22773 1947 2932 131 Cox Communications, Inc. 1785 1941 678 124 PaeTec Communications, Inc. 7545 1815 301 88 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 3118 2986 bellsouth.net, inc. 17974 2485 2431 PT TELEKOMUNIKASI INDONESIA 28573 2252 2182 NET Servicos de Comunicao S.A 10620 2270 2063 TVCABLE BOGOTA 4766 2946 2032 Korea Telecom (KIX) 18566 2081 1901 Covad Communications 1785 1941 1817 PaeTec Communications, Inc. 22773 1947 1816 Cox Communications, Inc. 7545 1815 1727 TPG Internet Pty Ltd 8402 1731 1715 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 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.24.0/21 41794 Altline LLC 128.0.64.0/22 49466 Declic Telecom SAS 128.0.68.0/22 49466 Declic Telecom SAS 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition 128.0.128.0/20 29285 AMT closed joint-stock compan 128.0.144.0/22 59675 mywire Datentechnik GmbH Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.112.114.0/24 23884 Proimage Engineering and Comm 41.222.80.0/21 37110 Moztel LDA 41.223.108.0/22 36966 >>UNKNOWN<< 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.66.32.0/20 18864 >>UNKNOWN<< 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. 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:18 /9:13 /10:29 /11:87 /12:244 /13:477 /14:858 /15:1545 /16:12489 /17:6566 /18:10939 /19:21633 /20:31043 /21:33016 /22:44333 /23:40798 /24:230036 /25:1304 /26:1682 /27:869 /28:172 /29:69 /30:13 /31:0 /32:19 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 7029 2729 3468 Windstream Communications Inc 18566 2031 2081 Covad Communications 6389 1773 3118 bellsouth.net, inc. 8402 1455 1731 Corbina telecom 22773 1279 1947 Cox Communications, Inc. 30036 1261 1356 Mediacom Communications Corp 11492 1157 1194 Cable One 1785 1023 1941 PaeTec Communications, Inc. 6503 980 1454 AVANTEL, S.A. 7011 954 1206 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:704 2:692 3:3 4:9 5:701 6:3 8:470 12:1929 13:3 14:701 15:11 16:3 17:6 20:27 23:221 24:1786 27:1467 31:1349 32:54 33:2 34:2 36:11 37:1145 38:841 39:2 40:141 41:2658 42:180 44:3 46:1726 47:3 49:527 50:656 52:12 54:28 55:8 56:1 57:28 58:1071 59:559 60:237 61:1317 62:1039 63:2015 64:4348 65:2200 66:4492 67:2086 68:1199 69:3330 70:940 71:557 72:1893 74:2622 75:475 76:293 77:1052 78:1030 79:524 80:1221 81:982 82:661 83:537 84:529 85:1164 86:457 87:970 88:362 89:1757 90:304 91:5381 92:613 93:1621 94:1988 95:1630 96:489 97:337 98:967 99:40 100:31 101:286 103:1974 105:501 106:117 107:203 108:510 109:1753 110:834 111:983 112:470 113:745 114:642 115:905 116:888 117:775 118:962 119:1265 120:372 121:707 122:1727 123:1182 124:1320 125:1299 128:811 129:199 130:307 131:643 132:319 133:142 134:254 135:62 136:216 137:235 138:344 139:169 140:182 141:300 142:516 143:351 144:490 145:89 146:518 147:327 148:728 149:335 150:158 151:245 152:399 153:188 154:23 155:424 156:231 157:379 158:257 159:681 160:335 161:421 162:371 163:193 164:584 165:458 166:471 167:569 168:1006 169:131 170:988 171:164 172:4 173:1641 174:631 175:466 176:947 177:1479 178:1713 180:1364 181:183 182:1147 183:287 184:650 185:147 186:2157 187:1449 188:1903 189:1566 190:6187 192:6082 193:5720 194:4485 195:3602 196:1244 197:289 198:4012 199:5159 200:6032 201:2027 202:8859 203:8751 204:4479 205:2543 206:2810 207:2808 208:4064 209:3648 210:2911 211:1559 212:2006 213:1883 214:859 215:91 216:5135 217:1571 218:596 219:321 220:1260 221:544 222:324 223:375 End of report From cidr-report at potaroo.net Fri Dec 28 22:00:00 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Dec 2012 22:00:00 GMT Subject: The Cidr Report Message-ID: <201212282200.qBSM00bS087765@wattle.apnic.net> This report has been generated at Fri Dec 28 21:13:08 2012 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 21-12-12 440351 252593 22-12-12 440781 252719 23-12-12 440763 252676 24-12-12 440659 252626 25-12-12 440728 252757 26-12-12 440799 252807 27-12-12 440865 252753 28-12-12 440905 252699 AS Summary 43060 Number of ASes in routing system 17939 Number of ASes announcing only one prefix 3467 Largest number of prefixes announced by an AS AS7029 : WINDSTREAM - Windstream Communications Inc 115553760 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'). --- 28Dec12 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 440989 252735 188254 42.7% All ASes AS6389 3118 136 2982 95.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2263 71 2192 96.9% NET Servicos de Comunicao S.A. AS17974 2485 448 2037 82.0% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2946 931 2015 68.4% KIXS-AS-KR Korea Telecom AS7029 3467 1609 1858 53.6% WINDSTREAM - Windstream Communications Inc AS22773 1948 183 1765 90.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2081 423 1658 79.7% COVAD - Covad Communications Co. AS10620 2270 652 1618 71.3% Telmex Colombia S.A. AS7303 1674 397 1277 76.3% Telecom Argentina S.A. AS4323 1602 403 1199 74.8% TWTC - tw telecom holdings, inc. AS4755 1657 552 1105 66.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1052 53 999 95.0% RELCOM-AS OOO "NPO Relcom" AS7552 1147 163 984 85.8% VIETEL-AS-AP Vietel Corporation AS7545 1821 950 871 47.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS8151 1552 700 852 54.9% Uninet S.A. de C.V. AS18101 1016 170 846 83.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS1785 1940 1156 784 40.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1124 352 772 68.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS13977 852 118 734 86.2% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS18881 740 35 705 95.3% Global Village Telecom AS855 717 54 663 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS9808 682 32 650 95.3% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS17676 712 92 620 87.1% GIGAINFRA Softbank BB Corp. AS3356 1116 504 612 54.8% LEVEL3 Level 3 Communications AS3549 1038 439 599 57.7% GBLX Global Crossing Ltd. AS22561 1040 443 597 57.4% DIGITAL-TELEPORT - Digital Teleport Inc. AS19262 999 404 595 59.6% VZGNI-TRANSIT - Verizon Online LLC AS24560 1031 444 587 56.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22047 579 22 557 96.2% VTR BANDA ANCHA S.A. AS4804 633 96 537 84.8% MPX-AS Microplex PTY LTD Total 45302 12032 33270 73.4% 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- 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 41.222.80.0/21 AS37110 moztel-as 41.223.108.0/22 AS36966 EDL_AS Edgenet AS 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.66.32.0/20 AS18864 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 64.187.209.0/24 AS23005 SWITCH-COMMUNICATIONS - SWITCH Communications Group LLC 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 68.234.0.0/19 AS40430 COLO4JAX-AS - colo4jax, LLC 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 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 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.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.217.250.0/24 AS43108 GARM-AS Garm Technologies Ltd. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.244.245.0/24 AS13176 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 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.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 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.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 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.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 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 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 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 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.87.96.0/21 AS40638 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. 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.160.0/20 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 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 Dec 28 22:00:02 2012 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 Dec 2012 22:00:02 GMT Subject: BGP Update Report Message-ID: <201212282200.qBSM02Ph087779@wattle.apnic.net> BGP Update Report Interval: 20-Dec-12 -to- 27-Dec-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8402 36701 2.6% 55.5 -- CORBINA-AS OJSC "Vimpelcom" 2 - AS3909 36562 2.6% 4570.2 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - AS9829 29062 2.1% 34.3 -- BSNL-NIB National Internet Backbone 4 - AS29256 24976 1.8% 1085.9 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 5 - AS701 22541 1.6% 727.1 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 6 - AS4198 16386 1.2% 1365.5 -- RADIXNET - RadixNet, Inc. 7 - AS1637 16301 1.2% 494.0 -- DNIC-AS-01637 - Headquarters, USAISC 8 - AS7552 14557 1.1% 15.4 -- VIETEL-AS-AP Vietel Corporation 9 - AS4538 10240 0.7% 22.5 -- ERX-CERNET-BKB China Education and Research Network Center 10 - AS9198 8248 0.6% 24.0 -- KAZTELECOM-AS JSC Kazakhtelecom 11 - AS29614 7576 0.6% 315.7 -- GHANATEL-AS 12 - AS45271 7556 0.6% 34.0 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road 13 - AS7029 7548 0.5% 6.9 -- WINDSTREAM - Windstream Communications Inc 14 - AS38142 7288 0.5% 455.5 -- UNAIR-AS-ID Universitas Airlangga 15 - AS48159 7270 0.5% 22.9 -- TIC-AS Telecommunication Infrastructure Company 16 - AS50710 6912 0.5% 47.0 -- EARTHLINK-AS EarthLink Ltd. Communications&Internet Services 17 - AS2033 6551 0.5% 6551.0 -- PANIX - Panix Network Information Center 18 - AS24057 6313 0.5% 6313.0 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 19 - AS9756 6046 0.4% 403.1 -- CHEONANVITSSEN-AS-KR Cheonan Broadcast Corporation 20 - AS2708 6000 0.4% 85.7 -- Universidad de Guanajuato TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS2033 6551 0.5% 6551.0 -- PANIX - Panix Network Information Center 2 - AS24057 6313 0.5% 6313.0 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 3 - AS37430 4818 0.3% 4818.0 -- vdctelecom 4 - AS3909 36562 2.6% 4570.2 -- QWEST-AS-3908 - Qwest Communications Company, LLC 5 - AS19406 4202 0.3% 4202.0 -- TWRS-MA - Towerstream I, Inc. 6 - AS9950 4150 0.3% 4150.0 -- PUBNETPLUS2-AS-KR DACOM 7 - AS42705 4120 0.3% 4120.0 -- TALIA Talia provides VSAT network and hosting services worldwide. 8 - AS33158 4022 0.3% 4022.0 -- DATA-SERVICES-INC - Data Services Incorporated 9 - AS57918 3437 0.2% 3437.0 -- ACOD-AS ACOD CJSC 10 - AS6174 5644 0.4% 2822.0 -- SPRINTLINK8 - Sprint 11 - AS6629 2494 0.2% 2494.0 -- NOAA-AS - NOAA 12 - AS6197 2349 0.2% 2349.0 -- BATI-ATL - BellSouth Network Solutions, Inc 13 - AS25527 1993 0.1% 1993.0 -- CARTELSISTEM-AS Cartel-Sistem SRL, Moldova, Chisinau 14 - AS17293 3852 0.3% 1926.0 -- VTXC - VTX Communications 15 - AS40931 1695 0.1% 1695.0 -- MOBITV - MobiTV, Inc 16 - AS14680 4951 0.4% 1650.3 -- REALE-6 - Auction.com 17 - AS4198 16386 1.2% 1365.5 -- RADIXNET - RadixNet, Inc. 18 - AS4826 1298 0.1% 1298.0 -- VOCUS-BACKBONE-AS Vocus Connect International Backbone 19 - AS36529 2496 0.2% 1248.0 -- AXXA-RACKCO - Rackco.com 20 - AS29256 24976 1.8% 1085.9 -- INT-PDN-STE-AS Syrian Telecommunications Establishment TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 151.118.255.0/24 12165 0.8% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - 151.118.254.0/24 12165 0.8% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.18.0/24 12146 0.8% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 209.48.168.0/24 6551 0.4% AS2033 -- PANIX - Panix Network Information Center 5 - 202.14.255.0/24 6313 0.4% AS24057 -- AIGL-AS-AP PT. AIA FINANCIAL, Insurance company, Indonesia 6 - 41.77.184.0/22 4818 0.3% AS37430 -- vdctelecom 7 - 194.63.9.0/24 4477 0.3% AS1273 -- CW Cable and Wireless Worldwide plc 8 - 69.38.178.0/24 4202 0.3% AS19406 -- TWRS-MA - Towerstream I, Inc. 9 - 12.139.133.0/24 4175 0.3% AS14680 -- REALE-6 - Auction.com 10 - 58.184.229.0/24 4150 0.3% AS9950 -- PUBNETPLUS2-AS-KR DACOM 11 - 80.251.10.0/24 4120 0.3% AS42705 -- TALIA Talia provides VSAT network and hosting services worldwide. 12 - 12.183.21.0/24 4022 0.3% AS33158 -- DATA-SERVICES-INC - Data Services Incorporated 13 - 91.236.24.0/24 3437 0.2% AS57918 -- ACOD-AS ACOD CJSC 14 - 115.170.128.0/17 2890 0.2% AS4847 -- CNIX-AP China Networks Inter-Exchange 15 - 208.16.110.0/24 2825 0.2% AS6174 -- SPRINTLINK8 - Sprint 16 - 206.105.75.0/24 2819 0.2% AS6174 -- SPRINTLINK8 - Sprint 17 - 205.156.28.0/24 2507 0.2% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 18 - 205.156.27.0/24 2503 0.2% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 19 - 198.206.32.0/20 2503 0.2% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 20 - 198.206.48.0/21 2499 0.2% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 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 dave at temk.in Sat Dec 29 10:11:47 2012 From: dave at temk.in (David Temkin) Date: Sat, 29 Dec 2012 05:11:47 -0500 Subject: Netflix transit preference? In-Reply-To: <86ip7nje2j.fsf@seastrom.com> References: <3650991A-1AF5-4089-8236-38A440C13C06@ianai.net> <50DC946E.7000600@utc.edu> <86ip7nje2j.fsf@seastrom.com> Message-ID: Hi all, We (Netflix) reached out to Randal off-list to explain how our transit/peering methodology works. Feel free to reach out to peering at netflix.com for questions like this in the future. -Dave On Thu, Dec 27, 2012 at 6:00 PM, Robert E. Seastrom wrote: > > Jeff Kell writes: > > > On 12/27/2012 1:26 PM, Patrick W. Gilmore wrote: > >> On Dec 27, 2012, at 13:19 , randal k wrote: > >> > >>> (We move ~1.4gbps to Netflix, and are thus not a candidate for > >>> peering. And they have no POP close.) > >> Why don't you ask Netflix? And why not ask them for kit to put on-net? > >> > > > > The last time we asked, their criteria was ~2.0gbps, so he doesn't have > > enough qualifying traffic. > > > > Has anyone looked at a Qwilt? http://www.qwilt.com/ > > MiM-ing streaming media providers is filed under "encourage my > competitors to do this". It's likely to make your phone ring. > > -r > > > > From apishdadi at gmail.com Sat Dec 29 10:17:25 2012 From: apishdadi at gmail.com (A. Pishdadi) Date: Sat, 29 Dec 2012 04:17:25 -0600 Subject: Netflix transit preference? In-Reply-To: References: Message-ID: Hurricane electric has a very open peering policy , can peer with them at any major Equinix with pretty much no push or pull requirements , which is why Netflix prefers them cause it costs them almost nothing , why pay hurricane for transit when most of there connectivity can be accessed by peer routes pretty much for free through Equinix exchange or any2... On Thursday, December 27, 2012, randal k wrote: > Hey NANOG! > I work at a datacenter in southern Colorado that is the upstream bandwidth > provider for several regional ISPs. We have been investigating our > ever-growing bandwidth usage and have found that out of transits > (Level3,Cogent,HE) that Netflix always seems to come in via Hurricane > Electric. (We move ~1.4gbps to Netflix, and are thus not a candidate for > peering. And they have no POP close.) > > I tested this by advertising a /24 across all providers, then selectively > removed the advertisement to certain carriers to see where the bandwidth > goes. In order, it appears that if there is a HE route, Netflix uses it, > period. If there isn't, it prefers Level3, and Cogent comes last. > > Since Netflix is a big hunk of our bandwidth (and obviously makes our > customers happy), we are included to buy some more HE. However, if Netflix > decides that they want to randomly switch to, say, Cogent, we may be under > a year-long bandwidth contract that isn't particularly valuable anymore. > > With all of that, I am interested in finding out of any knowledge about > Netflix transit preferences, be it inside information, anecdotal, or > otherwise. I did email peering@ but haven't heard back, thus the public > question. > > Thanks! > Randal > From paul4004 at gmail.com Sat Dec 29 15:25:36 2012 From: paul4004 at gmail.com (PC) Date: Sat, 29 Dec 2012 08:25:36 -0700 Subject: really facebook? In-Reply-To: <50DC961B.7000204@bogus.com> References: <50DC7FA1.6080504@mtcc.com> <50DC84A6.2090505@bogus.com> <50DC9382.30908@mtcc.com> <50DC961B.7000204@bogus.com> Message-ID: Very common. Most Verizon Wireless data traffic on modern phones is backhauled to one or more mobile IP home agents based in a few cities. You'll typically see similar geolocation difficulties on their network for IPv4 too. They have another one in Texas, and another one in a different location I can't remember. This behavior plus related IP assignment practices has resulted in ineffective geolocation, often even on a regional level. Many mobile phone apps use more than just IP for geolocation though, which is much more effective. It's also worth noting that IPV6 geolocation support is quite primitive at this moment, but in this particular case its not what the problem is. On Thu, Dec 27, 2012 at 11:40 AM, joel jaeggli wrote: > On 12/27/12 10:29 AM, mike wrote: > >> On 12/27/12 9:25 AM, joel jaeggli wrote: >> >>> On 12/27/12 9:04 AM, mike wrote: >>> >>>> >>>> I reloaded their app (yes, I know... sew me) and got this warning: >>>> >>>> IP address: 2600:100f:b119:c6bc:bd6f:fabb:**ff30:2a3d >>>> Estimated location: Livingston, NJ, US >>>> >>> That's a rather good estimation of where many verizon wireless customers >>> appear to come from. >>> >> >> This can't mean that all of their v6 traffic is backhauled to NJ, right? >> > Wireless carriers have a limited number of PDN gateways in their networks. > it is entirely plausible that your packets visited new jersey. > > >>> Which seems pretty bizarre. I'm guessing they must be getting it from >>>> whois or something based on the address block for Verizon. The reverse >>>> map according to >>>> >>>> host 2600:100f:b119:c6bc:bd6f:fabb:**ff30:2a3d >>>> >>> one assumes they have a an geoip database like they have for ipv4 >>> >>>> >>>> comes back with NXDOMAIN. I suppose the real issue here is with Vz >>>> and why they don't have v6 reverse maps, but it did throw me thinking >>>> that >>>> somebody in New Jersey might have hacked my account. >>>> >>> Well could certainly wildcard their responses, not sure that dynamic dns >>> updates would be either scalable or appropiate. >>> >> >> Right, brain fart on my part. Reverse map has nothing to do with a geoip >> database. >> It's still strange that it has no reverse map though. I wonder what might >> break because >> of that assumption :) >> >> Mike >> >>> >>>> Mike >>>> >>>> >> > > From alter3d at alter3d.ca Sun Dec 30 02:41:35 2012 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Sat, 29 Dec 2012 21:41:35 -0500 Subject: Gmail and SSL In-Reply-To: <13C7AEC5-5A6F-448D-AE62-87DE2244BEEA@syminet.com> References: <50CB49F7.5050304@afxr.net> <50CB4B43.10803@alter3d.ca> <13C7AEC5-5A6F-448D-AE62-87DE2244BEEA@syminet.com> Message-ID: <50DFA9DF.7000806@alter3d.ca> On 12/29/2012 7:41 PM, Mark - Syminet wrote: > On Dec 14, 2012, at 7:52 AM, Peter Kristolaitis wrote: > >> On 12/14/2012 10:47 AM, Randy wrote: >>> I don't have hundreds of dollars to get my ssl certificates signed >> You can get single-host certificates issued for free from StartSSL, or for very cheaply (under $10) from low-cost providers like CheapSSL.com. I've never had a problem having my StartSSL certs verified by anyone. >> > > So I guess the question really, is this: > > Is it bad, therefore - to *force* every holder of a self-signed certificate - to transmit in the clear? > There are plenty of good reasons for self-signed certs -- people stuck running a Microsoft environment might find it might difficult without it, since it's a fundamental feature of Active Directory. ;) Various F/OSS projects, like OpenVPN, generally recommend self-signed certs as a standard deployment scenario, because it actually provides an extra layer of security -- as the CA, you determine who gets a cert and who doesn't. The difficulty you'll run into is defining "self-signed". If you generate your own CA and put the certs in your /etc/ssl directory, it's still "self-signed" (as in you're the one signing the end-use certs), the only difference is that your browser, etc, won't pop up a warning because it's now "trusted". It's also important to not conflate "encryption" with "chain of trust validation". There are good reasons to encrypt without really caring who you're talking to. There are also good reasons to not necessarily trust an arbitrary list of CAs as provided by your SSL stack vendor and provide your own list, as mentioned above. Two entirely separate issues, IMHO. - Pete From mysidia at gmail.com Sun Dec 30 05:08:41 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 29 Dec 2012 23:08:41 -0600 Subject: Gmail and SSL In-Reply-To: <50CB49F7.5050304@afxr.net> References: <50CB49F7.5050304@afxr.net> Message-ID: On 12/14/12, Randy wrote: [snip] > It explained that google is no longer accepting self signed ssl > certificates. It claims that this change will "offer[s] a higher level of security to better protect your information". Hm... Self-signed certificates, or (worse) the use of hostnames not on the certificate, are very common with POP/SMTP/IMAP over SSL/TLS servers; when setting up POP software, it is common that the user of an e-mail service will have instructions to check and install the certificate in the e-mail client, instead of requiring a unique IP address for every POP server mail domain, and a user purchased SSL certificate for each IP. The "major CAs" are not an authoritative list of CAs that may be used to sign POP, IMAP, or SMTP server certificates for various POP servers' on the internet; so Google's choices would seem poorly conceived in that regard. If Google should wish to enforce a validation of SSL certificates, the PKI authority required, should be specified by the user, not Google, or there should be a provision to accept any certificate whatsoever, by fingerprint, for a specific hostname; defined by the user. Google should go back to definitions. What is security: security is the assurance that the Confidentiality, Integrity, and Availability of data and systems are protected. How does this change apparently impact the assurances against risk? Availability: This change breaks availability, for users accessing servers already using self-signed certificates. (In other words, the change itself is a compromise of security; the risk that you lose availability of access to your mail that you expect to be downloaded via POP3 is 100%, if you have a self-signed cert in place) Confidentiality: The change prevents any transfer of data at all, unless the user of a self-signed certificate makes one of three changes: (1) Stop using gmail POP download altogether, in this case, confidentiality assurance may be improved, because no email can be downloaded and used with the service. In general, this may not be much of an improvement, when email has already been transmitted in cleartext, before it was placed on the remote POP server. (That might be their intended result -- discourage use of POP downloads) (2) Stop using SSL, and use regular POP3 instead. In this case, confidentiality will be no better than before, and may be significantly worse. A new risk of breach by 'passive sniffing' is created. When using SSL with a self-signed certificate; passive sniffing, or Deep packet inspection was not a risk: an active attack was a requirement. Therefore, being forced to "never use SSL", even without a CA signed cert, is not an improvement, and a potential increase in risk. (3) Users may buy an official certificate, from a 3rd party CA that Google trusts. In this case, the SSL encrypted POP3 connections from Google to the POP server, will have strong protection against possible exposure of data in transit due to active Man-in-the-middle attack. * In other words: If you deem Man-in-the-Middle attack more likely than Passive sniffing exposure attacks to discover users' passwords, and the majority of users' POP servers likely to have or get certificates from a CA that Google trusts, then forced rejection of any other certificates may be an improvement in assurance against these risks; forcing the remaining users to not use SSL, and risk their password being exposed is OK, because you deemed MITM the greater risk. If you do not make that assumption, then it is not clear at all, whether assurance of confidentiality has been improved or not; it may be improved slightly for some users, and terribly harmed for many others. Integrity: The change prevents any transfer of data at all, unless the user of a self-signed certificate makes one of three changes: (1) Stop using POP download altogether, in this case, data cannot be altered by an unauthorized user as it transits the network, data that wasn't downloaded couldn't have been tampered with. (2) Stop using SSL, and use regular POP3 instead. In this case, a new risk of "transparent inline tampering" is created, without encryption, a full blown MITM attack is not required, a passive interceptor can flip random bits, as long as they update the corresponding IP checksums; so there are new significant risks to integrity. (3) Users may buy an official certificate; in this case, the risk of interception by inline Man-in-the-middle attack is reduced. > I don't believe that this change offers better security. In fact it is > now unsecured - I am unable to use ssl with gmail, I have had to select > the plain-text pop3 option. > I don't have hundreds of dollars to get my ssl certificates signed, and > to top it off, gmail never notified me of an error with fetching my -- -JH From kmedcalf at dessus.com Sun Dec 30 20:30:03 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 30 Dec 2012 13:30:03 -0700 Subject: Gmail and SSL Message-ID: Your assertion that using "bought" certificates provides any security benefit whatsoever assumes facts not in evidence. Given recent failures in this space I would posit that the requirement to use certificates purchased from entities "under the thumb" of government control, clearly motivated only by profit, and with highly questionable moral and ethical standards represents a huge increase in risk of passive attack and confidentiality failure where such rosk did not previously exist. Sent from Samsung Mobile -------- Original message -------- From: Jimmy Hess Date: To: Randy Cc: NANOG list Subject: Re: Gmail and SSL From morrowc.lists at gmail.com Sun Dec 30 20:34:19 2012 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 30 Dec 2012 15:34:19 -0500 Subject: Gmail and SSL In-Reply-To: References: Message-ID: On Sun, Dec 30, 2012 at 3:30 PM, Keith Medcalf wrote: > Your assertion that using "bought" certificates provides any security benefit whatsoever assumes facts not in evidence. > > Given recent failures in this space I would posit that the requirement to use certificates purchased from entities "under the thumb" of government control, clearly motivated only by profit, and with highly questionable moral and ethical standards represents a huge increase in risk of passive attack and confidentiality failure where such rosk did not previously exist. > backing up some, I think the problem trying to be solved by requiring 'legitimate' certificates is stopping the obvious problems of mitm attacks, ala mallory-proxy. in the longer term, if the client can know that the server was supposed to present a cert with fingerprint XFOOBYFOOB and it can see that fingerprint for the cert presented in the session we all win, right? From kmedcalf at dessus.com Sun Dec 30 22:27:35 2012 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 30 Dec 2012 15:27:35 -0700 Subject: Gmail and SSL Message-ID: While i will agree that the client being able to validate the certificate directly is the best place to be, I do not see any advantage of requiring purchased certificates over self-signed certificates. ?IMO it provides no realistic security benefit at all. Then again I don't award points for? certificate verification having anything to do with identity verification of the remote party. In other words, if I didn't sign it then the certificate posseses no more validity than an ephemeral self-signed certificate. Of course, others are free to delude ?themselves with additional "theatrics" and false assumtions if they want to do so. Sent from Samsung Mobile -------- Original message -------- From: Christopher Morrow Date: To: kmedcalf Cc: mysidia at gmail.com,nanog at nanog.org Subject: Re: Gmail and SSL From mysidia at gmail.com Mon Dec 31 01:25:04 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 30 Dec 2012 19:25:04 -0600 Subject: Gmail and SSL In-Reply-To: References: Message-ID: On 12/30/12, Keith Medcalf wrote: > Your assertion that using "bought" certificates provides any security > benefit whatsoever assumes facts not in evidence. I would say those claiming certificates from a public CA provide no assurance of authentication of server identity greater than that of a self-signed one would have the burden of proof to show that it is no less likely for an attempted forger to be able to obtain a false "bought" certificate from a public trusted CA that has audited certification practices statement, a certificate improperly issued contrary to their CPS, than to have created a self-issued false self-signed certificate. It is certainly contrary to some basis on which web browser implementations of HTTPS and TLS in practice rely upon. While there have been failure in that area, regarding some particular CAs, and some particular certificates, the reported occurrences of this were sufficiently rare, that one doubts "obtaining an improperly issued certificate from a widely trusted CA" is an easy feat for the most likely attackers to accomplish. So I would be very interested in any data you had to show that a CA signature provides no additional assurance; Especially, when combined with a policy of requiring manual human verification of the certificate fingerprint, and manual human agreement that the CA's CPS is strict enough for this certificate usage, after all the automatic checks that it was properly signed by a well-known CA with an audited CPS statement, with the usage of the certificate key matching an allowed usage declared by the Type/EKU/CA attributes of the subject and issuer certs. -- -JH From johnl at iecc.com Mon Dec 31 03:46:45 2012 From: johnl at iecc.com (John Levine) Date: 31 Dec 2012 03:46:45 -0000 Subject: Gmail and SSL In-Reply-To: Message-ID: <20121231034645.11439.qmail@joyce.lan> >I would say those claiming certificates from a public CA provide no >assurance of authentication of server identity greater than that of a >self-signed one would have the burden of proof to show that it is no >less likely for an attempted forger to be able to obtain a false >"bought" certificate from a public trusted CA that has audited >certification practices statement, a certificate improperly issued >contrary to their CPS, than to have created a self-issued false >self-signed certificate. Do you ever buy SSL certificates? For cheap certificates ($9 Geotrust, $8 Comodo, free Startcom, all accepted by Gmail), the entirety of the identity validation is to send an email message to an address associated with the domain, typically one of the WHOIS addresses, or hostmaster at domain, and look for a click on an embedded URL. Sometimes they flag names that look particularly funky, such as typos of famous names, but usually they don't. So the only assurance a signed cert provides is that the person who got the cert has some authority over a name that points to the mail client, which need have no connection to any email address used in mail sent from that server. That doesn't sound like "authentication of server identity" to me. R's, John From mysidia at gmail.com Mon Dec 31 04:26:36 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 30 Dec 2012 22:26:36 -0600 Subject: Gmail and SSL In-Reply-To: <20121231034645.11439.qmail@joyce.lan> References: <20121231034645.11439.qmail@joyce.lan> Message-ID: On 12/30/12, John Levine wrote: > Do you ever buy SSL certificates? For cheap certificates ($9 > Geotrust, $8 Comodo, free Startcom, all accepted by Gmail), the > entirety of the identity validation is to send an email message to an > address associated with the domain, typically one of the WHOIS > addresses, or hostmaster at domain, and look for a click on an embedded These CA's will normally require interactions be done through a web site, there will often be captchas or other methods involved in applying for a certificate that are difficult to automate. They require payment, which requires a credit card, and obtaining a massive number of certificates is not a practical thing for malware to perform, unless they also possess a mass amount of stolen credit cards, and stolen WHOIS e-mail address contacts; on the other hand, self-signed certificates can be generated on the fly by malware, using a simple command or series of CryptoAPI calls. I am aware of the procedure the CAs follow, and I am well aware that there are significant theoretical weaknesses inherent to the procedures that are followed to authenticate such "Turbo", "Domain auth" based SSL certificates. (They use an unencrypted e-mail message to send the equivalent of a PIN number, for getting a certificate signed, in reliance of WHOIS information downloaded over unencrypted connection: WHOIS data may be tampered with, a MITM may be used to alter WHOIS response in transit to the CA --- the PIN number in confirmation e-mail can be sniffed in transit, or the contact e-mail address may be hosted by a 3rd party insecure service provider and/or no longer belong to the authorized contact). All of these practices have considerable risks, and the risk that _some_ fraudulent requests are approved is signicant. The very e-mail server the certificate is to be issued to, might be the one that receives the e-mail, and a passive sniffer there may capture the PIN required to authorize the certificate. However, the procedures required to exploit these weaknesses are slightly more complicated than simply producing a self-signed certificate on the fly for man in the middle use -- they require planning, a waiting period, because CAs do not typically issue immediately. And the use of credit card numbers; either legitimate ones, which provide a trail to trace the attacker, or stolen ones, which is a requirement, that reduces the possible size of an attack (since a worm, or other malware infection, won't have an infinite supply of those to apply for certificates). But "Does the CA's signature actually represent a guaranteed authentication" wasn't the question. The only question is... Does it provide an assurance that is at all stronger than a self-signed certificate that can be made on the fly? And it does... not a strong one, but a slightly stronger one. > mail sent from that server. That doesn't sound like "authentication > of server identity" to me. > > R's, > John -- -JH From rsk at gsp.org Mon Dec 31 11:44:34 2012 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 31 Dec 2012 06:44:34 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: <20121231114434.GA6972@gsp.org> On Sun, Dec 30, 2012 at 10:26:36PM -0600, Jimmy Hess wrote: > These CA's will normally require interactions be done through a web > site, there will often be captchas or other methods involved in > applying for a certificate that are difficult to automate. You're kidding, right? Captchas have been quite, quite thoroughly beaten for some time now. See, among others: http://www.physorg.com/news/2011-11-stanford-outsmart-captcha-codes.html http://cintruder.sourceforge.net/ http://arstechnica.com/security/2012/05/google-recaptcha-brought-to-its-knees/ http://arstechnica.com/news.ars/post/20080415-gone-in-60-seconds-spambot-cracks-livehotmail-captcha.html http://www.troyhunt.com/2012/01/breaking-captcha-with-automated-humans.html http://it.slashdot.org/article.pl?sid=08/10/14/1442213 ---rsk From johnl at iecc.com Mon Dec 31 14:07:11 2012 From: johnl at iecc.com (John R. Levine) Date: 31 Dec 2012 09:07:11 -0500 Subject: Gmail and SSL In-Reply-To: References: <20121231034645.11439.qmail@joyce.lan> Message-ID: > However, the procedures required to exploit these weaknesses are > slightly more complicated than simply producing a self-signed > certificate on the fly for man in the middle use -- they require > planning, a waiting period, because CAs do not typically issue > immediately. Hmmn, I guess I was right, you haven't bought any certs lately. Startcom typically issues on the spot, Comodo and Geotrust mail them to you within 15 minutes. I agree that 15 minutes is not exactly the same as immediately, but so what? > And the use of credit card numbers; either legitimate ones, which > provide a trail to trace the attacker, or stolen ones, ... or a prepaid card bought for cash at a convenience or grocery store. Really, this isn't hard to understand. Current SSL signers do no more than tie the identity of the cert to the identity of a domain name. Anyone who's been following the endless crisis at ICANN about bogus WHOIS knows that domain names do not reliably identify anyone. > The only question is... Does it provide an assurance that is at all > stronger than a self-signed certificate that can be made on the fly? > > And it does... not a strong one, but a slightly stronger one. I supose to the extent that 0.2% is greater than 0.1%, perhaps. But not enough for any sensible person to care. Also keep in mind that this particular argument is about the certs used to submit mail to Gmail, which requires a separate SMTP AUTH within the SSL session before you can send any mail. This isn't belt and suspenders, this is belt and a 1/16" inch piece of duct tape. R's, John From drew.weaver at thenap.com Mon Dec 31 15:41:09 2012 From: drew.weaver at thenap.com (Drew Weaver) Date: Mon, 31 Dec 2012 10:41:09 -0500 Subject: Happy new year (and contact at 7018/20057) Message-ID: Howdy and Happy New Year. We're having some IP/routing issues with AS 20057/7018 and so far attempts at hitting noc at att.net and noc at attglobal.net haven't been successful. Does anyone have a contact at 20057 or 7018 or if anyone from those orgs are reading this can you please contact me off list? Thanks, -Drew From rjoffe at centergate.com Mon Dec 31 15:41:54 2012 From: rjoffe at centergate.com (Rodney Joffe) Date: Mon, 31 Dec 2012 10:41:54 -0500 Subject: GeekTools Whois Proxy and RIPE/RIPE-NCC Message-ID: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> NANOG and ARIN Friends, 14 Years ago, at the suggestion of Jon Postel and some of the early participants in NANOG, we developed the GeekTools Whois proxy to make it easier for *us* - network security and abuse techs - to deal with the expanding number of gtlds and registrars and the varied whois servers that were appearing. The service had both a CLI and web interface. The service also led directly to the creation of whois-servers.net, which now seems to be part of a number of *nix distributions. The service has been up for 14 years, and over that time we have fulfilled the requirements of all of the whois server operators in regards to minimizing and stopping abuse of the GT whois proxy by domain scrapers, spammers, etc, while enabling the security folks to do their jobs. In some cases we have even written code to pass the ip address of the requestor to the whois server registry operator when they wanted to manage quota's directly. We think we have a really good relationship with all of the whois server operators, and I think we provide a useful service to the community, and is widely used. And in 14 years we have never been tarred as an enabler of abuse of "the whois" system. There has obviously never been any kind of charge or fee for using the proxy, or any of the other tools on GeekTools. In about 2002 we started placing a banner ad on the web interface page to offset some of the costs for the bandwidth that the proxy consumes. An average of about $70 a month for over the last 10 years. Actual bandwidth costs are higher than that of course, but it was a thought in 2002 that we had frankly forgotten about until recently. Two weeks ago RIPE-NCC, who provide the whois data for IP addresses in the RIPE region, informed us that based on decisions by their members, as of January 1st 2013, tomorrow, they would no longer provide whois proxy query response services to GeekTools unless we ponied up $1,800 a year for RIPE membership. I don't work very well above layer 7. It is what it is. So I wanted to let you know that as of midnight tonight, apparently, you won't be able to use GeekTools for RIPE related queries. If you have automated scripts, and you are one of the users who has expanded access to GeekTools, you'll need to find an alternative for RIPE queries *today*. My guess is that you will be able to query RIPE directly, once you have worked out that the address space is within RIPE's assignments. I think its wrong to have to pay for whois data that is part of a community resource . So I won't do it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From drc at virtualized.org Mon Dec 31 15:55:09 2012 From: drc at virtualized.org (David Conrad) Date: Mon, 31 Dec 2012 07:55:09 -0800 Subject: GeekTools Whois Proxy and RIPE/RIPE-NCC In-Reply-To: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> References: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> Message-ID: <0C07BC2C-AA0E-4B3A-9BD4-324944B76684@virtualized.org> Rodney, On Dec 31, 2012, at 7:41 AM, Rodney Joffe wrote: > Two weeks ago RIPE-NCC, who provide the whois data for IP addresses in the RIPE region, informed us that based on decisions by their members, as of January 1st 2013, tomorrow, they would no longer provide whois proxy query response services to GeekTools unless we ponied up $1,800 a year for RIPE membership. ... > I think its wrong to have to pay for whois data that is part of a community resource . So I won't do it. I have to assume there is some sort of misunderstanding here as the actions on behalf of RIPE you describe are ... surprising. However, if there isn't a misunderstanding then I strongly agree with you. I'll be interested in seeing RIPE's side of the story... Regards, -drc From rjoffe at centergate.com Mon Dec 31 16:27:53 2012 From: rjoffe at centergate.com (Rodney Joffe) Date: Mon, 31 Dec 2012 11:27:53 -0500 Subject: GeekTools Whois Proxy and RIPE/RIPE-NCC In-Reply-To: <0C07BC2C-AA0E-4B3A-9BD4-324944B76684@virtualized.org> References: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> <0C07BC2C-AA0E-4B3A-9BD4-324944B76684@virtualized.org> Message-ID: Hi David, On Dec 31, 2012, at 10:55 AM, David Conrad wrote: > Rodney, > > On Dec 31, 2012, at 7:41 AM, Rodney Joffe wrote: >> Two weeks ago RIPE-NCC, who provide the whois data for IP addresses in the RIPE region, informed us that based on decisions by their members, as of January 1st 2013, tomorrow, they would no longer provide whois proxy query response services to GeekTools unless we ponied up $1,800 a year for RIPE membership. > ... >> I think its wrong to have to pay for whois data that is part of a community resource . So I won't do it. > > I have to assume there is some sort of misunderstanding here as the actions on behalf of RIPE you describe are ... surprising. However, if there isn't a misunderstanding then I strongly agree with you. > > I'll be interested in seeing RIPE's side of the story? I am absolutely open to believing that I have misunderstood. The older I've gotten, the dumber I've realized I am ;-) The references I can provide (besides the notice from RIPE which you already have) appear to be: http://www.ripe.net/ripe/docs/ripe-558 , specifically 2.4.7 RIPE Database Proxy Service /rlj From job.snijders at atrato-ip.com Mon Dec 31 16:46:07 2012 From: job.snijders at atrato-ip.com (Job Snijders) Date: Mon, 31 Dec 2012 17:46:07 +0100 Subject: GeekTools Whois Proxy and RIPE/RIPE-NCC In-Reply-To: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> References: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> Message-ID: <77455F9F-4ED4-4494-A3BB-679BDA81479B@atrato-ip.com> Hi Rodney, From the looks of it, this decision was made by the RIPE NCC Executive Board rather than at the General Meeting. Inqueries will have to be made why this was decided, and what the consequences are. But, I don't expect a resolution to be reached in the next 6 hours. In the meantime you could consider setting up an irrd[1], redirect queries to that instance instead of whois.ripe.net, and keep it kind of fresh by feeding it ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz on a daily basis. Kind regards, Job [1] http://www.irrd.net/ On Dec 31, 2012, at 4:41 PM, Rodney Joffe wrote: > NANOG and ARIN Friends, > > 14 Years ago, at the suggestion of Jon Postel and some of the early participants in NANOG, we developed the GeekTools Whois proxy to make it easier for *us* - network security and abuse techs - to deal with the expanding number of gtlds and registrars and the varied whois servers that were appearing. The service had both a CLI and web interface. > > The service also led directly to the creation of whois-servers.net, which now seems to be part of a number of *nix distributions. > > The service has been up for 14 years, and over that time we have fulfilled the requirements of all of the whois server operators in regards to minimizing and stopping abuse of the GT whois proxy by domain scrapers, spammers, etc, while enabling the security folks to do their jobs. In some cases we have even written code to pass the ip address of the requestor to the whois server registry operator when they wanted to manage quota's directly. We think we have a really good relationship with all of the whois server operators, and I think we provide a useful service to the community, and is widely used. And in 14 years we have never been tarred as an enabler of abuse of "the whois" system. > > There has obviously never been any kind of charge or fee for using the proxy, or any of the other tools on GeekTools. In about 2002 we started placing a banner ad on the web interface page to offset some of the costs for the bandwidth that the proxy consumes. An average of about $70 a month for over the last 10 years. Actual bandwidth costs are higher than that of course, but it was a thought in 2002 that we had frankly forgotten about until recently. > > Two weeks ago RIPE-NCC, who provide the whois data for IP addresses in the RIPE region, informed us that based on decisions by their members, as of January 1st 2013, tomorrow, they would no longer provide whois proxy query response services to GeekTools unless we ponied up $1,800 a year for RIPE membership. > > I don't work very well above layer 7. It is what it is. So I wanted to let you know that as of midnight tonight, apparently, you won't be able to use GeekTools for RIPE related queries. If you have automated scripts, and you are one of the users who has expanded access to GeekTools, you'll need to find an alternative for RIPE queries *today*. My guess is that you will be able to query RIPE directly, once you have worked out that the address space is within RIPE's assignments. > > I think its wrong to have to pay for whois data that is part of a community resource . So I won't do it. -- AS5580 - Atrato IP Networks From rjoffe at centergate.com Mon Dec 31 16:56:14 2012 From: rjoffe at centergate.com (Rodney Joffe) Date: Mon, 31 Dec 2012 11:56:14 -0500 Subject: GeekTools Whois Proxy and RIPE/RIPE-NCC In-Reply-To: <77455F9F-4ED4-4494-A3BB-679BDA81479B@atrato-ip.com> References: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> <77455F9F-4ED4-4494-A3BB-679BDA81479B@atrato-ip.com> Message-ID: <7AB7F2EF-DDA1-4187-8880-87FB53707C89@centergate.com> Hi Job, On Dec 31, 2012, at 11:46 AM, Job Snijders wrote: > Hi Rodney, > > From the looks of it, this decision was made by the RIPE NCC Executive Board rather than at the General Meeting. Inqueries will have to be made why this was decided, and what the consequences are. But, I don't expect a resolution to be reached in the next 6 hours. I don't expect it to be resolved in any different way at all, based on my experience over the last 20 years. We're not a RIPE member, so we have *zero* influence, and relevance for the RIP-NCC board. > In the meantime you could consider setting up an irrd[1], redirect queries to that instance instead of whois.ripe.net, and keep it kind of fresh by feeding it ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz on a daily basis. As far as bulk data, one *really* important aspect of GeekTools from day 1, is that we do not provide any actual data, we *only* proxy data. So there is no possibility that at any time we have stale data. We are a proxy, not a provider of data. Its what Jon told me to do 14 years ago, and its what we have stuck to (I think we're the only whois proxy that has done this). If we give you an answer today, you can count on it being the authoritative answer as of this second. If we can't reach a whois server when you query us, we do *not* give you a cached answer. We store nothing. Important when chasing miscreants or problems. I don't want to change this. > > Kind regards, > > Job > > [1] http://www.irrd.net/ > > On Dec 31, 2012, at 4:41 PM, Rodney Joffe wrote: > >> NANOG and ARIN Friends, >> >> 14 Years ago, at the suggestion of Jon Postel and some of the early participants in NANOG, we developed the GeekTools Whois proxy to make it easier for *us* - network security and abuse techs - to deal with the expanding number of gtlds and registrars and the varied whois servers that were appearing. The service had both a CLI and web interface. >> >> The service also led directly to the creation of whois-servers.net, which now seems to be part of a number of *nix distributions. >> >> The service has been up for 14 years, and over that time we have fulfilled the requirements of all of the whois server operators in regards to minimizing and stopping abuse of the GT whois proxy by domain scrapers, spammers, etc, while enabling the security folks to do their jobs. In some cases we have even written code to pass the ip address of the requestor to the whois server registry operator when they wanted to manage quota's directly. We think we have a really good relationship with all of the whois server operators, and I think we provide a useful service to the community, and is widely used. And in 14 years we have never been tarred as an enabler of abuse of "the whois" system. >> >> There has obviously never been any kind of charge or fee for using the proxy, or any of the other tools on GeekTools. In about 2002 we started placing a banner ad on the web interface page to offset some of the costs for the bandwidth that the proxy consumes. An average of about $70 a month for over the last 10 years. Actual bandwidth costs are higher than that of course, but it was a thought in 2002 that we had frankly forgotten about until recently. >> >> Two weeks ago RIPE-NCC, who provide the whois data for IP addresses in the RIPE region, informed us that based on decisions by their members, as of January 1st 2013, tomorrow, they would no longer provide whois proxy query response services to GeekTools unless we ponied up $1,800 a year for RIPE membership. >> >> I don't work very well above layer 7. It is what it is. So I wanted to let you know that as of midnight tonight, apparently, you won't be able to use GeekTools for RIPE related queries. If you have automated scripts, and you are one of the users who has expanded access to GeekTools, you'll need to find an alternative for RIPE queries *today*. My guess is that you will be able to query RIPE directly, once you have worked out that the address space is within RIPE's assignments. >> >> I think its wrong to have to pay for whois data that is part of a community resource . So I won't do it. > > -- > AS5580 - Atrato IP Networks > > > > From rjoffe at centergate.com Mon Dec 31 19:36:44 2012 From: rjoffe at centergate.com (Rodney Joffe) Date: Mon, 31 Dec 2012 14:36:44 -0500 Subject: Update: Re: GeekTools Whois Proxy and RIPE/RIPE-NCC In-Reply-To: <77455F9F-4ED4-4494-A3BB-679BDA81479B@atrato-ip.com> References: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> <77455F9F-4ED4-4494-A3BB-679BDA81479B@atrato-ip.com> Message-ID: <89C1080F-1311-4C1E-AC1E-CEBB16038D2F@centergate.com> So we think we're working out the impact, and have a work-around for users. There seem to be more than a few hundred network operations groups (thats many of you on NANOG) that use GeekTools (we can tell by the NAT IP addresses, and the rate of queries) that will be affected. It seems that what RIPE is doing is removing the ability for us to query their whois server using the special format that passes "your" ip address to RIPE in our queries that go to them. This was how they satisfied themselves that if *you* were abusing the query limit, and we had not caught it, and were not already preemptively blocking you or rate limiting you, they could do it. I guess its their version of "trust, but verify". No argument from us. They are not alone. We do the same thing with AFRINIC and APNIC amongst RIRs, nic.br as a TLD operator, and Network Solutions as a registrar. DENIC and a few others have asked us to provide queries in special formats, and we happily comply with all of these. We appreciate their efforts to enable us to help the community. And I think they've mostly been happy with us for the last 14 years or whatever. (BTW there are about 310 of them total at the moment that we're able to parse and identify and query for, as well as many more specially requested cases, like uk.com, au.com, etc. RIPE-NCC has decided to limit this to their members only. Not us. So they are now removing that from us. We will now be subject to their normal limits (whatever that is). When we reach our daily limit, we will be blocked. When we do that a few times, we will be permanently blacklisted. The good news is that if you query them yourselves, you'll be able to query them up to your daily individual limit before being blocked. So if you have been using us, and have never been blocked with RIPE queries, you will likely not be blocked when you query then direct (we have already been passing them your IP address so they can count and rate limit). The only difference is that now you you can make a single query for every TLD, every RWHOIS delegated server via the TLD whois server, and every RIR, and get a answer in one. Except if it ends up in RIPE land. Then you're on your own, walking their tree, etc. But you can do it manually. Later today, when we see how RIPE handles rejecting us, we'll write a script, and without asking you all to become members and pay us $1,800 a year , we'll post here, identifying the text we'll pass so that you can configure scripts to recognize the rejection, and handle the query in an exception routine. Also, more than 10 years ago, we created a windows program that loaded in the systray, and provided desktop capabilities. And we also made available the gpl'd unix source for people who wanted to run it locally. We haven't updated it for years, but many of you have it and did update, and that will not be affected, beyond the existing limitation you would be seeing - the app queries from your own IP address already. If any of you has been maintaining and upgrading/updating the app, and feels like sharing it, please do ;-). If you want, send it to us and we'll audit it (I know you won't mind in today's environment) and then add it to the geektools website. I guess I should also put together a smartphone app that uses the proxy as well? Anyway, enough noise for now. Apologies. And thanks to all of you who responded privately, with offers etc. Fortunately we don't need finance, or resources or support. I'm just happy it has helped for so long. Wishing you everything you want for yourselves in 2013 - the year of IPv6 and hundreds of new TLDs. Rodney and the CenterGate/GeekTools crew (yes, we're still around ;-)). . . . - . - On Dec 31, 2012, at 11:46 AM, Job Snijders wrote: > Hi Rodney, > > From the looks of it, this decision was made by the RIPE NCC Executive Board rather than at the General Meeting. Inqueries will have to be made why this was decided, and what the consequences are. But, I don't expect a resolution to be reached in the next 6 hours. > > In the meantime you could consider setting up an irrd[1], redirect queries to that instance instead of whois.ripe.net, and keep it kind of fresh by feeding it ftp://ftp.ripe.net/ripe/dbase/ripe.db.gz on a daily basis. > > Kind regards, > > Job > > [1] http://www.irrd.net/ > > On Dec 31, 2012, at 4:41 PM, Rodney Joffe wrote: > >> NANOG and ARIN Friends, >> >> 14 Years ago, at the suggestion of Jon Postel and some of the early participants in NANOG, we developed the GeekTools Whois proxy to make it easier for *us* - network security and abuse techs - to deal with the expanding number of gtlds and registrars and the varied whois servers that were appearing. The service had both a CLI and web interface. >> >> The service also led directly to the creation of whois-servers.net, which now seems to be part of a number of *nix distributions. >> >> The service has been up for 14 years, and over that time we have fulfilled the requirements of all of the whois server operators in regards to minimizing and stopping abuse of the GT whois proxy by domain scrapers, spammers, etc, while enabling the security folks to do their jobs. In some cases we have even written code to pass the ip address of the requestor to the whois server registry operator when they wanted to manage quota's directly. We think we have a really good relationship with all of the whois server operators, and I think we provide a useful service to the community, and is widely used. And in 14 years we have never been tarred as an enabler of abuse of "the whois" system. >> >> There has obviously never been any kind of charge or fee for using the proxy, or any of the other tools on GeekTools. In about 2002 we started placing a banner ad on the web interface page to offset some of the costs for the bandwidth that the proxy consumes. An average of about $70 a month for over the last 10 years. Actual bandwidth costs are higher than that of course, but it was a thought in 2002 that we had frankly forgotten about until recently. >> >> Two weeks ago RIPE-NCC, who provide the whois data for IP addresses in the RIPE region, informed us that based on decisions by their members, as of January 1st 2013, tomorrow, they would no longer provide whois proxy query response services to GeekTools unless we ponied up $1,800 a year for RIPE membership. >> >> I don't work very well above layer 7. It is what it is. So I wanted to let you know that as of midnight tonight, apparently, you won't be able to use GeekTools for RIPE related queries. If you have automated scripts, and you are one of the users who has expanded access to GeekTools, you'll need to find an alternative for RIPE queries *today*. My guess is that you will be able to query RIPE directly, once you have worked out that the address space is within RIPE's assignments. >> >> I think its wrong to have to pay for whois data that is part of a community resource . So I won't do it. > > -- > AS5580 - Atrato IP Networks > > > > From ebais at a2b-internet.com Mon Dec 31 19:48:47 2012 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 31 Dec 2012 20:48:47 +0100 Subject: GeekTools Whois Proxy and RIPE/RIPE-NCC In-Reply-To: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> References: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> Message-ID: Hi Rodney, Would support from a RIPE LIR be sufficient to keep the service up ? I'm pretty sure there isn't a requirement to register for a LIR membership if this is the only usage. As a RIPE LIR, we can have a look at what the options are if that would help. Have a good new year, Regards, Erik Bais A2B Internet Verstuurd vanaf mijn iPad Op 31 dec. 2012 om 16:41 heeft Rodney Joffe het volgende geschreven: > NANOG and ARIN Friends, > > 14 Years ago, at the suggestion of Jon Postel and some of the early participants in NANOG, we developed the GeekTools Whois proxy to make it easier for *us* - network security and abuse techs - to deal with the expanding number of gtlds and registrars and the varied whois servers that were appearing. The service had both a CLI and web interface. > > The service also led directly to the creation of whois-servers.net, which now seems to be part of a number of *nix distributions. > > The service has been up for 14 years, and over that time we have fulfilled the requirements of all of the whois server operators in regards to minimizing and stopping abuse of the GT whois proxy by domain scrapers, spammers, etc, while enabling the security folks to do their jobs. In some cases we have even written code to pass the ip address of the requestor to the whois server registry operator when they wanted to manage quota's directly. We think we have a really good relationship with all of the whois server operators, and I think we provide a useful service to the community, and is widely used. And in 14 years we have never been tarred as an enabler of abuse of "the whois" system. > > There has obviously never been any kind of charge or fee for using the proxy, or any of the other tools on GeekTools. In about 2002 we started placing a banner ad on the web interface page to offset some of the costs for the bandwidth that the proxy consumes. An average of about $70 a month for over the last 10 years. Actual bandwidth costs are higher than that of course, but it was a thought in 2002 that we had frankly forgotten about until recently. > > Two weeks ago RIPE-NCC, who provide the whois data for IP addresses in the RIPE region, informed us that based on decisions by their members, as of January 1st 2013, tomorrow, they would no longer provide whois proxy query response services to GeekTools unless we ponied up $1,800 a year for RIPE membership. > > I don't work very well above layer 7. It is what it is. So I wanted to let you know that as of midnight tonight, apparently, you won't be able to use GeekTools for RIPE related queries. If you have automated scripts, and you are one of the users who has expanded access to GeekTools, you'll need to find an alternative for RIPE queries *today*. My guess is that you will be able to query RIPE directly, once you have worked out that the address space is within RIPE's assignments. > > I think its wrong to have to pay for whois data that is part of a community resource . So I won't do it. From rjoffe at centergate.com Mon Dec 31 19:56:59 2012 From: rjoffe at centergate.com (Rodney Joffe) Date: Mon, 31 Dec 2012 14:56:59 -0500 Subject: GeekTools Whois Proxy and RIPE/RIPE-NCC In-Reply-To: References: <71BEAB45-2AC4-4573-BF20-35B6BAB1B119@centergate.com> Message-ID: <4F68611B-2D1A-47C2-B8E5-B86ABFB3C1D3@centergate.com> Hi Erik, I appreciate the offer (a number of RIPE members have stepped forward). However I would not a) want this to in any way threaten your membership status - its possible I guess that this might violate the RIPE contract because it is a circumvention, and b) would not want special status - its important that the problem should be resolved for all the parties who are being affected and don't have a voice. GeekTools isn't special. I can easily afford RIPE membership. However its the principle, and the small folks that matter. I'm hoping that the good folks on the RIPE board think about the unintended detrimental consequences of their decision. I'm sure they didn't mean this to happen... Thanks again. Rodney On Dec 31, 2012, at 2:48 PM, Erik Bais wrote: > Hi Rodney, > > Would support from a RIPE LIR be sufficient to keep the service up ? > > I'm pretty sure there isn't a requirement to register for a LIR membership if this is the only usage. > > As a RIPE LIR, we can have a look at what the options are if that would help. > > Have a good new year, > > Regards, > Erik Bais > A2B Internet > > Verstuurd vanaf mijn iPad > > Op 31 dec. 2012 om 16:41 heeft Rodney Joffe het volgende geschreven: > >> NANOG and ARIN Friends, >> >> 14 Years ago, at the suggestion of Jon Postel and some of the early participants in NANOG, we developed the GeekTools Whois proxy to make it easier for *us* - network security and abuse techs - to deal with the expanding number of gtlds and registrars and the varied whois servers that were appearing. The service had both a CLI and web interface. >> >> The service also led directly to the creation of whois-servers.net, which now seems to be part of a number of *nix distributions. >> >> The service has been up for 14 years, and over that time we have fulfilled the requirements of all of the whois server operators in regards to minimizing and stopping abuse of the GT whois proxy by domain scrapers, spammers, etc, while enabling the security folks to do their jobs. In some cases we have even written code to pass the ip address of the requestor to the whois server registry operator when they wanted to manage quota's directly. We think we have a really good relationship with all of the whois server operators, and I think we provide a useful service to the community, and is widely used. And in 14 years we have never been tarred as an enabler of abuse of "the whois" system. >> >> There has obviously never been any kind of charge or fee for using the proxy, or any of the other tools on GeekTools. In about 2002 we started placing a banner ad on the web interface page to offset some of the costs for the bandwidth that the proxy consumes. An average of about $70 a month for over the last 10 years. Actual bandwidth costs are higher than that of course, but it was a thought in 2002 that we had frankly forgotten about until recently. >> >> Two weeks ago RIPE-NCC, who provide the whois data for IP addresses in the RIPE region, informed us that based on decisions by their members, as of January 1st 2013, tomorrow, they would no longer provide whois proxy query response services to GeekTools unless we ponied up $1,800 a year for RIPE membership. >> >> I don't work very well above layer 7. It is what it is. So I wanted to let you know that as of midnight tonight, apparently, you won't be able to use GeekTools for RIPE related queries. If you have automated scripts, and you are one of the users who has expanded access to GeekTools, you'll need to find an alternative for RIPE queries *today*. My guess is that you will be able to query RIPE directly, once you have worked out that the address space is within RIPE's assignments. >> >> I think its wrong to have to pay for whois data that is part of a community resource . So I won't do it. >