- NANOG - lists.nanog.org

IPv6 faster/better proof? was Re: Need /24 (arin) asap
by Scott Weeks 24 Jul '18

24 Jul '18

--- cb.list6(a)gmail.com wrote: From: Ca By <cb.list6(a)gmail.com> > Meanwhile, FB reports that 75% of mobiles in the USA > reach them via ipv6 > > And Akaimai reports 80% of mobiles And they both report ipv6 is faster / better. ---------------------------------------- Hmm... Faster and better? The links seem to be an IPv6 cheerleader write up. I looked at the URLs and the URLs one pointed to and pulled out everything related to IPv6 being faster/better. Akamai URL: "For dual-stacked hostnames we typically see higher average estimated throughput over IPv6 than over IPv4. Some of this may be due to IPv6-connected users being correlated with better connectivity, but over half of dual-stacked hostnames (weighted by daily bytes delivered) have IPv6 estimated throughput at least 50% faster than IPv4, and 90% of these hostnames have the IPv6 estimated throughput at least 10% faster than IPv4." FB URL: "People using Facebook services typically see better performance over IPv6..." and it points to https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-b… which says: "We’ve long been anticipating the exhaustion of IPv in favor of the speed and performance benefits of IPv6." "We’ve observed that accessing Facebook can be 10-15 percent faster over IPv6." I'd sure like to see how they came up with these numbers in a technically oriented paper. There should be no difference, except for no CGN or Happy Eyeballs working better or something similar. Am I missing something? Same routers; same links; same RTTs; same interrupt times on servers; same etc, etc for both protocols. scott

17 35

looking for collaborating data for phishing email
by Dan Hollis 23 Jul '18

23 Jul '18

Anyone who recently received the following phishing email, please drop me an email. I'm looking for collaborating data on an email database breach. Date: Wed, 18 Jul 2018 06:36:19 -0400 Return-Path: <AmericanExpress(a)aep.com> Received: from amp3.nuskin.com (amp3.nuskin.net [170.89.24.19] (may be forged)) From: American Express <AmericanExpress(a)aep.com> To: americanexpress(a)aep.com Subject: Act Now: Information About your Cardmember Account. -Dan

1 0

Cox contact?
by Anne P. Mitchell, Esq. 23 Jul '18

23 Jul '18

Does anybody have a contact at Cox (need networking but I'd take anything)? Thank you! Anne Anne P. Mitchell, Attorney at Law GDPR & CCPA Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center Member, California Bar Association Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop

1 0

FSEC.OR.KR
by Brian Kantor 23 Jul '18

23 Jul '18

Does anyone have a working contact email address for isac(a)fsec.or.kr? >From time to time we receive a security complaint from them, usually involving an IP address on our network that we know is not in use. They claim to represent the Financial Security Institute(FSI) of Korea, and usually say they may contact law enforcement in both our and their country. They request that we advise them of our action in whatever matter they happen to be complaining about. So far, so good. But... There is no record of fsec.or.kr at the APNIC nor KRNIC. All attempts to reply to these folks are in vain; they reject EVERY reply message - even "hello world" - with the rejection notice that the message contains spam. Before I put them in my 'smtp connection refused' list, I'd like to discuss the matter with them, or to at least let them know that they have a severe CRIS problem. - Brian

1 0

Nominations Open Until 31 July for ARIN Board of Trustees, ARIN Advisory Council, and NRO Number Council Seats
by John Curran 23 Jul '18

23 Jul '18

Folks - For those of you associated with ARIN member organizations, please note an important deadline fast approaching: the 31st of July is the last day for ARIN Members to nominate candidates to serve on the ARIN Board of Trustees and/or the ARIN Advisory Council. Note that 31 July is also the last day to nominate candidates to represent the ARIN region on the NRO Number Council (and anyone in the community may make such a nomination.) Submit your nomination(s) at https://www.surveymonkey.com/r/ARIN2018Nominations You can out find more information about ARIN elections at: https://www.arin.net/participate/elections/ Each ARIN member organization may cast one ballot in the ARIN Board, ARIN AC elections, and NRO NC elections – voting is done by the organization’s Voting Contact on record. Note that 20 August is the deadline to organizations to establish voter eligibility. More information is available at: https://www.arin.net/about_us/membership/votingcontacts.html (or reach out to members(a)arin.net<mailto:members@arin.net> with any questions or requests for assistance.) As NRO-NC are open to anyone in the community, those NANOG 74 and ARIN 42 meeting attendees who are registered by 27 September will receive an email invitation to vote online in the NRO NC elections which run from 1-12 October. Thanks! /John John Curran President and CEO American Registry for Internet Numbers (ARIN)

1 0

Re: Rising sea levels are going to mess with the internet
by Scott Weeks 23 Jul '18

23 Jul '18

<snippage occurred> --- rob(a)invaluement.com wrote: From: Rob McEwen <rob(a)invaluement.com> The bottom line is that there is no trend of recently observed sea level rising data that is even close to being on track to hit all these dire predictions within the foreseeable future.... And, again, there were articles like this 10, 15, and even 20 years ago that made very similar predictions - that didn't happen. ------------------------------------------ Maybe the dire predictions didn't happen, but when combined with other drivers stuff happens. For example: https://www.theguardian.com/environment/2016/may/10/headlines-exaggerated-c… "The study blamed the loss on a combination of sea-level rise and high wave energy." "The major misunderstanding stems from the conflation of sea-level rise with climate change." "...the ocean has been rising in the Solomon Islands at 7mm per year, more than double the global average." "...driven partly by global warming and partly by climatic cycles - in particular the Pacific Decadal Oscillation." So for us, it's an it depends thing. It depends what cables and where they're located. scott

2 1

[OT] Internet in China
by Danijel Starman 23 Jul '18

23 Jul '18

Hi, Can someone suggest a reliable internet provider in China? Are all options China Telecom? Some current links we have in Shanghai are sometimes exhibiting ~40% packet loss to Japan/Singapore AWS regions which is not really acceptable. Off-list replies are welcome too. Thank you! -- *blap*

2 1

Spectrum Outage
by Tyler Harden 23 Jul '18

23 Jul '18

Any Charter/Spectrum engineers in here? Seems to be a large outage.

1 0

Proving Gig Speed
by Chris Gross 22 Jul '18

22 Jul '18

I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes?

40 114

Re: using expect to log into devices
by Scott Weeks 22 Jul '18

22 Jul '18

--- ler762(a)gmail.com wrote: From: Lee <ler762(a)gmail.com> > I have a file with 1000s of devices and another file > with a list of commands. The program issues all > commands for a device and then moves on to the next > one using nested loops. In the debug I see the > "spawn_id expNN" (where NN is a number that, I > believe is representative of the number of file > descriptors used in the system) increment only when > a device does not respond. As long as a device > responds before the timeout period I see the expNN > number does not increase. As soon as a device > doesn't respond the expNN count goes up and I can't > figure out why. Once I hit a certain expNN the <snip> :: 'close $spawn_id' is wrong, so maybe that's it? :: man expect :: close [-slave] [-onexec 0|1] [-i spawn_id] :: closes the connection to the current process. :: ... The -i :: flag declares the :: process to close corresponding to the named :: spawn_id. <.. snip ..> ---------------------------------------- I hand typed the close stuff in the email with just 'close spawn_id'. I did the -i in previous iterations, but saw no difference. Maybe I should try more. I saw the 'close' alone a lot on Stackexchange a lot,so I was copying those in this iteration. I also should have read the man page more than I did, so a face slap to myself. :: No matter whether the connection is closed :: implicitly or explicitly, you should call wait to :: clear up the corresponding kernel process slot. :: close does not call wait since there is no guarantee :: that closing a process connection will cause it to :: exit. See wait below for more info. :: The eof and timeout cases are basically :: { catch {close}; catch {wait}; } I always used wait after close and need to look into those above. Maybe they close it different somehow. :: get rancid from here... and take a look at clogin... I'm going to be looking for a new job and want to up my skills, in case I get a chance to do the SDN/NFV stuff, which I read requires coding skills, so this is also an exercise toward that. Plus it's fun. I had already done this in PERL, but, even though we have PERL, we are not allowed to download modules here. So, I'm redoing it in Expect. I thought someone would say a "oh just <blah, blah> and you're done" type of response. Thanks a lot from everyone private and on the list. I'll post for the archives if I find the answer. scott

4 4