From nop at imap.cc Sun Apr 1 00:08:07 2018 From: nop at imap.cc (nop at imap.cc) Date: Sat, 31 Mar 2018 17:08:07 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> Message-ID: <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> On Sat, Mar 31, 2018, at 2:18 PM, Mehmet Akcin wrote: > Very disappointing to see a popular prefix being allocated/reseved for > research then being allocated to a company without public consultation. I > am sure APNIC community will ask APNIC Sr. management for an explanation. > > This prefix , if it will be given to any business , should go thru a > transparent bidding process OR regular APNIC allocation process > transprently. > >From what I can tell, this has not been "allocated" (probably closer to a LOA)? All contacts and maintainers on the inetnum object are still APNIC's, Cloudflare does not have free access to do whatever they want here. From mehmet at akcin.net Sun Apr 1 00:19:10 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 31 Mar 2018 17:19:10 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> Message-ID: https://www.wired.com/story/new-encryption-service-adds-privacy-protection-for-web-browsing/ On Sat, Mar 31, 2018 at 5:08 PM, wrote: > On Sat, Mar 31, 2018, at 2:18 PM, Mehmet Akcin wrote: > > > Very disappointing to see a popular prefix being allocated/reseved for > > research then being allocated to a company without public consultation. I > > am sure APNIC community will ask APNIC Sr. management for an explanation. > > > > This prefix , if it will be given to any business , should go thru a > > transparent bidding process OR regular APNIC allocation process > > transprently. > > > > From what I can tell, this has not been "allocated" (probably closer to a > LOA)? All contacts and maintainers on the inetnum object are still APNIC's, > Cloudflare does not have free access to do whatever they want here. > From mysidia at gmail.com Sun Apr 1 01:05:56 2018 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 31 Mar 2018 20:05:56 -0500 Subject: Yet another Quadruple DNS? In-Reply-To: <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> Message-ID: On Sat, Mar 31, 2018 at 7:08 PM, wrote: > From what I can tell, this has not been "allocated" (probably closer to a LOA)? > All contacts and maintainers on the inetnum object are still APNIC's, Cloudflare > does not have free access to do whatever they want here. Did you ask WHOIS? Looks like the /24 is Portable-Assigned to a joint project. I don't know that APNIC is necessarily required to make a public consultation;. If it was from an ARIN block; ARIN wouldn't have to "ask the public either"... the Number Resource Policy allows for /24 micro-allocations for critical infrastructure, which exactly describes the nature of an anycasted /24 for the service IP of a shared open DNS recursive resolver service, and the RIR could potentially allocate from any block under their control that were deemed most suitable for the critical infrastructure. Then again, maybe APNIC made a consultation at their February meeting in Nepal? One thing i'm sure is they wouldn't have to ask NANOG's permission. $ whois 1.1.1.1 % [whois.apnic.net] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html % Information related to '1.1.1.0 - 1.1.1.255' % Abuse contact for '1.1.1.0 - 1.1.1.255' is 'abuse at apnic.net' inetnum: 1.1.1.0 - 1.1.1.255 netname: APNIC-LABS descr: APNIC and Cloudflare DNS Resolver project descr: Routed globally by AS13335/Cloudflare descr: Research prefix for APNIC Labs country: AU org: ORG-ARAD1-AP admin-c: AR302-AP tech-c: AR302-AP mnt-by: APNIC-HM mnt-routes: MAINT-AU-APNIC-GM85-AP mnt-irt: IRT-APNICRANDNET-AU status: ASSIGNED PORTABLE remarks: --------------- remarks: All Cloudflare abuse reporting can be done via remarks: resolver-abuse at cloudflare.com remarks: --------------- last-modified: 2018-03-30T01:51:28Z source: APNIC ..... -- -JH From job at instituut.net Sun Apr 1 11:09:16 2018 From: job at instituut.net (Job Snijders) Date: Sun, 1 Apr 2018 11:09:16 +0000 Subject: IPv6 addressing plan spreadsheet issue Message-ID: <20180401110915.GA96949@vurt.meerval.net> Hi all, I made a list of the IPv6 addresses in my home LAN, but have trouble copy+pasting the list into a cloud spreadsheet. My address list is here: http://pete.meerval.net/~job/ How do other folks do this? Just administrate things in text files? Kind regards, Job From sp at iphh.net Sun Apr 1 11:15:47 2018 From: sp at iphh.net (Sascha Pollok) Date: Sun, 01 Apr 2018 13:15:47 +0200 Subject: IPv6 addressing plan spreadsheet issue In-Reply-To: <20180401110915.GA96949@vurt.meerval.net> References: <20180401110915.GA96949@vurt.meerval.net> Message-ID: <16280eb9ab8.27df.0891eb2d685d091c0d1b837b0ec4f146@iphh.net> Hi Job, I quickly went through your whole list and looking at the totally random addresses I think it is best if you render a multi-page TIFF file from each address and put them into a binary field of an MS Access database. That might sound unusual but you could easily access them from Excel and make notes for each address. Thank me later! Groet Sascha Am 1. April 2018 13:09:33 schrieb Job Snijders : > Hi all, > > I made a list of the IPv6 addresses in my home LAN, but have trouble > copy+pasting the list into a cloud spreadsheet. My address list is here: > http://pete.meerval.net/~job/ > > How do other folks do this? Just administrate things in text files? > > Kind regards, > > Job From timoid at timoid.org Sun Apr 1 11:25:46 2018 From: timoid at timoid.org (Tim Warnock) Date: Sun, 1 Apr 2018 11:25:46 +0000 Subject: IPv6 addressing plan spreadsheet issue In-Reply-To: <20180401110915.GA96949@vurt.meerval.net> References: <20180401110915.GA96949@vurt.meerval.net> Message-ID: <0eb3eb5af5db4e4391376dc168d5db55@timoid.org> > Hi all, > > I made a list of the IPv6 addresses in my home LAN, but have trouble > copy+pasting the list into a cloud spreadsheet. My address list is here: > http://pete.meerval.net/~job/ > > How do other folks do this? Just administrate things in text files? > > Kind regards, > > Job Length: unspecified [text/plain] Saving to: '/dev/null' Thanks for the speed test file! :) ps: phpIPAM is pretty good. From lists at quux.de Sun Apr 1 12:28:56 2018 From: lists at quux.de (Jens Link) Date: Sun, 01 Apr 2018 14:28:56 +0200 Subject: IPv6 addressing plan spreadsheet issue In-Reply-To: <20180401110915.GA96949@vurt.meerval.net> (Job Snijders's message of "Sun, 1 Apr 2018 11:09:16 +0000") References: <20180401110915.GA96949@vurt.meerval.net> Message-ID: <87370ft8jb.fsf@pc8.berlin.quux.de> Job Snijders writes: Hi, > I made a list of the IPv6 addresses in my home LAN, but have trouble > copy+pasting the list into a cloud spreadsheet. My address list is here: > http://pete.meerval.net/~job/ > > How do other folks do this? Just administrate things in text files? If the standard IPAM tool (aka. Excel) can't handle your address plan maybe it's not the fault of the spreadsheet but the fault of the protocol. After almost 3.500 days using IPv6 I decided to turn it of! Nobody uses it and nobody needs it! I'll to the same with DNSSEC! Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at quux.de | --------------- | ---------------------------------------------------------------------------- From list-nanog2 at dragon.net Sun Apr 1 15:02:07 2018 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Sun, 01 Apr 2018 09:02:07 -0600 Subject: IPv6 addressing plan spreadsheet issue In-Reply-To: <20180401110915.GA96949@vurt.meerval.net> References: <20180401110915.GA96949@vurt.meerval.net> Message-ID: <20180401150207.44BF953B490@fafnir.remote.dragon.net> job> Hi all, I made a list of the IPv6 addresses in my home LAN, but job> have trouble copy+pasting the list into a cloud spreadsheet. My job> address list is here: http://pete.meerval.net/~job/ job> How do other folks do this? Just administrate things in text files? I just put all my v6 addrs into an emoji-based DNS zone file. Then I altered all system files, including ifconfig, iptables, etc. to use DNS instead of raw IP addrs. I'm in the midst of uploading it all into route 53. I'm sure it will be finished soon. Problem solved. From mehmet at akcin.net Sun Apr 1 15:05:58 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 01 Apr 2018 15:05:58 +0000 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> Message-ID: https://1.1.1.1 link has details of the service. No official announcement from APNIC (though Geoff replied my direct email inquiry privately) I don’t know why this prefix was handed over to any company for a service without public consultation but again this may or may not be required. I am just suprised to see lack of transparency about this allocation rather than anything else. World needs more services like this to make internet better and safer, i don’t think it is important what IPs are , ie: opendns , they might not have fancy ip block but they get the job done!(well done!) Mehmet On Sat, Mar 31, 2018 at 6:06 PM Jimmy Hess wrote: > On Sat, Mar 31, 2018 at 7:08 PM, wrote: > > > From what I can tell, this has not been "allocated" (probably closer to > a LOA)? > > All contacts and maintainers on the inetnum object are still APNIC's, > Cloudflare > > does not have free access to do whatever they want here. > > Did you ask WHOIS? Looks like the /24 is Portable-Assigned to > a joint project. > I don't know that APNIC is necessarily required to make a public > consultation;. > > If it was from an ARIN block; ARIN wouldn't have to "ask the public > either"... > the Number Resource Policy allows for /24 micro-allocations for > critical infrastructure, which exactly describes the nature of an > anycasted > /24 for the service IP of a shared open DNS recursive resolver service, > and the RIR could potentially allocate from any block under their control > that > were deemed most suitable for the critical infrastructure. > > Then again, maybe APNIC made a consultation at their February meeting > in Nepal? > One thing i'm sure is they wouldn't have to ask NANOG's permission. > > $ whois 1.1.1.1 > % [whois.apnic.net] > % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html > > % Information related to '1.1.1.0 - 1.1.1.255' > % Abuse contact for '1.1.1.0 - 1.1.1.255' is 'abuse at apnic.net' > > inetnum: 1.1.1.0 - 1.1.1.255 > netname: APNIC-LABS > descr: APNIC and Cloudflare DNS Resolver project > descr: Routed globally by AS13335/Cloudflare > descr: Research prefix for APNIC Labs > country: AU > org: ORG-ARAD1-AP > admin-c: AR302-AP > tech-c: AR302-AP > mnt-by: APNIC-HM > mnt-routes: MAINT-AU-APNIC-GM85-AP > mnt-irt: IRT-APNICRANDNET-AU > status: ASSIGNED PORTABLE > remarks: --------------- > remarks: All Cloudflare abuse reporting can be done via > remarks: resolver-abuse at cloudflare.com > remarks: --------------- > last-modified: 2018-03-30T01:51:28Z > source: APNIC > > ..... > > > > -- > -JH > From mattlists at rivervalleyinternet.net Sun Apr 1 15:18:26 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Sun, 1 Apr 2018 11:18:26 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> Message-ID: Do we? (Need more services like this?) Why not just implement recursive cache severs on end user routers? Why does an end user CPE need to query one or two specific DNS servers? Recursive servers like PowerDNS are extremely simple and light weight. Is there a legitimate reason things don’t just query the root servers directly? Or at least have that option? > On Apr 1, 2018, at 11:05, Mehmet Akcin wrote: > > https://1.1.1.1 link has details of the service. > > No official announcement from APNIC (though Geoff replied my direct email > inquiry privately) > > I don’t know why this prefix was handed over to any company for a service > without public consultation but again this may or may not be required. I am > just suprised to see lack of transparency about this allocation rather than > anything else. > > World needs more services like this to make internet better and safer, i > don’t think it is important what IPs are , ie: opendns , they might not > have fancy ip block but they get the job done!(well done!) > > Mehmet > >> On Sat, Mar 31, 2018 at 6:06 PM Jimmy Hess wrote: >> >>> On Sat, Mar 31, 2018 at 7:08 PM, wrote: >>> >>> From what I can tell, this has not been "allocated" (probably closer to >> a LOA)? >>> All contacts and maintainers on the inetnum object are still APNIC's, >> Cloudflare >>> does not have free access to do whatever they want here. >> >> Did you ask WHOIS? Looks like the /24 is Portable-Assigned to >> a joint project. >> I don't know that APNIC is necessarily required to make a public >> consultation;. >> >> If it was from an ARIN block; ARIN wouldn't have to "ask the public >> either"... >> the Number Resource Policy allows for /24 micro-allocations for >> critical infrastructure, which exactly describes the nature of an >> anycasted >> /24 for the service IP of a shared open DNS recursive resolver service, >> and the RIR could potentially allocate from any block under their control >> that >> were deemed most suitable for the critical infrastructure. >> >> Then again, maybe APNIC made a consultation at their February meeting >> in Nepal? >> One thing i'm sure is they wouldn't have to ask NANOG's permission. >> >> $ whois 1.1.1.1 >> % [whois.apnic.net] >> % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html >> >> % Information related to '1.1.1.0 - 1.1.1.255' >> % Abuse contact for '1.1.1.0 - 1.1.1.255' is 'abuse at apnic.net' >> >> inetnum: 1.1.1.0 - 1.1.1.255 >> netname: APNIC-LABS >> descr: APNIC and Cloudflare DNS Resolver project >> descr: Routed globally by AS13335/Cloudflare >> descr: Research prefix for APNIC Labs >> country: AU >> org: ORG-ARAD1-AP >> admin-c: AR302-AP >> tech-c: AR302-AP >> mnt-by: APNIC-HM >> mnt-routes: MAINT-AU-APNIC-GM85-AP >> mnt-irt: IRT-APNICRANDNET-AU >> status: ASSIGNED PORTABLE >> remarks: --------------- >> remarks: All Cloudflare abuse reporting can be done via >> remarks: resolver-abuse at cloudflare.com >> remarks: --------------- >> last-modified: 2018-03-30T01:51:28Z >> source: APNIC >> >> ..... >> >> >> >> -- >> -JH >> From mehmet at akcin.net Sun Apr 1 15:32:18 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 01 Apr 2018 15:32:18 +0000 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> Message-ID: Well that isnt optimal for root servers. Every cpe querying root would be waste really. Though we can copy root zone into recursive servers (not via DNS) and serve from CPEs that way. I think the real problem is restictions of networks who won’t let you run this on your devices. Mehmet On Sun, Apr 1, 2018 at 8:18 AM Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > Do we? (Need more services like this?) > > Why not just implement recursive cache severs on end user routers? Why > does an end user CPE need to query one or two specific DNS servers? > > Recursive servers like PowerDNS are extremely simple and light weight. > > Is there a legitimate reason things don’t just query the root servers > directly? Or at least have that option? > > > On Apr 1, 2018, at 11:05, Mehmet Akcin wrote: > > > > https://1.1.1.1 link has details of the service. > > > > No official announcement from APNIC (though Geoff replied my direct email > > inquiry privately) > > > > I don’t know why this prefix was handed over to any company for a service > > without public consultation but again this may or may not be required. I > am > > just suprised to see lack of transparency about this allocation rather > than > > anything else. > > > > World needs more services like this to make internet better and safer, i > > don’t think it is important what IPs are , ie: opendns , they might not > > have fancy ip block but they get the job done!(well done!) > > > > Mehmet > > > >> On Sat, Mar 31, 2018 at 6:06 PM Jimmy Hess wrote: > >> > >>> On Sat, Mar 31, 2018 at 7:08 PM, wrote: > >>> > >>> From what I can tell, this has not been "allocated" (probably closer to > >> a LOA)? > >>> All contacts and maintainers on the inetnum object are still APNIC's, > >> Cloudflare > >>> does not have free access to do whatever they want here. > >> > >> Did you ask WHOIS? Looks like the /24 is Portable-Assigned to > >> a joint project. > >> I don't know that APNIC is necessarily required to make a public > >> consultation;. > >> > >> If it was from an ARIN block; ARIN wouldn't have to "ask the public > >> either"... > >> the Number Resource Policy allows for /24 micro-allocations for > >> critical infrastructure, which exactly describes the nature of an > >> anycasted > >> /24 for the service IP of a shared open DNS recursive resolver > service, > >> and the RIR could potentially allocate from any block under their > control > >> that > >> were deemed most suitable for the critical infrastructure. > >> > >> Then again, maybe APNIC made a consultation at their February meeting > >> in Nepal? > >> One thing i'm sure is they wouldn't have to ask NANOG's permission. > >> > >> $ whois 1.1.1.1 > >> % [whois.apnic.net] > >> % Whois data copyright terms > http://www.apnic.net/db/dbcopyright.html > >> > >> % Information related to '1.1.1.0 - 1.1.1.255' > >> % Abuse contact for '1.1.1.0 - 1.1.1.255' is 'abuse at apnic.net' > >> > >> inetnum: 1.1.1.0 - 1.1.1.255 > >> netname: APNIC-LABS > >> descr: APNIC and Cloudflare DNS Resolver project > >> descr: Routed globally by AS13335/Cloudflare > >> descr: Research prefix for APNIC Labs > >> country: AU > >> org: ORG-ARAD1-AP > >> admin-c: AR302-AP > >> tech-c: AR302-AP > >> mnt-by: APNIC-HM > >> mnt-routes: MAINT-AU-APNIC-GM85-AP > >> mnt-irt: IRT-APNICRANDNET-AU > >> status: ASSIGNED PORTABLE > >> remarks: --------------- > >> remarks: All Cloudflare abuse reporting can be done via > >> remarks: resolver-abuse at cloudflare.com > >> remarks: --------------- > >> last-modified: 2018-03-30T01:51:28Z > >> source: APNIC > >> > >> ..... > >> > >> > >> > >> -- > >> -JH > >> > From list at satchell.net Sun Apr 1 16:22:10 2018 From: list at satchell.net (Stephen Satchell) Date: Sun, 1 Apr 2018 09:22:10 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> Message-ID: On 04/01/2018 08:18 AM, Matt Hoppes wrote: > Why not just implement recursive cache severs on end user routers? > Why does an end user CPE need to query one or two specific DNS > servers? Recursive lookups take bandwidth and wall time. The closer you can get your recursive DNS server to the core of the internet, the faster the lookups. This is particularly true of mobile and satellite. Implementing large caches in that close-to-the-core DNS server can add another benefit: lookups to common and popular endpoints, such as Google, would require far less real time to resolve. As the traffic tides change, the cache would change with it, so flash-in-the-pan sites would be served from cache, and forgotten in time when said sites drift back to obscurity. (I wonder if the Internet Systems Consortium has considered adding a cache-hit counter, or even a very coarse heat map (say, four 16-bit counters cycled every five minutes), to DNS entries, to figure out the best ones to drop? It would increase the complexity of BIND, but the benefit for a BIND server serving a largish customer population could be significant. If I were younger, I might try to model such a change. Sort by hits, then by time-to-die. Drop the oldest 250 or so entries when the cache is full. That way, the oldest least-used cache entries get dropped.) ISPs provide to their customers DNS addresses to servers that, allegedly, are closer to the core than the customers are. (Pipe dream, I know; which is why so many ISPs have decided to specify 8.8.8.8 and 8.8.4.4, because Google is closer to the core than the ISP is.) I've not personally measured the number of times a look-up could be satisfied from a cache in a production environment; it's been 15 years since I worked in such a job. It would be interesting to see if someone has taken the time to gather those statistics and published them. The main reason for *not* implementing recursion exclusively in CPE is that a recursive lookup is a complex operation, and I have my doubts if BIND or equivalent could be maintained properly in, say, a wireless access point (router) -- how would you update a hints table? From nanog at ics-il.net Sun Apr 1 17:05:15 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 1 Apr 2018 12:05:15 -0500 (CDT) Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> Message-ID: <761822155.464.1522602310249.JavaMail.mhammett@ThunderFuck> Unless you want optimum CDN performance, then your recursive servers belong pushed back in your network until there are no more diverse upstream\peer paths to choose from. Yes, I know there's an extension to DNS to help remove this need, but until that's universally supported, you can't abandon the old way. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Stephen Satchell" To: nanog at nanog.org Sent: Sunday, April 1, 2018 11:22:10 AM Subject: Re: Yet another Quadruple DNS? On 04/01/2018 08:18 AM, Matt Hoppes wrote: > Why not just implement recursive cache severs on end user routers? > Why does an end user CPE need to query one or two specific DNS > servers? Recursive lookups take bandwidth and wall time. The closer you can get your recursive DNS server to the core of the internet, the faster the lookups. This is particularly true of mobile and satellite. Implementing large caches in that close-to-the-core DNS server can add another benefit: lookups to common and popular endpoints, such as Google, would require far less real time to resolve. As the traffic tides change, the cache would change with it, so flash-in-the-pan sites would be served from cache, and forgotten in time when said sites drift back to obscurity. (I wonder if the Internet Systems Consortium has considered adding a cache-hit counter, or even a very coarse heat map (say, four 16-bit counters cycled every five minutes), to DNS entries, to figure out the best ones to drop? It would increase the complexity of BIND, but the benefit for a BIND server serving a largish customer population could be significant. If I were younger, I might try to model such a change. Sort by hits, then by time-to-die. Drop the oldest 250 or so entries when the cache is full. That way, the oldest least-used cache entries get dropped.) ISPs provide to their customers DNS addresses to servers that, allegedly, are closer to the core than the customers are. (Pipe dream, I know; which is why so many ISPs have decided to specify 8.8.8.8 and 8.8.4.4, because Google is closer to the core than the ISP is.) I've not personally measured the number of times a look-up could be satisfied from a cache in a production environment; it's been 15 years since I worked in such a job. It would be interesting to see if someone has taken the time to gather those statistics and published them. The main reason for *not* implementing recursion exclusively in CPE is that a recursive lookup is a complex operation, and I have my doubts if BIND or equivalent could be maintained properly in, say, a wireless access point (router) -- how would you update a hints table? From bengelly at gmail.com Sun Apr 1 18:02:51 2018 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Sun, 1 Apr 2018 20:02:51 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: <761822155.464.1522602310249.JavaMail.mhammett@ThunderFuck> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <761822155.464.1522602310249.JavaMail.mhammett@ThunderFuck> Message-ID: <26D4896A-0EF9-4B5B-BC24-6DF3829D1B78@gmail.com> Hi, Maybe this links will help : https://blog.cloudflare.com/dns-resolver-1-1-1-1/ https://blog.cloudflare.com/announcing-1111/ Best regards. > Le 1 avr. 2018 à 19:05, Mike Hammett a écrit : > > Unless you want optimum CDN performance, then your recursive servers belong pushed back in your network until there are no more diverse upstream\peer paths to choose from. > > Yes, I know there's an extension to DNS to help remove this need, but until that's universally supported, you can't abandon the old way. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Stephen Satchell" > To: nanog at nanog.org > Sent: Sunday, April 1, 2018 11:22:10 AM > Subject: Re: Yet another Quadruple DNS? > >> On 04/01/2018 08:18 AM, Matt Hoppes wrote: >> Why not just implement recursive cache severs on end user routers? >> Why does an end user CPE need to query one or two specific DNS >> servers? > Recursive lookups take bandwidth and wall time. The closer you can get > your recursive DNS server to the core of the internet, the faster the > lookups. This is particularly true of mobile and satellite. > > Implementing large caches in that close-to-the-core DNS server can add > another benefit: lookups to common and popular endpoints, such as > Google, would require far less real time to resolve. As the traffic > tides change, the cache would change with it, so flash-in-the-pan sites > would be served from cache, and forgotten in time when said sites drift > back to obscurity. > > (I wonder if the Internet Systems Consortium has considered adding a > cache-hit counter, or even a very coarse heat map (say, four 16-bit > counters cycled every five minutes), to DNS entries, to figure out the > best ones to drop? It would increase the complexity of BIND, but the > benefit for a BIND server serving a largish customer population could be > significant. If I were younger, I might try to model such a change. > Sort by hits, then by time-to-die. Drop the oldest 250 or so entries > when the cache is full. That way, the oldest least-used cache entries > get dropped.) > > ISPs provide to their customers DNS addresses to servers that, > allegedly, are closer to the core than the customers are. (Pipe dream, > I know; which is why so many ISPs have decided to specify 8.8.8.8 and > 8.8.4.4, because Google is closer to the core than the ISP is.) > > I've not personally measured the number of times a look-up could be > satisfied from a cache in a production environment; it's been 15 years > since I worked in such a job. It would be interesting to see if someone > has taken the time to gather those statistics and published them. > > The main reason for *not* implementing recursion exclusively in CPE is > that a recursive lookup is a complex operation, and I have my doubts if > BIND or equivalent could be maintained properly in, say, a wireless > access point (router) -- how would you update a hints table? > From pete at tccmail.ca Sun Apr 1 18:35:28 2018 From: pete at tccmail.ca (Pete Baldwin) Date: Sun, 1 Apr 2018 14:35:28 -0400 Subject: IPv6 addressing plan spreadsheet issue In-Reply-To: <20180401110915.GA96949@vurt.meerval.net> References: <20180401110915.GA96949@vurt.meerval.net> Message-ID: Each file can only contain a single IP address in order to upload to the cloud spreadsheet.  You'll need to split each entry into it's own file and then it should work.  Good luck! ----- Pete Baldwin Tuckersmith Communications (P) 519-565-2400 (C) 519-441-7383 On 04/01/2018 07:09 AM, Job Snijders wrote: > Hi all, > > I made a list of the IPv6 addresses in my home LAN, but have trouble > copy+pasting the list into a cloud spreadsheet. My address list is here: > http://pete.meerval.net/~job/ > > How do other folks do this? Just administrate things in text files? > > Kind regards, > > Job From list-nanog2 at dragon.net Sun Apr 1 20:03:41 2018 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Sun, 01 Apr 2018 14:03:41 -0600 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> Message-ID: <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> mhoppes> Why not just implement recursive cache severs on end user mhoppes> routers? Because who ever saw problems with old, unpatched code or misconfigured CPE routers? And they all use the best possible hardware and are at the end of uncongested, close to the core connections. Not. ;) mhoppes>> Why does an end user CPE need to query one or two specific DNS mhoppes>> servers? Better cache hit rates, professionally run and maintained DNS servers, better connectivity, all resulting in better performance. Yes, geo-ip is a bit off but in most large ISPs, caching recursive servers are very close to the same exit point for consumer connections and the CDN folks keep close track of this. And EDNS client subnet mostly works. And yes, running your own resolver is more private. So is running your own home linux server instead of antique consumer OSs on consumer grade gear and using VPNs. But how many folks can do that? This also ignores the shift if every house in the world did its own recursion. TLD servers and auth servers all over the world would have to massively up their capacity to cope. And you'd wind up consolidating small domain owners onto folks like godaddy, etc. because they couldn't run their own and survive. Large caches are a win for both users and auth DNS servers. None of these are bad or good. They all have tradeoffs. As long as ISPs don't actually disallow running of recursive servers (or do opt-in like some ISPs do with running your own MX), there are folks that will want to run their own. Some will want the ISP resolvers, some will want to use some of the well run public resolvers (like google, opendns, quad9, cloudflare). Choices aren't a bad thing. From list at satchell.net Sun Apr 1 23:49:29 2018 From: list at satchell.net (Stephen Satchell) Date: Sun, 1 Apr 2018 16:49:29 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> Message-ID: <34ca9d53-0b4e-041f-587a-c046d2c2a54f@satchell.net> On 04/01/2018 01:03 PM, Paul Ebersman wrote: > And yes, running your own resolver is more private. So is running your > own home linux server instead of antique consumer OSs on consumer grade > gear and using VPNs. But how many folks can do that? I gave up on Microsoft desktop products more than 15 years ago. Mac products more than 7 years ago. (When Apple refused to fix my broken MacBook screen, that was it for Apple.) Why do I run my own servers, including a mail server? Court subpoenas. When I was working at a Web host company, I got several of these things, complete with gag orders. Mail captures, mostly. One time the Nevada Gaming Commission wanted to take an image of a colo customer's hard drive. The fool they brought was a MSCE, and knew *nothing* about Unix and Linux. Ended up having to do the mirror myself, and sign an affidavit to boot. (Customer was running an on-line poker service without a license, which is unlawful in Nevada.) I want to know when a LEO gets access to my data. From aftab.siddiqui at gmail.com Mon Apr 2 01:57:05 2018 From: aftab.siddiqui at gmail.com (Aftab Siddiqui) Date: Mon, 02 Apr 2018 01:57:05 +0000 Subject: Yet another Quadruple DNS? In-Reply-To: <34ca9d53-0b4e-041f-587a-c046d2c2a54f@satchell.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <34ca9d53-0b4e-041f-587a-c046d2c2a54f@satchell.net> Message-ID: Here is the update from Geoff himself. I guess they didn't want to publish it on April 1st (AEST). https://blog.apnic.net/2018/04/02/apnic-labs-enters-into-a-research-agreement-with-cloudflare/ On Mon, 2 Apr 2018 at 09:51 Stephen Satchell wrote: > On 04/01/2018 01:03 PM, Paul Ebersman wrote: > > And yes, running your own resolver is more private. So is running your > > own home linux server instead of antique consumer OSs on consumer grade > > gear and using VPNs. But how many folks can do that? > > > > I gave up on Microsoft desktop products more than 15 years ago. Mac > products more than 7 years ago. (When Apple refused to fix my broken > MacBook screen, that was it for Apple.) > > Why do I run my own servers, including a mail server? Court subpoenas. > When I was working at a Web host company, I got several of these things, > complete with gag orders. Mail captures, mostly. > > One time the Nevada Gaming Commission wanted to take an image of a colo > customer's hard drive. The fool they brought was a MSCE, and knew > *nothing* about Unix and Linux. Ended up having to do the mirror > myself, and sign an affidavit to boot. (Customer was running an on-line > poker service without a license, which is unlawful in Nevada.) > > I want to know when a LEO gets access to my data. > -- Best Wishes, Aftab A. Siddiqui From baldur.norddahl at gmail.com Mon Apr 2 09:07:07 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 02 Apr 2018 09:07:07 +0000 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <34ca9d53-0b4e-041f-587a-c046d2c2a54f@satchell.net> Message-ID: The problem I see here is the five year research term after which they may or may not revoke the use of the prefix. This is harmful. Such services should be stable. If you are going to let cloudflare run this service, it should be permanent. Regards Baldur Den man. 2. apr. 2018 03.57 skrev Aftab Siddiqui : > Here is the update from Geoff himself. I guess they didn't want to publish > it on April 1st (AEST). > > https://blog.apnic.net/2018/04/02/apnic-labs-enters-into-a-research-agreement-with-cloudflare/ > > On Mon, 2 Apr 2018 at 09:51 Stephen Satchell wrote: > > > On 04/01/2018 01:03 PM, Paul Ebersman wrote: > > > And yes, running your own resolver is more private. So is running your > > > own home linux server instead of antique consumer OSs on consumer grade > > > gear and using VPNs. But how many folks can do that? > > > > > > > > I gave up on Microsoft desktop products more than 15 years ago. Mac > > products more than 7 years ago. (When Apple refused to fix my broken > > MacBook screen, that was it for Apple.) > > > > Why do I run my own servers, including a mail server? Court subpoenas. > > When I was working at a Web host company, I got several of these things, > > complete with gag orders. Mail captures, mostly. > > > > One time the Nevada Gaming Commission wanted to take an image of a colo > > customer's hard drive. The fool they brought was a MSCE, and knew > > *nothing* about Unix and Linux. Ended up having to do the mirror > > myself, and sign an affidavit to boot. (Customer was running an on-line > > poker service without a license, which is unlawful in Nevada.) > > > > I want to know when a LEO gets access to my data. > > > -- > Best Wishes, > > Aftab A. Siddiqui > From Brian at ampr.org Mon Apr 2 09:31:45 2018 From: Brian at ampr.org (Brian Kantor) Date: Mon, 2 Apr 2018 02:31:45 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: References: <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <34ca9d53-0b4e-041f-587a-c046d2c2a54f@satchell.net> Message-ID: <20180402093145.GA25374@meow.BKantor.net> On Mon, Apr 02, 2018 at 09:07:07AM +0000, Baldur Norddahl wrote: > The problem I see here is the five year research term after which they may > or may not revoke the use of the prefix. > > This is harmful. Such services should be stable. If you are going to let > cloudflare run this service, it should be permanent. > > Regards > > Baldur I would maintain that in the context of hi-tech for-profit industry and the Internet, five years is a very close approximation of permanent. - Brian From wwaites at tardis.ed.ac.uk Mon Apr 2 09:32:58 2018 From: wwaites at tardis.ed.ac.uk (William Waites) Date: Mon, 2 Apr 2018 10:32:58 +0100 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <34ca9d53-0b4e-041f-587a-c046d2c2a54f@satchell.net> Message-ID: > On 2 Apr 2018, at 02:57, Aftab Siddiqui wrote: > > Here is the update from Geoff himself. I guess they didn't want to publish > it on April 1st (AEST). > https://blog.apnic.net/2018/04/02/apnic-labs-enters-into-a-research-agreement-with-cloudflare/ The research justification for a RIR to do this seems a little thin. Surely we, as a community already know about what happens when a company operates a public resolver. How will yet another one will tell us more? A more interesting question might be, what happens when we let multiple organisations anycast a well-known public resolver address? There are reasons why it might be a bad idea, but at least it’s slightly novel. William Waites Laboratory for Foundations of Computer Science School of Informatics, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From jcurran at arin.net Mon Apr 2 13:36:16 2018 From: jcurran at arin.net (John Curran) Date: Mon, 2 Apr 2018 13:36:16 +0000 Subject: ARIN 41 - potential changes to Number Resource Policy (Fwd: [arin-announce] Participate in the Public Policy Process at ARIN 41) References: <5AC22D52.2040505@arin.net> Message-ID: NANOGers - ARIN operates the number registry according to community-developed policies, but ultimately such policies are shaped by the folks in this community who choose to participate in their development. There are several significant policy proposals that will be considered at ARIN 41, and I’d recommend taking a moment to review them and either comment on our public policy mail list (arin-ppml at arin.net) or participate in the upcoming meeting (onsite in Miami or remotely, as one prefers) Please see the attached email summarizing potential changes to number resource policy that will be discussed at ARIN 41 two weeks from today. Thanks! /John John Curran President and CEO American Registry for Internet Numbers (ARIN) Begin forwarded message: From: ARIN > Subject: [arin-announce] Participate in the Public Policy Process at ARIN 41 Date: 2 April 2018 at 9:17:06 AM EDT To: > We hope you’ve heard about the upcoming ARIN 41 Public Policy and Members Meeting, taking place 15-18 April in Miami, and that you are planning to participate in this important policy discussion forum. These policies can have a direct impact on your business, so you will undoubtedly want to share your thoughts and contribute to the discussion! The policy discussions at ARIN 41 will include: -Recommended Draft Policy ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation -Recommended Draft Policy ARIN-2017-8: Amend Community Networks -Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers -Recommended Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) -Recommended Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment -Recommended Draft Policy ARIN-2017-13: Remove ARIN Review Requirements for Large IPv4 Reassignments/Reallocations -Draft Policy ARIN-2018-1: Allows Inter-regional ASN Transfers -Draft Policy ARIN-2018-2: Clarification to ISP Initial Allocation and Permit Renumbering All draft policy text is available at: https://www.arin.net/policy/proposals/ You won’t want to miss other agenda highlights like updates on software development, the ARIN fee schedule, and data privacy, plus the latest news from the other RIRs. We will also provide an update on the website redesign project that is currently underway and review the results of our most recent customer satisfaction survey. The full ARIN 41 agenda is available at: https://www.arin.net/ARIN41_agenda We hope to see you in Miami, but if you are unable to make it in person, participating online can be equally rewarding. As a registered remote participant, you'll be able to access the live transcript and webcast on the ARIN website throughout the meeting, submit questions and comments alongside in-person attendees, and raise your virtual hand during straw polls. The webcast and live transcript are available to anyone, but if you want to join in the meeting chat room and add your voice to the discussion and participate in straw polls, you must register at: https://www.arin.net/ARIN41_remote Select "Register” and choose “Remote Participant” as your registration type. We are using Slack for ARIN 41 and all remote participants will be sent an invitation to create an account to access the meeting chat. We strongly encourage you to log in to Slack to test this functionality before the meeting begins so that you can participate fully when the meeting starts. Please note that all times listed on the agenda are Eastern Time. All remote participants are subject to the Remote Participation Acceptable Use Policy (AUP) found at: https://www.arin.net/participate/meetings/remote_aup.html Whether you attend in person or remotely, we look forward to your participation! Please contact us at meetings at arin.net if you have any questions. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From lists-nanog at gadd.is Sun Apr 1 20:59:52 2018 From: lists-nanog at gadd.is (Jeremy L. Gaddis) Date: Sun, 1 Apr 2018 16:59:52 -0400 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE Message-ID: <20180401205952.wnfyvw7nobrc6not@gadd.is> Greetings, If anyone at 7018 wants to pass a message along to the correct folks, please let them know that Cloudflare's new public DNS service (1.1.1.1) is completely unusable for at least some of AT&T's customers. There is apparently a bug with some CPE (including the 5268AC). From behind such CPE, the services at 1.1.1.1 are completely unreachable, whether via (ICMP) ping, DNS, or HTTPS. Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns the following results: ping successful: icmp seq:0, time=2.364 ms ping successful: icmp seq:1, time=1.085 ms ping successful: icmp seq:2, time=1.160 ms ping successful: icmp seq:3, time=1.245 ms ping successful: icmp seq:4, time=0.739 ms RTTs to the CPE's default gateway are, at minimum, ~20 ms. A traceroute (using the same web-based diagnostic tool built-in to the CPE) reports, simply: traceroute 1.1.1.1 with: 64 bytes of data 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms I haven't bothered to report this to AT&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T wants to pass the info along to the appropriate group, it would certainly be appreciated. Thanks, -Jeremy -- Jeremy L. Gaddis "The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to." --John Levine From colinj at gt86car.org.uk Mon Apr 2 09:39:32 2018 From: colinj at gt86car.org.uk (Colin Johnston) Date: Mon, 2 Apr 2018 10:39:32 +0100 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <34ca9d53-0b4e-041f-587a-c046d2c2a54f@satchell.net> Message-ID: <212C2672-9243-4085-88C4-4B2CDBB651C7@gt86car.org.uk> > On 2 Apr 2018, at 10:32, William Waites wrote: > > > >> On 2 Apr 2018, at 02:57, Aftab Siddiqui wrote: >> >> Here is the update from Geoff himself. I guess they didn't want to publish >> it on April 1st (AEST). >> https://blog.apnic.net/2018/04/02/apnic-labs-enters-into-a-research-agreement-with-cloudflare/ > > The research justification for a RIR to do this seems a little thin. > Surely we, as a community already know about what happens when a company > operates a public resolver. How will yet another one will tell us more? > The connectivity aspects could easily be done by using ripe atlas probe queries with dns type. Colin From list-nanog2 at dragon.net Mon Apr 2 14:22:49 2018 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Mon, 02 Apr 2018 08:22:49 -0600 Subject: Yet another Quadruple DNS? In-Reply-To: <34ca9d53-0b4e-041f-587a-c046d2c2a54f@satchell.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <34ca9d53-0b4e-041f-587a-c046d2c2a54f@satchell.net> Message-ID: <20180402142249.48C0F54373D@fafnir.remote.dragon.net> ebersman> And yes, running your own resolver is more private. So is ebersman> running your own home linux server instead of antique consumer ebersman> OSs on consumer grade gear and using VPNs. But how many folks ebersman> can do that? ssatchell> ssatchell> I gave up on Microsoft desktop products more than 15 years ssatchell> ago. Mac products more than 7 years ago. (When Apple ssatchell> refused to fix my broken MacBook screen, that was it for ssatchell> Apple.) Yes and so do I. And probably hundreds of others of the 26+ million homes for just comcast alone. We are not the normal, usual users of the internet. There need to be good, safe, well run alternatives for the other 99.999999....% of the world that aren't us. From darin.steffl at mnwifi.com Mon Apr 2 15:03:14 2018 From: darin.steffl at mnwifi.com (Darin Steffl) Date: Mon, 2 Apr 2018 10:03:14 -0500 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <20180401205952.wnfyvw7nobrc6not@gadd.is> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> Message-ID: I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my router and not any further. When I enter the IP into my browser, it opens the login page for my router. So it appears 1.1.1.1 is used as a loopback in my Calix router. 1.0.0.1 goes to the proper place fine. On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis wrote: > Greetings, > > If anyone at 7018 wants to pass a message along to the correct folks, > please let them know that Cloudflare's new public DNS service (1.1.1.1) > is completely unusable for at least some of AT&T's customers. > > There is apparently a bug with some CPE (including the 5268AC). From > behind such CPE, the services at 1.1.1.1 are completely unreachable, > whether via (ICMP) ping, DNS, or HTTPS. > > Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns > the following results: > > ping successful: icmp seq:0, time=2.364 ms > ping successful: icmp seq:1, time=1.085 ms > ping successful: icmp seq:2, time=1.160 ms > ping successful: icmp seq:3, time=1.245 ms > ping successful: icmp seq:4, time=0.739 ms > > RTTs to the CPE's default gateway are, at minimum, ~20 ms. > > A traceroute (using the same web-based diagnostic tool built-in to the > CPE) reports, simply: > > traceroute 1.1.1.1 with: 64 bytes of data > > 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms > > I haven't bothered to report this to AT&T through the standard customer > support channels (for reasons that should be obvious to anyone who has > ever called AT&T's consumer/residential technical support) but if anyone > at AT&T wants to pass the info along to the appropriate group, it would > certainly be appreciated. > > Thanks, > -Jeremy > > -- > Jeremy L. Gaddis > > > "The total budget at all receivers for solving senders' problems is > $0. If you want them to accept your mail and manage it the way you > want, send it the way the spec says to." --John Levine > > -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi Like us on Facebook From mattlists at rivervalleyinternet.net Mon Apr 2 15:05:30 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Mon, 2 Apr 2018 11:05:30 -0400 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: References: <20180401205952.wnfyvw7nobrc6not@gadd.is> Message-ID: <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this is causing odd issues. > On Apr 2, 2018, at 11:03, Darin Steffl wrote: > > I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my router > and not any further. When I enter the IP into my browser, it opens the > login page for my router. So it appears 1.1.1.1 is used as a loopback in my > Calix router. > > 1.0.0.1 goes to the proper place fine. > > On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis > wrote: > >> Greetings, >> >> If anyone at 7018 wants to pass a message along to the correct folks, >> please let them know that Cloudflare's new public DNS service (1.1.1.1) >> is completely unusable for at least some of AT&T's customers. >> >> There is apparently a bug with some CPE (including the 5268AC). From >> behind such CPE, the services at 1.1.1.1 are completely unreachable, >> whether via (ICMP) ping, DNS, or HTTPS. >> >> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns >> the following results: >> >> ping successful: icmp seq:0, time=2.364 ms >> ping successful: icmp seq:1, time=1.085 ms >> ping successful: icmp seq:2, time=1.160 ms >> ping successful: icmp seq:3, time=1.245 ms >> ping successful: icmp seq:4, time=0.739 ms >> >> RTTs to the CPE's default gateway are, at minimum, ~20 ms. >> >> A traceroute (using the same web-based diagnostic tool built-in to the >> CPE) reports, simply: >> >> traceroute 1.1.1.1 with: 64 bytes of data >> >> 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms >> >> I haven't bothered to report this to AT&T through the standard customer >> support channels (for reasons that should be obvious to anyone who has >> ever called AT&T's consumer/residential technical support) but if anyone >> at AT&T wants to pass the info along to the appropriate group, it would >> certainly be appreciated. >> >> Thanks, >> -Jeremy >> >> -- >> Jeremy L. Gaddis >> >> >> "The total budget at all receivers for solving senders' problems is >> $0. If you want them to accept your mail and manage it the way you >> want, send it the way the spec says to." --John Levine >> >> > > > -- > Darin Steffl > Minnesota WiFi > www.mnwifi.com > 507-634-WiFi > Like us on Facebook > From cma at cmadams.net Mon Apr 2 15:08:21 2018 From: cma at cmadams.net (Chris Adams) Date: Mon, 2 Apr 2018 10:08:21 -0500 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> Message-ID: <20180402150821.GA24937@cmadams.net> Once upon a time, Matt Hoppes said: > Seeing as how 1.1.1.1 isn’t suppose to be routed [citation needed] -- Chris Adams From CGross at ninestarconnect.com Mon Apr 2 15:08:38 2018 From: CGross at ninestarconnect.com (Chris Gross) Date: Mon, 2 Apr 2018 15:08:38 +0000 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: References: <20180401205952.wnfyvw7nobrc6not@gadd.is> Message-ID: That sounds like a provider problem with their configuration most likely. I run hundreds of 844E, 844Gs and have one at my house even, and it continues out fine for 1.1.1.1 when I was testing over the weekend with our config. Chris Gross IP Services Supervisor -----Original Message----- From: NANOG On Behalf Of Darin Steffl Sent: Monday, April 02, 2018 11:03 AM To: North American Network Operators' Group Subject: Re: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my router and not any further. When I enter the IP into my browser, it opens the login page for my router. So it appears 1.1.1.1 is used as a loopback in my Calix router. 1.0.0.1 goes to the proper place fine. On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis wrote: > Greetings, > > If anyone at 7018 wants to pass a message along to the correct folks, > please let them know that Cloudflare's new public DNS service > (1.1.1.1) is completely unusable for at least some of AT&T's customers. > > There is apparently a bug with some CPE (including the 5268AC). From > behind such CPE, the services at 1.1.1.1 are completely unreachable, > whether via (ICMP) ping, DNS, or HTTPS. > > Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns > the following results: > > ping successful: icmp seq:0, time=2.364 ms > ping successful: icmp seq:1, time=1.085 ms > ping successful: icmp seq:2, time=1.160 ms > ping successful: icmp seq:3, time=1.245 ms > ping successful: icmp seq:4, time=0.739 ms > > RTTs to the CPE's default gateway are, at minimum, ~20 ms. > > A traceroute (using the same web-based diagnostic tool built-in to the > CPE) reports, simply: > > traceroute 1.1.1.1 with: 64 bytes of data > > 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms > > I haven't bothered to report this to AT&T through the standard > customer support channels (for reasons that should be obvious to > anyone who has ever called AT&T's consumer/residential technical > support) but if anyone at AT&T wants to pass the info along to the > appropriate group, it would certainly be appreciated. > > Thanks, > -Jeremy > > -- > Jeremy L. Gaddis > > > "The total budget at all receivers for solving senders' problems is > $0. If you want them to accept your mail and manage it the way you > want, send it the way the spec says to." --John Levine > > -- Darin Steffl Minnesota WiFi https://na01.safelinks.protection.outlook.com/?url=www.mnwifi.com&data=02%7C01%7C%7C44b0d324ba284c19f9b108d598ab2d27%7C453303889ca9424bbe1a29721272041d%7C1%7C0%7C636582783328080128&sdata=Uwca5B1Fg0YSPmAwLRM63MGE%2BSBD8bTN%2FoGcVCvpUyc%3D&reserved=0 507-634-WiFi Like us on Facebook From lists at mtin.net Mon Apr 2 15:12:01 2018 From: lists at mtin.net (Justin Wilson) Date: Mon, 2 Apr 2018 11:12:01 -0400 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> Message-ID: <00EA4577-F9CF-47D5-8009-B7AB9FF1F36A@mtin.net> 1.0.0.0/8 was assigned to APNIC in 2010. Those who used it as a placeholder were doing it wrong. It is valid IP space. It just was not assigned until 2010. Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com > On Apr 2, 2018, at 11:05 AM, Matt Hoppes wrote: > > Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this is causing odd issues. > >> On Apr 2, 2018, at 11:03, Darin Steffl wrote: >> >> I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my router >> and not any further. When I enter the IP into my browser, it opens the >> login page for my router. So it appears 1.1.1.1 is used as a loopback in my >> Calix router. >> >> 1.0.0.1 goes to the proper place fine. >> >> On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis >> wrote: >> >>> Greetings, >>> >>> If anyone at 7018 wants to pass a message along to the correct folks, >>> please let them know that Cloudflare's new public DNS service (1.1.1.1) >>> is completely unusable for at least some of AT&T's customers. >>> >>> There is apparently a bug with some CPE (including the 5268AC). From >>> behind such CPE, the services at 1.1.1.1 are completely unreachable, >>> whether via (ICMP) ping, DNS, or HTTPS. >>> >>> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns >>> the following results: >>> >>> ping successful: icmp seq:0, time=2.364 ms >>> ping successful: icmp seq:1, time=1.085 ms >>> ping successful: icmp seq:2, time=1.160 ms >>> ping successful: icmp seq:3, time=1.245 ms >>> ping successful: icmp seq:4, time=0.739 ms >>> >>> RTTs to the CPE's default gateway are, at minimum, ~20 ms. >>> >>> A traceroute (using the same web-based diagnostic tool built-in to the >>> CPE) reports, simply: >>> >>> traceroute 1.1.1.1 with: 64 bytes of data >>> >>> 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms >>> >>> I haven't bothered to report this to AT&T through the standard customer >>> support channels (for reasons that should be obvious to anyone who has >>> ever called AT&T's consumer/residential technical support) but if anyone >>> at AT&T wants to pass the info along to the appropriate group, it would >>> certainly be appreciated. >>> >>> Thanks, >>> -Jeremy >>> >>> -- >>> Jeremy L. Gaddis >>> >>> >>> "The total budget at all receivers for solving senders' problems is >>> $0. If you want them to accept your mail and manage it the way you >>> want, send it the way the spec says to." --John Levine >>> >>> >> >> >> -- >> Darin Steffl >> Minnesota WiFi >> www.mnwifi.com >> 507-634-WiFi >> Like us on Facebook >> > From jason.w.kuehl at gmail.com Mon Apr 2 15:16:17 2018 From: jason.w.kuehl at gmail.com (Jason Kuehl) Date: Mon, 2 Apr 2018 11:16:17 -0400 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> Message-ID: Just like "S3 dependency check day" Thus begins "National 1.1.1.1 change week" I've already around a few peaces of equipment sets with 1.1.1.1 On Mon, Apr 2, 2018 at 11:05 AM, Matt Hoppes < mattlists at rivervalleyinternet.net> wrote: > Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this is > causing odd issues. > > > On Apr 2, 2018, at 11:03, Darin Steffl wrote: > > > > I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my > router > > and not any further. When I enter the IP into my browser, it opens the > > login page for my router. So it appears 1.1.1.1 is used as a loopback in > my > > Calix router. > > > > 1.0.0.1 goes to the proper place fine. > > > > On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis > > wrote: > > > >> Greetings, > >> > >> If anyone at 7018 wants to pass a message along to the correct folks, > >> please let them know that Cloudflare's new public DNS service (1.1.1.1) > >> is completely unusable for at least some of AT&T's customers. > >> > >> There is apparently a bug with some CPE (including the 5268AC). From > >> behind such CPE, the services at 1.1.1.1 are completely unreachable, > >> whether via (ICMP) ping, DNS, or HTTPS. > >> > >> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns > >> the following results: > >> > >> ping successful: icmp seq:0, time=2.364 ms > >> ping successful: icmp seq:1, time=1.085 ms > >> ping successful: icmp seq:2, time=1.160 ms > >> ping successful: icmp seq:3, time=1.245 ms > >> ping successful: icmp seq:4, time=0.739 ms > >> > >> RTTs to the CPE's default gateway are, at minimum, ~20 ms. > >> > >> A traceroute (using the same web-based diagnostic tool built-in to the > >> CPE) reports, simply: > >> > >> traceroute 1.1.1.1 with: 64 bytes of data > >> > >> 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms > >> > >> I haven't bothered to report this to AT&T through the standard customer > >> support channels (for reasons that should be obvious to anyone who has > >> ever called AT&T's consumer/residential technical support) but if anyone > >> at AT&T wants to pass the info along to the appropriate group, it would > >> certainly be appreciated. > >> > >> Thanks, > >> -Jeremy > >> > >> -- > >> Jeremy L. Gaddis > >> > >> > >> "The total budget at all receivers for solving senders' problems is > >> $0. If you want them to accept your mail and manage it the way you > >> want, send it the way the spec says to." --John Levine > >> > >> > > > > > > -- > > Darin Steffl > > Minnesota WiFi > > www.mnwifi.com > > 507-634-WiFi > > Like us on Facebook > > > -- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.kuehl at gmail.com From johnl at iecc.com Mon Apr 2 15:17:47 2018 From: johnl at iecc.com (John Levine) Date: 2 Apr 2018 11:17:47 -0400 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <20180402150821.GA24937@cmadams.net> Message-ID: <20180402151748.222E423FB428@ary.qy> In article <20180402150821.GA24937 at cmadams.net> you write: >Once upon a time, Matt Hoppes said: >> Seeing as how 1.1.1.1 isn’t suppose to be routed > >[citation needed] Look at the WHOIS info -- 1.1.1.0/24 is assigned to APNIC Research, and it says remarks: ++++++++++++++++++ remarks: + Address blocks listed with this contact remarks: + are withheld from general use and are remarks: + only routed briefly for passive testing. remarks: + remarks: + If you are receiving unwanted traffic remarks: + it is almost certainly spoofed source remarks: + or hijacked address usage. There's a comment at the top saying: descr: APNIC and Cloudflare DNS Resolver project descr: Routed globally by AS13335/Cloudflare descr: Research prefix for APNIC Labs So it's routed deliberately but it sure looks like an experiment. There's way too much equipment that treats 1.1.1.1 as magic for it to work reliably. Captive portals tend to use that address for the host you contact to log out. R's, John From jason.w.kuehl at gmail.com Mon Apr 2 15:23:40 2018 From: jason.w.kuehl at gmail.com (Jason Kuehl) Date: Mon, 2 Apr 2018 11:23:40 -0400 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <00EA4577-F9CF-47D5-8009-B7AB9FF1F36A@mtin.net> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <00EA4577-F9CF-47D5-8009-B7AB9FF1F36A@mtin.net> Message-ID: Not saying you're wrong. But people did it for whatever reason. On Mon, Apr 2, 2018 at 11:12 AM, Justin Wilson wrote: > 1.0.0.0/8 was assigned to APNIC in 2010. Those who used it as a > placeholder were doing it wrong. It is valid IP space. It just was not > assigned until 2010. > > > Justin Wilson > j2sw at mtin.net > > www.mtin.net > www.midwest-ix.com > > > On Apr 2, 2018, at 11:05 AM, Matt Hoppes rivervalleyinternet.net> wrote: > > > > Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this > is causing odd issues. > > > >> On Apr 2, 2018, at 11:03, Darin Steffl wrote: > >> > >> I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my > router > >> and not any further. When I enter the IP into my browser, it opens the > >> login page for my router. So it appears 1.1.1.1 is used as a loopback > in my > >> Calix router. > >> > >> 1.0.0.1 goes to the proper place fine. > >> > >> On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis > >> wrote: > >> > >>> Greetings, > >>> > >>> If anyone at 7018 wants to pass a message along to the correct folks, > >>> please let them know that Cloudflare's new public DNS service (1.1.1.1) > >>> is completely unusable for at least some of AT&T's customers. > >>> > >>> There is apparently a bug with some CPE (including the 5268AC). From > >>> behind such CPE, the services at 1.1.1.1 are completely unreachable, > >>> whether via (ICMP) ping, DNS, or HTTPS. > >>> > >>> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns > >>> the following results: > >>> > >>> ping successful: icmp seq:0, time=2.364 ms > >>> ping successful: icmp seq:1, time=1.085 ms > >>> ping successful: icmp seq:2, time=1.160 ms > >>> ping successful: icmp seq:3, time=1.245 ms > >>> ping successful: icmp seq:4, time=0.739 ms > >>> > >>> RTTs to the CPE's default gateway are, at minimum, ~20 ms. > >>> > >>> A traceroute (using the same web-based diagnostic tool built-in to the > >>> CPE) reports, simply: > >>> > >>> traceroute 1.1.1.1 with: 64 bytes of data > >>> > >>> 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms > >>> > >>> I haven't bothered to report this to AT&T through the standard customer > >>> support channels (for reasons that should be obvious to anyone who has > >>> ever called AT&T's consumer/residential technical support) but if > anyone > >>> at AT&T wants to pass the info along to the appropriate group, it would > >>> certainly be appreciated. > >>> > >>> Thanks, > >>> -Jeremy > >>> > >>> -- > >>> Jeremy L. Gaddis > >>> > >>> > >>> "The total budget at all receivers for solving senders' problems is > >>> $0. If you want them to accept your mail and manage it the way you > >>> want, send it the way the spec says to." --John Levine > >>> > >>> > >> > >> > >> -- > >> Darin Steffl > >> Minnesota WiFi > >> www.mnwifi.com > >> 507-634-WiFi > >> Like us on Facebook > >> > > > > -- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.kuehl at gmail.com From marty at cloudflare.com Mon Apr 2 15:26:13 2018 From: marty at cloudflare.com (Marty Strong) Date: Mon, 2 Apr 2018 16:26:13 +0100 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> Message-ID: <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> So far we know about a few CPEs which answer for 1.1.1.1 themselves: - Pace 5268 - Calix GigaCenter - Various Cisco Wifi access points If you know of others please send them my way so we can investigate. Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 2 Apr 2018, at 16:16, Jason Kuehl wrote: > > Just like "S3 dependency check day" Thus begins "National 1.1.1.1 change > week" I've already around a few peaces of equipment sets with 1.1.1.1 > > On Mon, Apr 2, 2018 at 11:05 AM, Matt Hoppes < > mattlists at rivervalleyinternet.net> wrote: > >> Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this is >> causing odd issues. >> >>> On Apr 2, 2018, at 11:03, Darin Steffl wrote: >>> >>> I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my >> router >>> and not any further. When I enter the IP into my browser, it opens the >>> login page for my router. So it appears 1.1.1.1 is used as a loopback in >> my >>> Calix router. >>> >>> 1.0.0.1 goes to the proper place fine. >>> >>> On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis >>> wrote: >>> >>>> Greetings, >>>> >>>> If anyone at 7018 wants to pass a message along to the correct folks, >>>> please let them know that Cloudflare's new public DNS service (1.1.1.1) >>>> is completely unusable for at least some of AT&T's customers. >>>> >>>> There is apparently a bug with some CPE (including the 5268AC). From >>>> behind such CPE, the services at 1.1.1.1 are completely unreachable, >>>> whether via (ICMP) ping, DNS, or HTTPS. >>>> >>>> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns >>>> the following results: >>>> >>>> ping successful: icmp seq:0, time=2.364 ms >>>> ping successful: icmp seq:1, time=1.085 ms >>>> ping successful: icmp seq:2, time=1.160 ms >>>> ping successful: icmp seq:3, time=1.245 ms >>>> ping successful: icmp seq:4, time=0.739 ms >>>> >>>> RTTs to the CPE's default gateway are, at minimum, ~20 ms. >>>> >>>> A traceroute (using the same web-based diagnostic tool built-in to the >>>> CPE) reports, simply: >>>> >>>> traceroute 1.1.1.1 with: 64 bytes of data >>>> >>>> 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms >>>> >>>> I haven't bothered to report this to AT&T through the standard customer >>>> support channels (for reasons that should be obvious to anyone who has >>>> ever called AT&T's consumer/residential technical support) but if anyone >>>> at AT&T wants to pass the info along to the appropriate group, it would >>>> certainly be appreciated. >>>> >>>> Thanks, >>>> -Jeremy >>>> >>>> -- >>>> Jeremy L. Gaddis >>>> >>>> >>>> "The total budget at all receivers for solving senders' problems is >>>> $0. If you want them to accept your mail and manage it the way you >>>> want, send it the way the spec says to." --John Levine >>>> >>>> >>> >>> >>> -- >>> Darin Steffl >>> Minnesota WiFi >>> www.mnwifi.com >>> 507-634-WiFi >>> Like us on Facebook >>> >> > > > > -- > Sincerely, > > Jason W Kuehl > Cell 920-419-8983 > jason.w.kuehl at gmail.com From mattlists at rivervalleyinternet.net Mon Apr 2 15:29:35 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Mon, 2 Apr 2018 11:29:35 -0400 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <00EA4577-F9CF-47D5-8009-B7AB9FF1F36A@mtin.net> Message-ID: <199E875D-BF1A-44BC-A420-2B1ADC7C8FD4@rivervalleyinternet.net> “Routed briefly for passive testing” sounds to me like “black hole it because legitimate traffic shouldn’t be coming to your network from it” > On Apr 2, 2018, at 11:23, Jason Kuehl wrote: > > Not saying you're wrong. But people did it for whatever reason. > >> On Mon, Apr 2, 2018 at 11:12 AM, Justin Wilson wrote: >> >> 1.0.0.0/8 was assigned to APNIC in 2010. Those who used it as a >> placeholder were doing it wrong. It is valid IP space. It just was not >> assigned until 2010. >> >> >> Justin Wilson >> j2sw at mtin.net >> >> www.mtin.net >> www.midwest-ix.com >> >>> On Apr 2, 2018, at 11:05 AM, Matt Hoppes > rivervalleyinternet.net> wrote: >>> >>> Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this >> is causing odd issues. >>> >>>> On Apr 2, 2018, at 11:03, Darin Steffl wrote: >>>> >>>> I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my >> router >>>> and not any further. When I enter the IP into my browser, it opens the >>>> login page for my router. So it appears 1.1.1.1 is used as a loopback >> in my >>>> Calix router. >>>> >>>> 1.0.0.1 goes to the proper place fine. >>>> >>>> On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis >>>> wrote: >>>> >>>>> Greetings, >>>>> >>>>> If anyone at 7018 wants to pass a message along to the correct folks, >>>>> please let them know that Cloudflare's new public DNS service (1.1.1.1) >>>>> is completely unusable for at least some of AT&T's customers. >>>>> >>>>> There is apparently a bug with some CPE (including the 5268AC). From >>>>> behind such CPE, the services at 1.1.1.1 are completely unreachable, >>>>> whether via (ICMP) ping, DNS, or HTTPS. >>>>> >>>>> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns >>>>> the following results: >>>>> >>>>> ping successful: icmp seq:0, time=2.364 ms >>>>> ping successful: icmp seq:1, time=1.085 ms >>>>> ping successful: icmp seq:2, time=1.160 ms >>>>> ping successful: icmp seq:3, time=1.245 ms >>>>> ping successful: icmp seq:4, time=0.739 ms >>>>> >>>>> RTTs to the CPE's default gateway are, at minimum, ~20 ms. >>>>> >>>>> A traceroute (using the same web-based diagnostic tool built-in to the >>>>> CPE) reports, simply: >>>>> >>>>> traceroute 1.1.1.1 with: 64 bytes of data >>>>> >>>>> 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms >>>>> >>>>> I haven't bothered to report this to AT&T through the standard customer >>>>> support channels (for reasons that should be obvious to anyone who has >>>>> ever called AT&T's consumer/residential technical support) but if >> anyone >>>>> at AT&T wants to pass the info along to the appropriate group, it would >>>>> certainly be appreciated. >>>>> >>>>> Thanks, >>>>> -Jeremy >>>>> >>>>> -- >>>>> Jeremy L. Gaddis >>>>> >>>>> >>>>> "The total budget at all receivers for solving senders' problems is >>>>> $0. If you want them to accept your mail and manage it the way you >>>>> want, send it the way the spec says to." --John Levine >>>>> >>>>> >>>> >>>> >>>> -- >>>> Darin Steffl >>>> Minnesota WiFi >>>> www.mnwifi.com >>>> 507-634-WiFi >>>> Like us on Facebook >>>> >>> >> >> > > > -- > Sincerely, > > Jason W Kuehl > Cell 920-419-8983 > jason.w.kuehl at gmail.com From simon at slimey.org Mon Apr 2 15:35:37 2018 From: simon at slimey.org (Simon Lockhart) Date: Mon, 2 Apr 2018 16:35:37 +0100 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <20180402151748.222E423FB428@ary.qy> References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> Message-ID: <20180402153537.GS31411@dilbert.slimey.org> On Mon Apr 02, 2018 at 11:17:47AM -0400, John Levine wrote: > So it's routed deliberately but it sure looks like an experiment. > There's way too much equipment that treats 1.1.1.1 as magic for it to > work reliably. Captive portals tend to use that address for the host > you contact to log out. Quite. This looks like a willy-waving exercise by Cloudflare coming up with the lowest quad-digit IP. They must have known that this would cause routing issues, and now suddenly it's our responsibility to make significant changes to live infrastructures just so they can continue to look clever with the IP address. Simon -- Simon Lockhart | * Server Co-location * ADSL * Domain Registration * Director | * Domain & Web Hosting * Connectivity * Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From sethm at rollernet.us Mon Apr 2 15:39:30 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 2 Apr 2018 08:39:30 -0700 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <20180402153537.GS31411@dilbert.slimey.org> References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> Message-ID: <645cb48e-437f-e036-75f0-c4416c8b9594@rollernet.us> On 4/2/18 8:35 AM, Simon Lockhart wrote: > > This looks like a willy-waving exercise by Cloudflare coming up with the lowest > quad-digit IP. They must have known that this would cause routing issues, and > now suddenly it's our responsibility to make significant changes to live > infrastructures just so they can continue to look clever with the IP address. To be fair, nobody should have been using 1/8 for anything. From nop at imap.cc Mon Apr 2 15:48:53 2018 From: nop at imap.cc (nop at imap.cc) Date: Mon, 02 Apr 2018 08:48:53 -0700 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <20180402153537.GS31411@dilbert.slimey.org> References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> Message-ID: <1522684133.3883389.1323755800.51DAE431@webmail.messagingengine.com> On Mon, Apr 2, 2018, at 8:35 AM, Simon Lockhart wrote: > quad-digit IP. They must have known that this would cause routing issues, and > now suddenly it's our responsibility to make significant changes to live > infrastructures just so they can continue to look clever with the IP address. In this case, one only broke their own infrastructure by doing bad things or "being clever" by misusing space that isn't theirs in unintended ways; people doing things correctly would not have this issue... From johnl at iecc.com Mon Apr 2 16:04:55 2018 From: johnl at iecc.com (John R. Levine) Date: 2 Apr 2018 12:04:55 -0400 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <20180402153537.GS31411@dilbert.slimey.org> References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> Message-ID: > This looks like a willy-waving exercise by Cloudflare coming up with the lowest > quad-digit IP. They must have known that this would cause routing issues, and > now suddenly it's our responsibility to make significant changes to live > infrastructures just so they can continue to look clever with the IP address. Perhaps we can ask APNIC what the experiment is. They surely know that 1.1.1.1 is messed up so I doubt that Matt expects every coffee shop in the world to bend to his will. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From james.cutler at consultant.com Mon Apr 2 16:07:32 2018 From: james.cutler at consultant.com (James R Cutler) Date: Mon, 2 Apr 2018 12:07:32 -0400 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <20180402153537.GS31411@dilbert.slimey.org> References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> Message-ID: > On Apr 2, 2018, at 11:35 AM, Simon Lockhart wrote: > > … > This looks like a willy-waving exercise by Cloudflare coming up with the lowest > quad-digit IP. They must have known that this would cause routing issues, and > now suddenly it's our responsibility to make significant changes to live > infrastructures just so they can continue to look clever with the IP address. > I am very impressed at Cloudflare’s forward thinking to force investing a significant amount of IPv4 infrastructure. This will obviously become even more important in the future as IPv6 withers away and is replaced by IPv4. And, I repeat, please tell me how many end users know about or care about DNS, even after reading snake oil advertisements. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu From lists at mtin.net Mon Apr 2 16:26:50 2018 From: lists at mtin.net (Justin Wilson) Date: Mon, 2 Apr 2018 12:26:50 -0400 Subject: IPv6 addressing plan spreadsheet issue In-Reply-To: References: <20180401110915.GA96949@vurt.meerval.net> Message-ID: We use PHPIPAM for our clients If given the choice Netflix traffic prefers IPV6. That is the “killer app” for me. Justin Wilson j2sw at mtin.net www.mtin.net www.midwest-ix.com > On Apr 1, 2018, at 2:35 PM, Pete Baldwin wrote: > > Each file can only contain a single IP address in order to upload to the cloud spreadsheet. You'll need to split each entry into it's own file and then it should work. Good luck! > > ----- > > Pete Baldwin > Tuckersmith Communications > (P) 519-565-2400 > (C) 519-441-7383 > > On 04/01/2018 07:09 AM, Job Snijders wrote: >> Hi all, >> >> I made a list of the IPv6 addresses in my home LAN, but have trouble >> copy+pasting the list into a cloud spreadsheet. My address list is here: >> http://pete.meerval.net/~job/ >> >> How do other folks do this? Just administrate things in text files? >> >> Kind regards, >> >> Job > From hank at efes.iucc.ac.il Mon Apr 2 16:34:18 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 2 Apr 2018 19:34:18 +0300 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <20180402153537.GS31411@dilbert.slimey.org> References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> Message-ID: On 02/04/2018 18:35, Simon Lockhart wrote: > On Mon Apr 02, 2018 at 11:17:47AM -0400, John Levine wrote: >> So it's routed deliberately but it sure looks like an experiment. >> There's way too much equipment that treats 1.1.1.1 as magic for it to >> work reliably. Captive portals tend to use that address for the host >> you contact to log out. > Quite. > > This looks like a willy-waving exercise by Cloudflare coming up with the lowest > quad-digit IP. They must have known that this would cause routing issues, and > now suddenly it's our responsibility to make significant changes to live > infrastructures just so they can continue to look clever with the IP address. > > Simon Perhaps they are running all  this to shake out exactly these type of issues?  I think that is exactly why APNIC research is called for. -Hank From fhr at fhrnet.eu Mon Apr 2 16:49:40 2018 From: fhr at fhrnet.eu (Filip Hruska) Date: Mon, 2 Apr 2018 16:49:40 +0000 Subject: IPv6 addressing plan spreadsheet issue In-Reply-To: <20180401110915.GA96949@vurt.meerval.net> References: <20180401110915.GA96949@vurt.meerval.net> Message-ID: <010201628743a83d-79c1ae4a-e3a0-46dc-92e5-23b91ac14200-000000@eu-west-1.amazonses.com> Well played. How did you actually create the .txt file? Is the filesize spoofed in some way? 8191PB is a lot of storage. -- Filip Hruska Linux System Administrator Dne 4/1/18 v 13:09 Job Snijders napsal(a): > Hi all, > > I made a list of the IPv6 addresses in my home LAN, but have trouble > copy+pasting the list into a cloud spreadsheet. My address list is here: > http://pete.meerval.net/~job/ > > How do other folks do this? Just administrate things in text files? > > Kind regards, > > Job > From nick at foobar.org Mon Apr 2 16:58:19 2018 From: nick at foobar.org (Nick Hilliard) Date: Mon, 02 Apr 2018 17:58:19 +0100 Subject: IPv6 addressing plan spreadsheet issue In-Reply-To: <010201628743a83d-79c1ae4a-e3a0-46dc-92e5-23b91ac14200-000000@eu-west-1.amazonses.com> References: <20180401110915.GA96949@vurt.meerval.net> <010201628743a83d-79c1ae4a-e3a0-46dc-92e5-23b91ac14200-000000@eu-west-1.amazonses.com> Message-ID: <5AC2612B.3010109@foobar.org> Filip Hruska wrote: > How did you actually create the .txt file? Is the filesize spoofed in > some way? > 8191PB is a lot of storage. Probably a giant RAID in the attic. Disk space is very cheap these days. Anyway, txt files are old hat for ip address management. Job should be using Excel like all the professional shops, although I do admit that it runs a bit slow on my home laptop after 3.2*10^38 entries. This is a real drag if you have a lot of hosts located at the top end of your ipv6 address range. Nick From tarko at lanparty.ee Mon Apr 2 16:59:35 2018 From: tarko at lanparty.ee (Tarko Tikan) Date: Mon, 2 Apr 2018 19:59:35 +0300 Subject: IPv6 addressing plan spreadsheet issue In-Reply-To: <010201628743a83d-79c1ae4a-e3a0-46dc-92e5-23b91ac14200-000000@eu-west-1.amazonses.com> References: <20180401110915.GA96949@vurt.meerval.net> <010201628743a83d-79c1ae4a-e3a0-46dc-92e5-23b91ac14200-000000@eu-west-1.amazonses.com> Message-ID: hey, > How did you actually create the .txt file? Is the filesize spoofed in > some way? > 8191PB is a lot of storage. Probably just handcrafted index.html with fake file size and CGI script that outputs the actual prefixes on-demand? -- tarko From fhr at fhrnet.eu Mon Apr 2 17:10:49 2018 From: fhr at fhrnet.eu (Filip Hruska) Date: Mon, 2 Apr 2018 17:10:49 +0000 Subject: IPv6 addressing plan spreadsheet issue In-Reply-To: References: <20180401110915.GA96949@vurt.meerval.net> <010201628743a83d-79c1ae4a-e3a0-46dc-92e5-23b91ac14200-000000@eu-west-1.amazonses.com> Message-ID: <01020162875702e1-21d33a7d-8642-45db-a75d-82d363b6ba7b-000000@eu-west-1.amazonses.com> Hi, I actually got that value from curl (on Mac) so who knows. It's certainly possible that it's generated on-the-fly and curl just shows garbage info. Regards, -- Filip Hruska Linux System Administrator Dne 4/2/18 v 18:59 Tarko Tikan napsal(a): > hey, > >> How did you actually create the .txt file? Is the filesize spoofed in >> some way? >> 8191PB is a lot of storage. > > Probably just handcrafted index.html with fake file size and CGI > script that outputs the actual prefixes on-demand? > From alan.buxey at gmail.com Mon Apr 2 17:11:34 2018 From: alan.buxey at gmail.com (Alan Buxey) Date: Mon, 2 Apr 2018 18:11:34 +0100 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> Message-ID: thats probably a key part of the experiment - to find locations and systems where 1.1.1.1 is trashed. it should be routable and its about time that vendors stopped messing around in that space - hopefully this is one of the sticks that prods people to start to behave - at which point 1.0.0.0/8 will regain value too and can be used by APNIC for other requirements. as for those berating addresses used for experiments - there are MANY networking experiments going on out there , the Internet itself derives from one big ongoing experiment...and some would even say it IS still an experiment. alan On 2 April 2018 at 17:04, John R. Levine wrote: >> This looks like a willy-waving exercise by Cloudflare coming up with the >> lowest >> quad-digit IP. They must have known that this would cause routing issues, >> and >> now suddenly it's our responsibility to make significant changes to live >> infrastructures just so they can continue to look clever with the IP >> address. > > > Perhaps we can ask APNIC what the experiment is. They surely know that > 1.1.1.1 is messed up so I doubt that Matt expects every coffee shop in the > world to bend to his will. > > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly From johnl at iecc.com Mon Apr 2 17:18:17 2018 From: johnl at iecc.com (John Levine) Date: 2 Apr 2018 13:18:17 -0400 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> Message-ID: <20180402171818.7156323FDEAD@ary.qy> In article <7DB5FAC7-972A-4EB6-89D9-B305A723334F at cloudflare.com> you write: >If you know of others please send them my way so we can investigate. A lot of hotel and coffee shop captive portals use it for the login and logout screens. Don't know what the underlying software is, but wander around London and hop on the wifi at coffee shops and hotels and you'll run into it soon enough. R's, John From drc at virtualized.org Mon Apr 2 17:49:53 2018 From: drc at virtualized.org (David Conrad) Date: Mon, 2 Apr 2018 13:49:53 -0400 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <645cb48e-437f-e036-75f0-c4416c8b9594@rollernet.us> References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> <645cb48e-437f-e036-75f0-c4416c8b9594@rollernet.us> Message-ID: Wait. What? Why do you think 1/8 shouldn’t be used for anything? Regards, -drc -- > On Monday, Apr 02, 2018 at 11:40 AM, Seth Mattinen wrote: > On 4/2/18 8:35 AM, Simon Lockhart wrote: > > > > This looks like a willy-waving exercise by Cloudflare coming up with the lowest > > quad-digit IP. They must have known that this would cause routing issues, and > > now suddenly it's our responsibility to make significant changes to live > > infrastructures just so they can continue to look clever with the IP address. > > > To be fair, nobody should have been using 1/8 for anything. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 695 bytes Desc: not available URL: From sethm at rollernet.us Mon Apr 2 17:56:14 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 2 Apr 2018 10:56:14 -0700 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> <645cb48e-437f-e036-75f0-c4416c8b9594@rollernet.us> Message-ID: On 4/2/18 10:49, David Conrad wrote: > Wait. What? > > Why do you think 1/8 shouldn’t be used for anything? > I didn't say that. In case this is a non-native English issue, "nobody should have been using" is past tense, which is to say everyone squatting on 1/8 space for their own purposes because it was "unassigned" shouldn't have been doing that. ~Seth From rubensk at gmail.com Mon Apr 2 18:24:28 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 2 Apr 2018 15:24:28 -0300 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> Message-ID: D-Link DMG-6661 as well. Rubens On Mon, Apr 2, 2018 at 12:26 PM, Marty Strong via NANOG wrote: > So far we know about a few CPEs which answer for 1.1.1.1 themselves: > > - Pace 5268 > - Calix GigaCenter > - Various Cisco Wifi access points > > If you know of others please send them my way so we can investigate. > > Regards, > Marty Strong > -------------------------------------- > Cloudflare - AS13335 > Network Engineer > marty at cloudflare.com > +44 7584 906 055 > smartflare (Skype) > > https://www.peeringdb.com/asn/13335 > > > On 2 Apr 2018, at 16:16, Jason Kuehl wrote: > > > > Just like "S3 dependency check day" Thus begins "National 1.1.1.1 change > > week" I've already around a few peaces of equipment sets with 1.1.1.1 > > > > On Mon, Apr 2, 2018 at 11:05 AM, Matt Hoppes < > > mattlists at rivervalleyinternet.net> wrote: > > > >> Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this > is > >> causing odd issues. > >> > >>> On Apr 2, 2018, at 11:03, Darin Steffl > wrote: > >>> > >>> I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my > >> router > >>> and not any further. When I enter the IP into my browser, it opens the > >>> login page for my router. So it appears 1.1.1.1 is used as a loopback > in > >> my > >>> Calix router. > >>> > >>> 1.0.0.1 goes to the proper place fine. > >>> > >>> On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis > >>> wrote: > >>> > >>>> Greetings, > >>>> > >>>> If anyone at 7018 wants to pass a message along to the correct folks, > >>>> please let them know that Cloudflare's new public DNS service > (1.1.1.1) > >>>> is completely unusable for at least some of AT&T's customers. > >>>> > >>>> There is apparently a bug with some CPE (including the 5268AC). From > >>>> behind such CPE, the services at 1.1.1.1 are completely unreachable, > >>>> whether via (ICMP) ping, DNS, or HTTPS. > >>>> > >>>> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns > >>>> the following results: > >>>> > >>>> ping successful: icmp seq:0, time=2.364 ms > >>>> ping successful: icmp seq:1, time=1.085 ms > >>>> ping successful: icmp seq:2, time=1.160 ms > >>>> ping successful: icmp seq:3, time=1.245 ms > >>>> ping successful: icmp seq:4, time=0.739 ms > >>>> > >>>> RTTs to the CPE's default gateway are, at minimum, ~20 ms. > >>>> > >>>> A traceroute (using the same web-based diagnostic tool built-in to the > >>>> CPE) reports, simply: > >>>> > >>>> traceroute 1.1.1.1 with: 64 bytes of data > >>>> > >>>> 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms > >>>> > >>>> I haven't bothered to report this to AT&T through the standard > customer > >>>> support channels (for reasons that should be obvious to anyone who has > >>>> ever called AT&T's consumer/residential technical support) but if > anyone > >>>> at AT&T wants to pass the info along to the appropriate group, it > would > >>>> certainly be appreciated. > >>>> > >>>> Thanks, > >>>> -Jeremy > >>>> > >>>> -- > >>>> Jeremy L. Gaddis > >>>> > >>>> > >>>> "The total budget at all receivers for solving senders' problems is > >>>> $0. If you want them to accept your mail and manage it the way you > >>>> want, send it the way the spec says to." --John Levine > >>>> > >>>> > >>> > >>> > >>> -- > >>> Darin Steffl > >>> Minnesota WiFi > >>> www.mnwifi.com > >>> 507-634-WiFi > >>> Like us on Facebook > >>> > >> > > > > > > > > -- > > Sincerely, > > > > Jason W Kuehl > > Cell 920-419-8983 > > jason.w.kuehl at gmail.com > > From brett at the-watsons.org Mon Apr 2 18:48:34 2018 From: brett at the-watsons.org (Brett Watson) Date: Mon, 2 Apr 2018 11:48:34 -0700 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <20180402171818.7156323FDEAD@ary.qy> References: <20180402171818.7156323FDEAD@ary.qy> Message-ID: > On Apr 2, 2018, at 10:18, John Levine wrote: > > In article <7DB5FAC7-972A-4EB6-89D9-B305A723334F at cloudflare.com> you write: >> If you know of others please send them my way so we can investigate. > > A lot of hotel and coffee shop captive portals use it for the login > and logout screens. Don't know what the underlying software is, but > wander around London and hop on the wifi at coffee shops and hotels > and you'll run into it soon enough. Tons of it in the US in hotels, airports, and any number of other places that folks have already mentioned. Why we are still experimenting with IPv4 space is a bit of a mystery to me. -b From mike.lyon at gmail.com Mon Apr 2 19:04:27 2018 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Mon, 2 Apr 2018 12:04:27 -0700 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: References: <20180402171818.7156323FDEAD@ary.qy> Message-ID: <23254A39-B37F-470D-83C5-4BA2AF494853@gmail.com> Because it would be wasteful not to use it??? > On Apr 2, 2018, at 11:48, Brett Watson wrote: > > > >> On Apr 2, 2018, at 10:18, John Levine wrote: >> >> In article <7DB5FAC7-972A-4EB6-89D9-B305A723334F at cloudflare.com> you write: >>> If you know of others please send them my way so we can investigate. >> >> A lot of hotel and coffee shop captive portals use it for the login >> and logout screens. Don't know what the underlying software is, but >> wander around London and hop on the wifi at coffee shops and hotels >> and you'll run into it soon enough. > > Tons of it in the US in hotels, airports, and any number of other places that folks have already mentioned. Why we are still experimenting with IPv4 space is a bit of a mystery to me. > > -b > From marty at cloudflare.com Mon Apr 2 19:32:58 2018 From: marty at cloudflare.com (Marty Strong) Date: Mon, 2 Apr 2018 20:32:58 +0100 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> Message-ID: <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> Do you have one? Do you know what is causing it to fail? i.e. IP on internal interface etc. Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 2 Apr 2018, at 19:24, Rubens Kuhl wrote: > > D-Link DMG-6661 as well. > > > Rubens > > > On Mon, Apr 2, 2018 at 12:26 PM, Marty Strong via NANOG wrote: > So far we know about a few CPEs which answer for 1.1.1.1 themselves: > > - Pace 5268 > - Calix GigaCenter > - Various Cisco Wifi access points > > If you know of others please send them my way so we can investigate. > > Regards, > Marty Strong > -------------------------------------- > Cloudflare - AS13335 > Network Engineer > marty at cloudflare.com > +44 7584 906 055 > smartflare (Skype) > > https://www.peeringdb.com/asn/13335 > > > On 2 Apr 2018, at 16:16, Jason Kuehl wrote: > > > > Just like "S3 dependency check day" Thus begins "National 1.1.1.1 change > > week" I've already around a few peaces of equipment sets with 1.1.1.1 > > > > On Mon, Apr 2, 2018 at 11:05 AM, Matt Hoppes < > > mattlists at rivervalleyinternet.net> wrote: > > > >> Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this is > >> causing odd issues. > >> > >>> On Apr 2, 2018, at 11:03, Darin Steffl wrote: > >>> > >>> I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my > >> router > >>> and not any further. When I enter the IP into my browser, it opens the > >>> login page for my router. So it appears 1.1.1.1 is used as a loopback in > >> my > >>> Calix router. > >>> > >>> 1.0.0.1 goes to the proper place fine. > >>> > >>> On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis > >>> wrote: > >>> > >>>> Greetings, > >>>> > >>>> If anyone at 7018 wants to pass a message along to the correct folks, > >>>> please let them know that Cloudflare's new public DNS service (1.1.1.1) > >>>> is completely unusable for at least some of AT&T's customers. > >>>> > >>>> There is apparently a bug with some CPE (including the 5268AC). From > >>>> behind such CPE, the services at 1.1.1.1 are completely unreachable, > >>>> whether via (ICMP) ping, DNS, or HTTPS. > >>>> > >>>> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns > >>>> the following results: > >>>> > >>>> ping successful: icmp seq:0, time=2.364 ms > >>>> ping successful: icmp seq:1, time=1.085 ms > >>>> ping successful: icmp seq:2, time=1.160 ms > >>>> ping successful: icmp seq:3, time=1.245 ms > >>>> ping successful: icmp seq:4, time=0.739 ms > >>>> > >>>> RTTs to the CPE's default gateway are, at minimum, ~20 ms. > >>>> > >>>> A traceroute (using the same web-based diagnostic tool built-in to the > >>>> CPE) reports, simply: > >>>> > >>>> traceroute 1.1.1.1 with: 64 bytes of data > >>>> > >>>> 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms > >>>> > >>>> I haven't bothered to report this to AT&T through the standard customer > >>>> support channels (for reasons that should be obvious to anyone who has > >>>> ever called AT&T's consumer/residential technical support) but if anyone > >>>> at AT&T wants to pass the info along to the appropriate group, it would > >>>> certainly be appreciated. > >>>> > >>>> Thanks, > >>>> -Jeremy > >>>> > >>>> -- > >>>> Jeremy L. Gaddis > >>>> > >>>> > >>>> "The total budget at all receivers for solving senders' problems is > >>>> $0. If you want them to accept your mail and manage it the way you > >>>> want, send it the way the spec says to." --John Levine > >>>> > >>>> > >>> > >>> > >>> -- > >>> Darin Steffl > >>> Minnesota WiFi > >>> www.mnwifi.com > >>> 507-634-WiFi > >>> Like us on Facebook > >>> > >> > > > > > > > > -- > > Sincerely, > > > > Jason W Kuehl > > Cell 920-419-8983 > > jason.w.kuehl at gmail.com > > From colinj at gt86car.org.uk Mon Apr 2 19:56:14 2018 From: colinj at gt86car.org.uk (Colin Johnston) Date: Mon, 2 Apr 2018 20:56:14 +0100 Subject: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london In-Reply-To: <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> Message-ID: <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> dont know if this is a problem but seeing different as paths for 1.0.0.1 and 1.1.1.1 in UK as lands 2 185.61.135.25 (185.61.135.25) 1.964 ms 72.824 ms 72.835 ms 3 10.254.84.3 (10.254.84.3) 2.671 ms 2.577 ms 2.601 ms 4 31.28.72.22 (31.28.72.22) 2.798 ms 2.897 ms 3.123 ms 5 * * * 6 * * * 7 ve160.er2.thn.as50056.net (178.18.119.90) 3.786 ms 178.18.122.193 (178.18.122.193) 2.542 ms ve160.er2.thn.as50056.net (178.18.119.90) 3.736 ms 8 * 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 3.350 ms * 2 185.61.135.25 (185.61.135.25) 3.172 ms 3.154 ms 3.130 ms 3 10.254.84.3 (10.254.84.3) 3.228 ms 3.525 ms 3.502 ms 4 31.28.72.22 (31.28.72.22) 3.781 ms 3.869 ms 3.857 ms 5 * * * 6 ve165.er1.the.as50056.net (94.126.43.225) 16.655 ms 9.496 ms 9.454 ms 7 lonap.as13335.net (5.57.81.75) 91.859 ms 2.484 ms 196.896 ms 8 1dot1dot1dot1.cloudflare-dns.com (1.0.0.1) 2.504 ms 2.804 ms 2.799 ms Colin From saku at ytti.fi Mon Apr 2 20:14:36 2018 From: saku at ytti.fi (Saku Ytti) Date: Mon, 2 Apr 2018 23:14:36 +0300 Subject: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london In-Reply-To: <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> Message-ID: If they are for redundancy, wouldn't it be preferable to route them to different place to cover more fault scenarios. I would complain if they are routed to same place. On 2 April 2018 at 22:56, Colin Johnston wrote: > dont know if this is a problem but seeing different as paths for 1.0.0.1 and 1.1.1.1 in UK as lands > > 2 185.61.135.25 (185.61.135.25) 1.964 ms 72.824 ms 72.835 ms > 3 10.254.84.3 (10.254.84.3) 2.671 ms 2.577 ms 2.601 ms > 4 31.28.72.22 (31.28.72.22) 2.798 ms 2.897 ms 3.123 ms > 5 * * * > 6 * * * > 7 ve160.er2.thn.as50056.net (178.18.119.90) 3.786 ms 178.18.122.193 (178.18.122.193) 2.542 ms ve160.er2.thn.as50056.net (178.18.119.90) 3.736 ms > 8 * 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 3.350 ms * > > > > 2 185.61.135.25 (185.61.135.25) 3.172 ms 3.154 ms 3.130 ms > 3 10.254.84.3 (10.254.84.3) 3.228 ms 3.525 ms 3.502 ms > 4 31.28.72.22 (31.28.72.22) 3.781 ms 3.869 ms 3.857 ms > 5 * * * > 6 ve165.er1.the.as50056.net (94.126.43.225) 16.655 ms 9.496 ms 9.454 ms > 7 lonap.as13335.net (5.57.81.75) 91.859 ms 2.484 ms 196.896 ms > 8 1dot1dot1dot1.cloudflare-dns.com (1.0.0.1) 2.504 ms 2.804 ms 2.799 ms > > > Colin > -- ++ytti From nanog at ics-il.net Mon Apr 2 20:16:15 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 2 Apr 2018 15:16:15 -0500 (CDT) Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> Message-ID: <201216628.1799.1522700172881.JavaMail.mhammett@ThunderFuck> "how many end users know about or care about DNS, even after reading snake oil advertisements." None. Nobody cares. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "James R Cutler" To: "North American Network Operators' Group" Sent: Monday, April 2, 2018 11:07:32 AM Subject: Re: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE > On Apr 2, 2018, at 11:35 AM, Simon Lockhart wrote: > > … > This looks like a willy-waving exercise by Cloudflare coming up with the lowest > quad-digit IP. They must have known that this would cause routing issues, and > now suddenly it's our responsibility to make significant changes to live > infrastructures just so they can continue to look clever with the IP address. > I am very impressed at Cloudflare’s forward thinking to force investing a significant amount of IPv4 infrastructure. This will obviously become even more important in the future as IPv6 withers away and is replaced by IPv4. And, I repeat, please tell me how many end users know about or care about DNS, even after reading snake oil advertisements. James R. Cutler James.cutler at consultant.com PGP keys at http://pgp.mit.edu From job at instituut.net Mon Apr 2 20:18:15 2018 From: job at instituut.net (Job Snijders) Date: Mon, 2 Apr 2018 20:18:15 +0000 Subject: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london In-Reply-To: References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> Message-ID: On Mon, Apr 2, 2018 at 8:14 PM, Saku Ytti wrote: > If they are for redundancy, wouldn't it be preferable to route them to > different place to cover more fault scenarios. > > I would complain if they are routed to same place. Better start complaining then :-) Kind regards, Job From me at anuragbhatia.com Mon Apr 2 20:36:34 2018 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 3 Apr 2018 02:06:34 +0530 Subject: whoami.akamai.net and public DNS node replies Message-ID: Hello everyone, Anyone using whoami.akamai.net? I have used it quite a while especially with large anycast players because they tend to have customer facing (anycast) IPs and internet facing unicast IPs to reach to outside world. Thus for say 8.8.8.8 while query may be local to my country (India), I saw that Google was using unicast IP from their Singapore location (as per IPs published here in their FAQ). dig @8.8.8.8 whoami.akamai.net used to give that IP. >From last few weeks, I see results are pretty inconsistent and just makes no sense whatsoever. E.g 5 consecutive queries to 8.8.8.8 asking whoami.akamai.net where Akamai should return me IP of recursor from where query came: dig @8.8.8.8 whoami.akamai.net a +short 103.252.111.59 dig @8.8.8.8 whoami.akamai.net a +short 118.185.164.42 dig @8.8.8.8 whoami.akamai.net a +short 118.185.164.42 dig @8.8.8.8 whoami.akamai.net a +short 14.139.241.214 dig @8.8.8.8 whoami.akamai.net a +short 103.252.111.59 This does not make sense since none of those unicast IPs belongs to Google. I see similar result for any other open DNS service like Cisco's OpenDNS: dig @208.67.222.222 whoami.akamai.net a +short 14.139.240.146 dig @208.67.222.222 whoami.akamai.net a +short 103.252.111.156 dig @208.67.222.222 whoami.akamai.net a +short 14.139.240.157 dig @208.67.222.222 whoami.akamai.net a +short 14.139.240.157 Is anyone aware of any issues in the way whoami.akamai.net works? dig +trace whoami.akamai.net gives me back my unicast IP which is logical considering fact that +trace tends to use local DNS recursor within the machine. This gives an impression that probably TTL is too high and recursors are caching reply which they are not supposed to. But at the same time, I do not see the logic of getting non-Google IPs when querying via 8.8.8.8. ;; QUESTION SECTION: ;whoami.akamai.net. IN A ;; ANSWER SECTION: whoami.akamai.net. 180 IN A 103.252.111.173 I think in past TTL used to be very low to avoid caching for it. Anyone with ideas on what's going on? -- Anurag Bhatia anuragbhatia.com From bruns at 2mbit.com Mon Apr 2 21:20:38 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 2 Apr 2018 15:20:38 -0600 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <20180402153537.GS31411@dilbert.slimey.org> References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> Message-ID: <91bcb362-1496-8d24-8c77-74edf8a6eaea@2mbit.com> On 4/2/2018 9:35 AM, Simon Lockhart wrote: > Quite. > > This looks like a willy-waving exercise by Cloudflare coming up with the lowest > quad-digit IP. They must have known that this would cause routing issues, and > now suddenly it's our responsibility to make significant changes to live > infrastructures just so they can continue to look clever with the IP address. > > Simon I don't see how this is Cloudflare's fault really? Its the responsibility of network maintainers to... well, lets be blunt here, maintain their network. If part of maintaining their network involves updating bogon routes/filters, then that's part of maintaining the network that can't be lapsed. This is like the WISPs blaming Ubiquiti for their failure to update their CPEs and PtP devices for a security flaw that Ubnt released fix for more then a year before (and for not properly securing the management interfaces of their network devices). Or even better, the morons who blocked all of 172.0.0.0/8 even though a good portion of that block is live public IP space. I actually felt really bad for AOL having been assigned IP blocks from that space, since it had to have created customer complaints at times. There's only one person to blame here, and it's not the RIRs or Cloudflare. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From nanog at ics-il.net Mon Apr 2 21:23:31 2018 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 2 Apr 2018 16:23:31 -0500 (CDT) Subject: UBNT Security was Re: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <91bcb362-1496-8d24-8c77-74edf8a6eaea@2mbit.com> References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> <91bcb362-1496-8d24-8c77-74edf8a6eaea@2mbit.com> Message-ID: <2145179005.1930.1522704208669.JavaMail.mhammett@ThunderFuck> I believe at one point UBNT did block outside management access, but then their customers voiced to bring it back. That said, I think they're taking security more seriously going forward. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brielle Bruns" To: nanog at nanog.org Sent: Monday, April 2, 2018 4:20:38 PM Subject: Re: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE On 4/2/2018 9:35 AM, Simon Lockhart wrote: > Quite. > > This looks like a willy-waving exercise by Cloudflare coming up with the lowest > quad-digit IP. They must have known that this would cause routing issues, and > now suddenly it's our responsibility to make significant changes to live > infrastructures just so they can continue to look clever with the IP address. > > Simon I don't see how this is Cloudflare's fault really? Its the responsibility of network maintainers to... well, lets be blunt here, maintain their network. If part of maintaining their network involves updating bogon routes/filters, then that's part of maintaining the network that can't be lapsed. This is like the WISPs blaming Ubiquiti for their failure to update their CPEs and PtP devices for a security flaw that Ubnt released fix for more then a year before (and for not properly securing the management interfaces of their network devices). Or even better, the morons who blocked all of 172.0.0.0/8 even though a good portion of that block is live public IP space. I actually felt really bad for AOL having been assigned IP blocks from that space, since it had to have created customer complaints at times. There's only one person to blame here, and it's not the RIRs or Cloudflare. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From fw at deneb.enyo.de Mon Apr 2 21:26:12 2018 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 02 Apr 2018 23:26:12 +0200 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: (Hank Nussbacher's message of "Mon, 2 Apr 2018 19:34:18 +0300") References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> Message-ID: <87muyluwp7.fsf@mid.deneb.enyo.de> * Hank Nussbacher: > Perhaps they are running all  this to shake out exactly these type of > issues?  I think that is exactly why APNIC research is called for. And return another 2**24 addresses to the global IPv4 pool eventually? That would indeed be a loadable goal. From bruns at 2mbit.com Mon Apr 2 21:37:37 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 2 Apr 2018 15:37:37 -0600 Subject: UBNT Security was Re: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <2145179005.1930.1522704208669.JavaMail.mhammett@ThunderFuck> References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> <91bcb362-1496-8d24-8c77-74edf8a6eaea@2mbit.com> <2145179005.1930.1522704208669.JavaMail.mhammett@ThunderFuck> Message-ID: <6529a4d9-f8e3-2c04-547a-1ec3cf480f16@2mbit.com> On 4/2/2018 3:23 PM, Mike Hammett wrote: > I believe at one point UBNT did block outside management access, but then their customers voiced to bring it back. > > That said, I think they're taking security more seriously going forward. I'm not entirely sure what Ubnt has changed lately, because I'm not a user of the Air* product lines (usually used by the WISPs), but I know on, for example the Unifi stuff, while the default password is ubnt/ubnt for the devices, as soon as they are paired with a controller, the password is set to a random long strong (on a per site basis). I seem to remember on new EdgeRouter devices they do have you change the default password during initial web setup. CLI stuff, I think still have to manually change it from the default. So yeah, big improvements. That being said, either way, providers that fail to even basic setup tasks like changing the default password do deserve what happens to them. (Note: I heavily use Ubnt's Unifi and Edge* product lines, so I'm probably biased in one way or another.) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From marty at cloudflare.com Mon Apr 2 21:58:29 2018 From: marty at cloudflare.com (Marty Strong) Date: Mon, 2 Apr 2018 22:58:29 +0100 Subject: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london In-Reply-To: References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> Message-ID: Routing from ~150 locations, plenty of redundancy. https://www.cloudflare.com/network/ Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 2 Apr 2018, at 21:14, Saku Ytti wrote: > > If they are for redundancy, wouldn't it be preferable to route them to > different place to cover more fault scenarios. > > I would complain if they are routed to same place. > > > On 2 April 2018 at 22:56, Colin Johnston wrote: >> dont know if this is a problem but seeing different as paths for 1.0.0.1 and 1.1.1.1 in UK as lands >> >> 2 185.61.135.25 (185.61.135.25) 1.964 ms 72.824 ms 72.835 ms >> 3 10.254.84.3 (10.254.84.3) 2.671 ms 2.577 ms 2.601 ms >> 4 31.28.72.22 (31.28.72.22) 2.798 ms 2.897 ms 3.123 ms >> 5 * * * >> 6 * * * >> 7 ve160.er2.thn.as50056.net (178.18.119.90) 3.786 ms 178.18.122.193 (178.18.122.193) 2.542 ms ve160.er2.thn.as50056.net (178.18.119.90) 3.736 ms >> 8 * 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 3.350 ms * >> >> >> >> 2 185.61.135.25 (185.61.135.25) 3.172 ms 3.154 ms 3.130 ms >> 3 10.254.84.3 (10.254.84.3) 3.228 ms 3.525 ms 3.502 ms >> 4 31.28.72.22 (31.28.72.22) 3.781 ms 3.869 ms 3.857 ms >> 5 * * * >> 6 ve165.er1.the.as50056.net (94.126.43.225) 16.655 ms 9.496 ms 9.454 ms >> 7 lonap.as13335.net (5.57.81.75) 91.859 ms 2.484 ms 196.896 ms >> 8 1dot1dot1dot1.cloudflare-dns.com (1.0.0.1) 2.504 ms 2.804 ms 2.799 ms >> >> >> Colin >> > > > > -- > ++ytti From sethm at rollernet.us Mon Apr 2 22:06:00 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 2 Apr 2018 15:06:00 -0700 Subject: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london In-Reply-To: References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> Message-ID: On 4/2/18 14:58, Marty Strong via NANOG wrote: > Routing from ~150 locations, plenty of redundancy. > > https://www.cloudflare.com/network/ I recommend 9.9.9.9 to people (if they must use a public resolver) because Quad9/PCH serves local markets of all sizes with anycast nodes and peering, not just "major markets". Since I'm not in a major market I want to support those who support the small markets that are overlooked by the big guys. From jared at puck.nether.net Mon Apr 2 22:10:15 2018 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 2 Apr 2018 18:10:15 -0400 Subject: whoami.akamai.net and public DNS node replies In-Reply-To: References: Message-ID: > On Apr 2, 2018, at 4:36 PM, Anurag Bhatia wrote: > > Hello everyone, > > Anyone using whoami.akamai.net? Thanks, our team is investigating this at present. I don’t have an ETR at the moment. - Jared From mattlists at rivervalleyinternet.net Mon Apr 2 22:39:58 2018 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Mon, 2 Apr 2018 18:39:58 -0400 Subject: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london In-Reply-To: References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> Message-ID: <1b15ef27-00db-8d1d-b6ab-bef7840b03a4@rivervalleyinternet.net> So in all this discussion, what I'm finding interesting is that 8.8.8.8 is actually more hops away from me than either 9.9.9.9 or 1.1.1.1 On 4/2/18 6:06 PM, Seth Mattinen wrote: > On 4/2/18 14:58, Marty Strong via NANOG wrote: >> Routing from ~150 locations, plenty of redundancy. >> >> https://www.cloudflare.com/network/ > > > I recommend 9.9.9.9 to people (if they must use a public resolver) > because Quad9/PCH serves local markets of all sizes with anycast nodes > and peering, not just "major markets". Since I'm not in a major market I > want to support those who support the small markets that are overlooked > by the big guys. From jsklein at gmail.com Mon Apr 2 22:58:14 2018 From: jsklein at gmail.com (Joe Klein) Date: Mon, 2 Apr 2018 18:58:14 -0400 Subject: NG Firewalls & IPv6 Message-ID: All, At security and network tradeshows over the last 15 years, I have asked companies if their products supported "IPv6". They all claimed they did, but were unable to verify any successful installations. Later they told me it was on their "Roadmap" but were unable to provide an estimated year, because it was a trade secret. Starting this last year at BlackHat US, I again visited every product booth, asking if their products supported dual-stack or IPv6 only operations. Receiving only the same unsupported answers, I decided to focus on one product category. To the gurus of the NANOG community, What are your experiences with installing and managing Next Generations firewalls? Do they support IPv6 only environments? Details? Stories? If you prefer not to disparage those poor product companies, please contact me off the list. Thanks, Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 From rubensk at gmail.com Mon Apr 2 23:17:48 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 2 Apr 2018 20:17:48 -0300 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> Message-ID: On Mon, Apr 2, 2018 at 4:32 PM, Marty Strong wrote: > Do you have one? > Yes, supplied by local broadband provider Vivo. FTTH GPON connection, router with broadband and IPTV services. > Do you know what is causing it to fail? i.e. IP on internal interface etc. > Interface table: eth5.2 (WAN2) Static 10.200.a.b 255.255.128.0 10.200.0.1 Connected NONE 527220 eth5.3 (WAN4) DHCP Unconfigured NONE 0 eth5.4 (WAN5) DHCP Unconfigured NONE 0 ppp0.1/eth5.1 (WAN1) PPPoE 179.x.y.z 255.255.255.255 200.d.e.f Connected NONE 527200 ppp1/wan3g (WAN3) PPPoE Unconfigured NONE 0 LAN INTERFACE STATUS Name Status IP Address Subnet Mask br0 Enable 192.168.1.1 255.255.255.0 br0:0 Enable 1.1.1.1 255.255.255.0 Routing table: 200.x.y.z 0.0.0.0 255.255.255.255 UH 0 ppp0.1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 br0 1.1.1.0 0.0.0.0 255.255.255.0 U 0 br0 10.200.0.0 0.0.0.0 255.255.128.0 U 0 eth5.2 0.0.0.0 200.100.88.195 0.0.0.0 UG 0 ppp0.1 Rubens From marka at isc.org Tue Apr 3 00:10:35 2018 From: marka at isc.org (Mark Andrews) Date: Tue, 3 Apr 2018 10:10:35 +1000 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <645cb48e-437f-e036-75f0-c4416c8b9594@rollernet.us> References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> <645cb48e-437f-e036-75f0-c4416c8b9594@rollernet.us> Message-ID: <172E74AB-1AC6-4B29-80BD-694F0CD1220D@isc.org> > On 3 Apr 2018, at 1:39 am, Seth Mattinen wrote: > > On 4/2/18 8:35 AM, Simon Lockhart wrote: >> This looks like a willy-waving exercise by Cloudflare coming up with the lowest >> quad-digit IP. They must have known that this would cause routing issues, and >> now suddenly it's our responsibility to make significant changes to live >> infrastructures just so they can continue to look clever with the IP address. > > > To be fair, nobody should have been using 1/8 for anything. Stop living in the 1900’s. Parts to 1/8 have be allocated to people for years now. 1.0.0/24 and 1.2.3/24 have been used for various experiments but the rest of 1/8 is being allocated for normal use (there may be a couple of more exceptions). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From sethm at rollernet.us Tue Apr 3 00:12:49 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 2 Apr 2018 17:12:49 -0700 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <172E74AB-1AC6-4B29-80BD-694F0CD1220D@isc.org> References: <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> <20180402153537.GS31411@dilbert.slimey.org> <645cb48e-437f-e036-75f0-c4416c8b9594@rollernet.us> <172E74AB-1AC6-4B29-80BD-694F0CD1220D@isc.org> Message-ID: On 4/2/18 5:10 PM, Mark Andrews wrote: >> On 3 Apr 2018, at 1:39 am, Seth Mattinen wrote: >> >> On 4/2/18 8:35 AM, Simon Lockhart wrote: >>> This looks like a willy-waving exercise by Cloudflare coming up with the lowest >>> quad-digit IP. They must have known that this would cause routing issues, and >>> now suddenly it's our responsibility to make significant changes to live >>> infrastructures just so they can continue to look clever with the IP address. >> >> To be fair, nobody should have been using 1/8 for anything. > Stop living in the 1900’s. Parts to 1/8 have be allocated to people for > years now. Copypasta: I didn't say that. In case this is a non-native English issue, "nobody should have been using" is past tense, which is to say everyone squatting on 1/8 space for their own purposes because it was "unassigned" shouldn't have been doing that. ~Seth From dhubbard at dino.hostasaurus.com Tue Apr 3 00:28:11 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 3 Apr 2018 00:28:11 +0000 Subject: NG Firewalls & IPv6 In-Reply-To: References: Message-ID: I’ve been doing dual stack through Fortinet products for many years without issue. Well, no issue from a technical perspective. Sometimes you have to dig for a bit to find the equivalent v6 CLI commands, and occasionally there’s GUI stuff missing that requires CLI where the v4 equivalent didn’t, but not a bad experience overall. Does v6 vpn’s great too. Haven’t delved into dynamic routing protocols on them so can’t speak to that. Happy to answer questions. David ________________________________ From: NANOG on behalf of Joe Klein Sent: Monday, April 2, 2018 6:58:14 PM To: NANOG list Subject: NG Firewalls & IPv6 All, At security and network tradeshows over the last 15 years, I have asked companies if their products supported "IPv6". They all claimed they did, but were unable to verify any successful installations. Later they told me it was on their "Roadmap" but were unable to provide an estimated year, because it was a trade secret. Starting this last year at BlackHat US, I again visited every product booth, asking if their products supported dual-stack or IPv6 only operations. Receiving only the same unsupported answers, I decided to focus on one product category. To the gurus of the NANOG community, What are your experiences with installing and managing Next Generations firewalls? Do they support IPv6 only environments? Details? Stories? If you prefer not to disparage those poor product companies, please contact me off the list. Thanks, Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 From mathews at hawaii.edu Tue Apr 3 02:24:15 2018 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Mon, 02 Apr 2018 22:24:15 -0400 Subject: From Nov 2017... Message-ID: <5AC2E5CF.4020508@hawaii.edu> To be clear..... *DNS resolver 9.9.9.9 will check requests against IBM threat database* *Group Co-founded by City of London Police promises 'no snooping on your requests'* By Richard Chirgwin 20 Nov 2017 at 06:58 The Register (UK) https://www.theregister.co.uk/2017/11/20/quad9_secure_private_dns_resolver/ From sethm at rollernet.us Tue Apr 3 02:36:33 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 2 Apr 2018 19:36:33 -0700 Subject: From Nov 2017... In-Reply-To: <5AC2E5CF.4020508@hawaii.edu> References: <5AC2E5CF.4020508@hawaii.edu> Message-ID: <56998e3a-93bf-2b00-3fe8-64718294af24@rollernet.us> On 4/2/18 7:24 PM, Robert Mathews (OSIA) wrote: > To be clear..... > > *DNS resolver 9.9.9.9 will check requests against IBM threat database* To be clear on what? That an IBM database is queried, just like it says on their website? That doesn't mean they are recording who is making what requests. From sethm at rollernet.us Tue Apr 3 03:42:55 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 2 Apr 2018 20:42:55 -0700 Subject: From Nov 2017... In-Reply-To: References: <5AC2E5CF.4020508@hawaii.edu> <56998e3a-93bf-2b00-3fe8-64718294af24@rollernet.us> Message-ID: <1b08686d-7981-bf0e-8b80-9ffebae9931b@rollernet.us> On 4/2/18 7:43 PM, J Crowe wrote: > That database could possibly be ingested and used locally. Traffic may > not even be traversing to the database hosted by IBM. > > At least they are open about where they are getting the data that allows > for blocking to certain FQDNs. Even if it does traverse somewhere to ask the database, it wouldn't be the DNS user that's making that request, it would be coming from whatever anycast node is handling it decoupled from the actual user's DNS query. From woody at pch.net Tue Apr 3 05:04:28 2018 From: woody at pch.net (Bill Woodcock) Date: Mon, 2 Apr 2018 22:04:28 -0700 Subject: From Nov 2017... In-Reply-To: <5AC2E5CF.4020508@hawaii.edu> References: <5AC2E5CF.4020508@hawaii.edu> Message-ID: > On Apr 2, 2018, at 7:24 PM, Robert Mathews (OSIA) wrote: > *Group Co-founded by City of London Police promises 'no snooping on your requests’* Note that this is _extremely_ misleading, since the group being referred to here is _not_ Quad9, but instead GCA, one of the many donors that are supporting the Quad9 project. Quad9 doesn’t have any association with the City of London Police, other than that they’re among the many tens of millions of users in the general public. > *DNS resolver 9.9.9.9 will check requests against IBM threat database* Not exactly correct… There are nineteen threat intel providers, including Intel, Cisco, and F-Secure, which provide real-time feeds of compromised and C&C domains to Quad9. Quad9 does a bunch of reputation scoring on the data feeds to figure out which are likely problematic and which might be false-positives, before including them in the optional block-list. There’s a partial list of the threat-intel providers about halfway down this page: https://www.quad9.net/about/ And you can check at any time whether an FQDN is currently being blocked using a field on the front page of the Quad9 site. > On Apr 2, 2018, at 7:36 PM, Seth Mattinen wrote: > ...an IBM database is queried, just like it says on their website? That doesn't mean they are recording who is making what requests. Correct. All that is defined in the privacy policy. No IP addresses are recorded. No query strings are recorded, but ones that match an FQDN on the block-list are tallied, and that tally is used to improve the reputation-scoring of the threat intel providers, and is fed back to the threat intel providers to help them improve their own data quality. I believe the privacy policy that’s still up right now says that we may optionally give the threat-intel providers aggregate statistics per country, but we’re not actually doing that in practice, and it’s our intention to narrow down the policy to reflect actual practice. On 4/2/18 7:43 PM, J Crowe wrote: > That database could possibly be ingested and used locally. Correct. The database is ingested and used locally _at each server_, so the queries never even leave the server. Anything else would be too slow and stateful to work. > Traffic may not even be traversing to the database hosted by IBM. Correct. The threat-intel data comes from them to us, and a count of matches goes from us to them. > At least they are open about where they are getting the data that allows for blocking to certain FQDNs. Yeah… Sorry only twelve of the nineteen are listed on the web site right now, but the project is stretched pretty thin keeping up with requests for new locations, and we haven’t had a lot of time to update the web site… There’s no intention for the list to not be public, and I can get and post the full list if anyone cares. Though it would probably be better if I spent that time hunting for someone to update the web site. :-) -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From hank at efes.iucc.ac.il Tue Apr 3 05:12:40 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 3 Apr 2018 08:12:40 +0300 Subject: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london In-Reply-To: <1b15ef27-00db-8d1d-b6ab-bef7840b03a4@rivervalleyinternet.net> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> <1b15ef27-00db-8d1d-b6ab-bef7840b03a4@rivervalleyinternet.net> Message-ID: On 03/04/2018 01:39, Matt Hoppes wrote: You might be interested in these links which compare the services: https://medium.com/@nykolas.z/dns-resolvers-performance-compared-cloudflare-x-google-x-quad9-x-opendns-149e803734e5 https://webxtrakt.com/public-dns-performance -Hank > So in all this discussion, what I'm finding interesting is that > 8.8.8.8 is actually more hops away from me than either 9.9.9.9 or 1.1.1.1 > > On 4/2/18 6:06 PM, Seth Mattinen wrote: >> On 4/2/18 14:58, Marty Strong via NANOG wrote: >>> Routing from ~150 locations, plenty of redundancy. >>> >>> https://www.cloudflare.com/network/ >> >> >> I recommend 9.9.9.9 to people (if they must use a public resolver) >> because Quad9/PCH serves local markets of all sizes with anycast >> nodes and peering, not just "major markets". Since I'm not in a major >> market I want to support those who support the small markets that are >> overlooked by the big guys. > From tore at fud.no Tue Apr 3 05:22:30 2018 From: tore at fud.no (Tore Anderson) Date: Tue, 3 Apr 2018 07:22:30 +0200 Subject: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london In-Reply-To: References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> Message-ID: <20180403072230.07a785b7@echo.ms.redpill-linpro.com> * Marty Strong via NANOG > Routing from ~150 locations, plenty of redundancy. Any plans to support NSID and/or "hostname.bind" to allow clients to identify which node is serving their requests? For example: $ dig @nsb.dnsnode.net. hostname.bind. CH TXT +nsid [...] ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; NSID: 73 34 2e 6f 73 6c ("s4.osl") ;; QUESTION SECTION: ;hostname.bind. CH TXT ;; ANSWER SECTION: hostname.bind. 0 CH TXT "s4.osl" [...] Tore From rol at witbe.net Tue Apr 3 06:22:04 2018 From: rol at witbe.net (Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)) Date: Tue, 3 Apr 2018 08:22:04 +0200 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> Message-ID: <20180403082204.3fee93ac@riri.DEF.witbe.net> Hello, On Mon, 2 Apr 2018 16:26:13 +0100 Marty Strong via NANOG wrote: > So far we know about a few CPEs which answer for 1.1.1.1 themselves: > > - Pace 5268 > - Calix GigaCenter > - Various Cisco Wifi access points > > If you know of others please send them my way so we can investigate. It seems that in France, Orange's Livebox is also using 1.1.1.1 is some way... 215 [6:20] rol at riri:~> traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 216 [6:20] rol at riri:~> ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.371 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=0.292 ms ^C --- 1.1.1.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1037ms rtt min/avg/max/mdev = 0.292/0.331/0.371/0.043 ms 217 [6:20] rol at riri:~> traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 livebox.home (192.168.1.254) 0.268 ms 0.236 ms 0.263 ms 2 * * * 3 ae102-0.ncidf103.Puteaux.francetelecom.net (193.253.80.138) 1.724 ms 1.733 ms 1.793 ms ... That IP address is definitely full of magic... Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From mathews at hawaii.edu Tue Apr 3 06:28:27 2018 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Tue, 03 Apr 2018 02:28:27 -0400 Subject: From Nov 2017... In-Reply-To: References: <5AC2E5CF.4020508@hawaii.edu> Message-ID: <5AC31F0B.1080903@hawaii.edu> On 4/3/2018 1:04 AM, Bill Woodcock wrote: >> On Apr 2, 2018, at 7:24 PM, Robert Mathews (OSIA) >> wrote: *Group Co-founded by City of London >> Police promises 'no snooping on your requests’* > Note that this is _extremely_ misleading, since the group being > referred to here is _not_ Quad9, but instead GCA, one of the many > donors that are supporting the Quad9 project. Quad9 doesn’t have any > association with the City of London Police, other than that they’re > among the many tens of millions of users in the general public. Bill: As you will have noted, the post was a reflection of that which The Register had published, and at the URL that was provided. Have you, or others at Quad9, reached out to The Register to have the details in their reporting corrected? In focus, within the Cloudflare announcement, is the subject of Privacy. Subsequently, some on the list had also spoken of Privacy needs in relation to the DNS Ops. It is solely for that reason, The Register publication was shared. > -Bill All the best, Robert. -- From marty at cloudflare.com Tue Apr 3 06:37:15 2018 From: marty at cloudflare.com (Marty Strong) Date: Tue, 3 Apr 2018 07:37:15 +0100 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <20180403082204.3fee93ac@riri.DEF.witbe.net> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <20180403082204.3fee93ac@riri.DEF.witbe.net> Message-ID: <8E0CFAE3-9AF4-4EC4-AC53-ECEF03601205@cloudflare.com> Orange France is known, they just didn’t tell us the exact reason. They said that if you contact them, they’ll provide you with an official explanation. Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 3 Apr 2018, at 07:22, Paul Rolland (ポール・ロラン) wrote: > > Hello, > > On Mon, 2 Apr 2018 16:26:13 +0100 > Marty Strong via NANOG wrote: > >> So far we know about a few CPEs which answer for 1.1.1.1 themselves: >> >> - Pace 5268 >> - Calix GigaCenter >> - Various Cisco Wifi access points >> >> If you know of others please send them my way so we can investigate. > > It seems that in France, Orange's Livebox is also using 1.1.1.1 is some > way... > > 215 [6:20] rol at riri:~> traceroute 1.1.1.1 > traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets > 1 * * * > 2 * * * > 3 * * * > 4 * * * > > 216 [6:20] rol at riri:~> ping 1.1.1.1 > PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. > 64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.371 ms > 64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=0.292 ms > ^C > --- 1.1.1.1 ping statistics --- > 2 packets transmitted, 2 received, 0% packet loss, time 1037ms > rtt min/avg/max/mdev = 0.292/0.331/0.371/0.043 ms > > 217 [6:20] rol at riri:~> traceroute 8.8.8.8 > traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets > 1 livebox.home (192.168.1.254) 0.268 ms 0.236 ms 0.263 ms > 2 * * * > 3 ae102-0.ncidf103.Puteaux.francetelecom.net (193.253.80.138) 1.724 ms 1.733 ms 1.793 ms > ... > > That IP address is definitely full of magic... > > Paul > > From woody at pch.net Tue Apr 3 06:37:10 2018 From: woody at pch.net (Bill Woodcock) Date: Mon, 2 Apr 2018 23:37:10 -0700 Subject: From Nov 2017... In-Reply-To: <5AC31F0B.1080903@hawaii.edu> References: <5AC2E5CF.4020508@hawaii.edu> <5AC31F0B.1080903@hawaii.edu> Message-ID: <96FDCBF9-0BAE-4CA5-AD66-48FB178257FD@pch.net> > On Apr 2, 2018, at 11:28 PM, Robert Mathews (OSIA) wrote: > > On 4/3/2018 1:04 AM, Bill Woodcock wrote: >>> On Apr 2, 2018, at 7:24 PM, Robert Mathews (OSIA) >>> wrote: *Group Co-founded by City of London >>> Police promises 'no snooping on your requests’* >> Note that this is _extremely_ misleading, since the group being >> referred to here is _not_ Quad9, but instead GCA, one of the many >> donors that are supporting the Quad9 project. Quad9 doesn’t have any >> association with the City of London Police, other than that they’re >> among the many tens of millions of users in the general public. > > > Bill: As you will have noted, the post was a reflection of that which > The Register had published, and at the URL that was provided. What’s your point, though? Are you talking about Quad9, or about GCA? If you’re talking about Quad9, you’re misleading people by implying that the quote you pulled from the Register piece pertains to Quad9, when it does not. If you’re talking about GCA, you’re misleading people by implying that what you’re saying about GCA somehow applies to Quad9. If you’re talking about Quad9, John Todd or I can address any questions. If you’re talking about GCA, that’s between you and them. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From mathews at hawaii.edu Tue Apr 3 06:54:39 2018 From: mathews at hawaii.edu (Robert Mathews (OSIA)) Date: Tue, 03 Apr 2018 02:54:39 -0400 Subject: From Nov 2017... In-Reply-To: <96FDCBF9-0BAE-4CA5-AD66-48FB178257FD@pch.net> References: <5AC2E5CF.4020508@hawaii.edu> <5AC31F0B.1080903@hawaii.edu> <96FDCBF9-0BAE-4CA5-AD66-48FB178257FD@pch.net> Message-ID: <5AC3252F.7010501@hawaii.edu> On 4/3/2018 2:37 AM, Bill Woodcock wrote: > What’s your point, though? Are you talking about Quad9, or about GCA? > > If you’re talking about Quad9, you’re misleading people by implying that the quote you pulled from the Register piece pertains to Quad9, when it does not. > > If you’re talking about GCA, you’re misleading people by implying that what you’re saying about GCA somehow applies to Quad9. > > If you’re talking about Quad9, John Todd or I can address any questions. If you’re talking about GCA, that’s between you and them. > > -Bill Bill and others: The story from The Register was posted as it was... the added words, "to be clear" was intended to focus exchanges (if there was interest) in relation to Privacy, The Register's reporting. NOTHING more. The fact that you have somehow INTERPRETED here, that I have personally taken a FOR, or AGAINST position to Quad9 operation, would be an error. Since when is it an offense, to merely share a publicly available URL? More to the point of Privacy, you have shared some information here regarding Quad9 operations that may have been beneficial to some, or many. It has been of benefit to me, and thanks for sharing that which what you have. All the best. From woody at pch.net Tue Apr 3 07:15:04 2018 From: woody at pch.net (Bill Woodcock) Date: Tue, 3 Apr 2018 00:15:04 -0700 Subject: From Nov 2017... In-Reply-To: <5AC3252F.7010501@hawaii.edu> References: <5AC2E5CF.4020508@hawaii.edu> <5AC31F0B.1080903@hawaii.edu> <96FDCBF9-0BAE-4CA5-AD66-48FB178257FD@pch.net> <5AC3252F.7010501@hawaii.edu> Message-ID: > Since when is it an offense, to merely share a publicly available URL? > > More to the point of Privacy, you have shared some information here regarding Quad9 operations that may have been beneficial to some, or many. It has been of benefit to me, and thanks for sharing that which what you have. Ok, sorry if I was being overly persnickety. My apologies. I’ve been spending too much time answering questions on “social media” and it’s making me antisocial. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From mathews at hawaii.edu Tue Apr 3 07:29:30 2018 From: mathews at hawaii.edu (Mathews, Robert) Date: Tue, 03 Apr 2018 03:29:30 -0400 Subject: From Nov 2017... In-Reply-To: References: <5AC2E5CF.4020508@hawaii.edu> <5AC31F0B.1080903@hawaii.edu> <96FDCBF9-0BAE-4CA5-AD66-48FB178257FD@pch.net> <5AC3252F.7010501@hawaii.edu> Message-ID: <5AC32D5A.704@hawaii.edu> On 4/3/2018 3:15 AM, Bill Woodcock wrote: >> Since when is it an offense, to merely share a publicly available URL? >> >> More to the point of Privacy, you have shared some information here regarding Quad9 operations that may have been beneficial to some, or many. It has been of benefit to me, and thanks for sharing that which what you have. > Ok, sorry if I was being overly persnickety. My apologies. I’ve been spending too much time answering questions on “social media” and it’s making me antisocial. > > -Bill Bill: No offense taken... it is quite alright... and thank you, for the information you had cared to share.... All the best, Robert. From bengelly at gmail.com Tue Apr 3 07:55:20 2018 From: bengelly at gmail.com (Youssef Bengelloun-Zahr) Date: Tue, 3 Apr 2018 09:55:20 +0200 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <8E0CFAE3-9AF4-4EC4-AC53-ECEF03601205@cloudflare.com> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <20180403082204.3fee93ac@riri.DEF.witbe.net> <8E0CFAE3-9AF4-4EC4-AC53-ECEF03601205@cloudflare.com> Message-ID: Still believe in santa ? ;-) Good luck with that. Best regards. 2018-04-03 8:37 GMT+02:00 Marty Strong via NANOG : > Orange France is known, they just didn’t tell us the exact reason. > > They said that if you contact them, they’ll provide you with an official > explanation. > > Regards, > Marty Strong > -------------------------------------- > Cloudflare - AS13335 > Network Engineer > marty at cloudflare.com > +44 7584 906 055 > smartflare (Skype) > > https://www.peeringdb.com/asn/13335 > > > On 3 Apr 2018, at 07:22, Paul Rolland (ポール・ロラン) wrote: > > > > Hello, > > > > On Mon, 2 Apr 2018 16:26:13 +0100 > > Marty Strong via NANOG wrote: > > > >> So far we know about a few CPEs which answer for 1.1.1.1 themselves: > >> > >> - Pace 5268 > >> - Calix GigaCenter > >> - Various Cisco Wifi access points > >> > >> If you know of others please send them my way so we can investigate. > > > > It seems that in France, Orange's Livebox is also using 1.1.1.1 is some > > way... > > > > 215 [6:20] rol at riri:~> traceroute 1.1.1.1 > > traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets > > 1 * * * > > 2 * * * > > 3 * * * > > 4 * * * > > > > 216 [6:20] rol at riri:~> ping 1.1.1.1 > > PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. > > 64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.371 ms > > 64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=0.292 ms > > ^C > > --- 1.1.1.1 ping statistics --- > > 2 packets transmitted, 2 received, 0% packet loss, time 1037ms > > rtt min/avg/max/mdev = 0.292/0.331/0.371/0.043 ms > > > > 217 [6:20] rol at riri:~> traceroute 8.8.8.8 > > traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets > > 1 livebox.home (192.168.1.254) 0.268 ms 0.236 ms 0.263 ms > > 2 * * * > > 3 ae102-0.ncidf103.Puteaux.francetelecom.net (193.253.80.138) 1.724 > ms 1.733 ms 1.793 ms > > ... > > > > That IP address is definitely full of magic... > > > > Paul > > > > > > From bortzmeyer at nic.fr Tue Apr 3 09:45:05 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 3 Apr 2018 11:45:05 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> Message-ID: <20180403094505.h2wf6rg7w2uf7x64@nic.fr> On Sun, Apr 01, 2018 at 09:22:10AM -0700, Stephen Satchell wrote a message of 39 lines which said: > Recursive lookups take bandwidth and wall time. The closer you can > get your recursive DNS server to the core of the internet, the > faster the lookups. I think the exact opposite is true: many DNS requests hit the cache, so the important factor is the latency between the end user and the cache. So, local resolvers win. > This is particularly true of mobile and satellite. Yes, because they have awful latency, it is important to have a local resolver. > (I wonder if the Internet Systems Consortium has considered adding a > cache-hit counter, or even a very coarse heat map (say, four 16-bit counters > cycled every five minutes), to DNS entries, to figure out the best ones to > drop? It would increase the complexity of BIND, but the benefit for a BIND > server serving a largish customer population could be significant. Making the largest and richest services even faster and so increase centralisation? It does not strike me as a good strategy. > I've not personally measured the number of times a look-up could be > satisfied from a cache in a production environment; For instance, at my home: % cache.stats() [hit] => 276089296 [delete] => 5 [miss] => 423661208 [insert] => 18850452 > The main reason for *not* implementing recursion exclusively in CPE > is that a recursive lookup is a complex operation, and I have my > doubts if BIND or equivalent could be maintained properly in, say, a > wireless access point (router) -- how would you update a hints > table? There is nothing DNS-specific here: routers/CPE with automatic updates exist for several years (I use the Turris Omnia ). The hints file is the *last* problem: most IP addresses of the root name servers didn't change for more than ten years. From bortzmeyer at nic.fr Tue Apr 3 09:54:36 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 3 Apr 2018 11:54:36 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> Message-ID: <20180403095436.t5gleuzzgv7xutjf@nic.fr> On Sun, Apr 01, 2018 at 02:03:41PM -0600, Paul Ebersman wrote a message of 38 lines which said: > And EDNS client subnet mostly works. It is awful, privacy-wise, complicates the cache a lot and seriously decreases hit rate in cache (since the key to a cached resource is no longer type+name but type+name+source_address). > And yes, running your own resolver is more private. So is running > your own home linux server instead of antique consumer OSs on > consumer grade gear and using VPNs. But how many folks can do that? It is not just an issue of knowledge and skills. Even if you have both, you may lack time, and prefer a shrink-wrapped solution. The future is in "boxes" which are both ready-to-use (for the guy who lacks sysadmin skills, and/or lacks time) and open (for the tinkerer). The Turris Omnia is a very good example. > This also ignores the shift if every house in the world did its own > recursion. TLD servers and auth servers all over the world would > have to massively up their capacity to cope. With my TLD operator hat, I tend to say it is not a problem, we already have a lot of extra capacity, to handle dDoS. > As long as ISPs don't actually disallow running of recursive servers That would be a terrible violation of network neutrality. I hope that such ISP will go bankrupt. From Brian at ampr.org Tue Apr 3 10:01:19 2018 From: Brian at ampr.org (Brian Kantor) Date: Tue, 3 Apr 2018 03:01:19 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: <20180403095436.t5gleuzzgv7xutjf@nic.fr> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <20180403095436.t5gleuzzgv7xutjf@nic.fr> Message-ID: <20180403100119.GA30206@meow.BKantor.net> On Tue, Apr 03, 2018 at 11:54:36AM +0200, Stephane Bortzmeyer wrote: > On Sun, Apr 01, 2018 at 02:03:41PM -0600, > Paul Ebersman wrote > > As long as ISPs don't actually disallow running of recursive servers > > That would be a terrible violation of network neutrality. I hope that > such ISP will go bankrupt. On the contrary: it will enable them to collect more usage statistics and from that sell more directed advertising. They will make MORE money off doing so. And so they will. - Brian From bortzmeyer at nic.fr Tue Apr 3 10:09:27 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 3 Apr 2018 12:09:27 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: <20180403100119.GA30206@meow.BKantor.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <20180403095436.t5gleuzzgv7xutjf@nic.fr> <20180403100119.GA30206@meow.BKantor.net> Message-ID: <20180403100927.pzlzju3zdeao4wuh@nic.fr> On Tue, Apr 03, 2018 at 03:01:19AM -0700, Brian Kantor wrote a message of 12 lines which said: > > That would be a terrible violation of network neutrality. I hope > > that such ISP will go bankrupt. > > On the contrary: it will enable them to collect more usage > statistics and from that sell more directed advertising. They will > make MORE money off doing so. And so they will. Then, I'm going to stop reading NANOG and go to the movie instead. Because, in the movies, the bad guys lose. From saku at ytti.fi Tue Apr 3 10:16:53 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 3 Apr 2018 13:16:53 +0300 Subject: NG Firewalls & IPv6 In-Reply-To: References: Message-ID: Done Checkpoint, Netscreen, SRX , iptables, nftables IPv6 FW all with dynamic routing, but only under extreme duress, like I'm sure everyone who is forced to touch stateful firewalls. Send help. Seems to me this has mostly worked for over decade, worked in context where stateful FW can be said to work at all. Of course like in every other context, IPv6 is second class citizen, so you're going to find more bugs, as less people are using the feature, there are less people doing bug scrubbing and fewer people bridging feature gaps. This isn't going to go away any time soon. On 3 April 2018 at 03:28, David Hubbard wrote: > I’ve been doing dual stack through Fortinet products for many years without issue. Well, no issue from a technical perspective. Sometimes you have to dig for a bit to find the equivalent v6 CLI commands, and occasionally there’s GUI stuff missing that requires CLI where the v4 equivalent didn’t, but not a bad experience overall. Does v6 vpn’s great too. Haven’t delved into dynamic routing protocols on them so can’t speak to that. Happy to answer questions. > > David > ________________________________ > From: NANOG on behalf of Joe Klein > Sent: Monday, April 2, 2018 6:58:14 PM > To: NANOG list > Subject: NG Firewalls & IPv6 > > All, > > At security and network tradeshows over the last 15 years, I have asked > companies if their products supported "IPv6". They all claimed they did, > but were unable to verify any successful installations. Later they told me > it was on their "Roadmap" but were unable to provide an estimated year, > because it was a trade secret. > > Starting this last year at BlackHat US, I again visited every product > booth, asking if their products supported dual-stack or IPv6 only > operations. Receiving only the same unsupported answers, I decided to focus > on one product category. > > To the gurus of the NANOG community, What are your experiences with > installing and managing Next Generations firewalls? Do they support IPv6 > only environments? Details? Stories? > > If you prefer not to disparage those poor product companies, please contact > me off the list. > > Thanks, > > Joe Klein > > "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) > PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 -- ++ytti From Brian at ampr.org Tue Apr 3 10:24:39 2018 From: Brian at ampr.org (Brian Kantor) Date: Tue, 3 Apr 2018 03:24:39 -0700 Subject: Yet another Quadruple DNS? In-Reply-To: <20180403100927.pzlzju3zdeao4wuh@nic.fr> References: <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <20180403095436.t5gleuzzgv7xutjf@nic.fr> <20180403100119.GA30206@meow.BKantor.net> <20180403100927.pzlzju3zdeao4wuh@nic.fr> Message-ID: <20180403102439.GA30677@meow.BKantor.net> On Tue, Apr 03, 2018 at 12:09:27PM +0200, Stephane Bortzmeyer wrote: > On Tue, Apr 03, 2018 at 03:01:19AM -0700, > Brian Kantor wrote > a message of 12 lines which said: > > > > That would be a terrible violation of network neutrality. I hope > > > that such ISP will go bankrupt. > > > > On the contrary: it will enable them to collect more usage > > statistics and from that sell more directed advertising. They will > > make MORE money off doing so. And so they will. > > Then, I'm going to stop reading NANOG and go to the movie > instead. Because, in the movies, the bad guys lose. Yes, I'm afraid that the situation is now like that of commercial television - those who were the clients are now the product, and the real paying customer is the advertisers. - Brian From sthaug at nethelp.no Tue Apr 3 10:29:48 2018 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 03 Apr 2018 12:29:48 +0200 (CEST) Subject: Yet another Quadruple DNS? In-Reply-To: <20180403095436.t5gleuzzgv7xutjf@nic.fr> References: <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <20180403095436.t5gleuzzgv7xutjf@nic.fr> Message-ID: <20180403.122948.71163434.sthaug@nethelp.no> > > This also ignores the shift if every house in the world did its own > > recursion. TLD servers and auth servers all over the world would > > have to massively up their capacity to cope. > > With my TLD operator hat, I tend to say it is not a problem, we > already have a lot of extra capacity, to handle dDoS. > > > As long as ISPs don't actually disallow running of recursive servers > > That would be a terrible violation of network neutrality. I hope that > such ISP will go bankrupt. With my ISP hat on: I see no problem with this as long as the resolver is not open to the Internet. There are unfortunately plenty of home user equipment with an open DNS proxy (probably also some resolvers). This *will* be misused. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jean at ddostest.me Tue Apr 3 10:45:02 2018 From: jean at ddostest.me (Jean | ddostest.me) Date: Tue, 3 Apr 2018 06:45:02 -0400 Subject: NG Firewalls & IPv6 In-Reply-To: References: Message-ID: <679cea8d-8f39-3068-8875-ec4f9e7dc589@ddostest.me> If by NextGen you meant performance, then I recommend to have a look at kipfw over Netmap driver on a FreeBSD 11 box. You buy a couple of Chelsio 40 Gbps or 100 Gbps NIC and you are in business. It was mentioned here in NANOG couple of years ago. Very good stuff, but you will need to invest a bit of time in writing your own scripts. It's a kind of bridging firewall though, so you can't route through it IIRC. If by NextGen you meant features riched, then don't go this way. ;) Jean On 04/03/2018 06:16 AM, Saku Ytti wrote: > Done Checkpoint, Netscreen, SRX , iptables, nftables IPv6 FW all with > dynamic routing, but only under extreme duress, like I'm sure everyone > who is forced to touch stateful firewalls. Send help. > > Seems to me this has mostly worked for over decade, worked in context > where stateful FW can be said to work at all. Of course like in every > other context, IPv6 is second class citizen, so you're going to find > more bugs, as less people are using the feature, there are less people > doing bug scrubbing and fewer people bridging feature gaps. This isn't > going to go away any time soon. > > On 3 April 2018 at 03:28, David Hubbard wrote: >> I’ve been doing dual stack through Fortinet products for many years without issue. Well, no issue from a technical perspective. Sometimes you have to dig for a bit to find the equivalent v6 CLI commands, and occasionally there’s GUI stuff missing that requires CLI where the v4 equivalent didn’t, but not a bad experience overall. Does v6 vpn’s great too. Haven’t delved into dynamic routing protocols on them so can’t speak to that. Happy to answer questions. >> >> David >> ________________________________ >> From: NANOG on behalf of Joe Klein >> Sent: Monday, April 2, 2018 6:58:14 PM >> To: NANOG list >> Subject: NG Firewalls & IPv6 >> >> All, >> >> At security and network tradeshows over the last 15 years, I have asked >> companies if their products supported "IPv6". They all claimed they did, >> but were unable to verify any successful installations. Later they told me >> it was on their "Roadmap" but were unable to provide an estimated year, >> because it was a trade secret. >> >> Starting this last year at BlackHat US, I again visited every product >> booth, asking if their products supported dual-stack or IPv6 only >> operations. Receiving only the same unsupported answers, I decided to focus >> on one product category. >> >> To the gurus of the NANOG community, What are your experiences with >> installing and managing Next Generations firewalls? Do they support IPv6 >> only environments? Details? Stories? >> >> If you prefer not to disparage those poor product companies, please contact >> me off the list. >> >> Thanks, >> >> Joe Klein >> >> "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) >> PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 > > > From rod.beck at unitedcablecompany.com Tue Apr 3 13:55:08 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 3 Apr 2018 13:55:08 +0000 Subject: New DNS Service Message-ID: https://techxplore.com/news/2018-04-dns-privacy.html Not associated with Cloudflare in any way. Regards, Roderick. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com New York City & Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From andy at newslink.com Tue Apr 3 14:05:52 2018 From: andy at newslink.com (Andy Ringsmuth) Date: Tue, 3 Apr 2018 09:05:52 -0500 Subject: New DNS Service In-Reply-To: References: Message-ID: <1C5C6B69-6662-4DD9-8D68-0BF00219EB6D@newslink.com> > On Apr 3, 2018, at 8:55 AM, Rod Beck wrote: > > https://techxplore.com/news/2018-04-dns-privacy.html > > > Not associated with Cloudflare in any way. > > > Regards, > > > Roderick. > Mildly interesting but very much old news. The new Cloudflare DNS has been discussed extensively right here on NANOG for the last few days. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From rod.beck at unitedcablecompany.com Tue Apr 3 14:06:49 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 3 Apr 2018 14:06:49 +0000 Subject: New DNS Service In-Reply-To: <79E31D85-2178-43FF-9058-7D5B5E3578A5@andyring.com> References: , <79E31D85-2178-43FF-9058-7D5B5E3578A5@andyring.com> Message-ID: And any consensus regarding the service? My layman question is how does this provide privacy? The routers still need to know the IP address of the far end point. I would assume that it would be easy to deduce the domain name from the IP address. - R. ________________________________ From: Andy Ringsmuth Sent: Tuesday, April 3, 2018 4:03 PM To: Rod Beck Cc: nanog at nanog.org Subject: Re: New DNS Service > On Apr 3, 2018, at 8:55 AM, Rod Beck wrote: > > https://techxplore.com/news/2018-04-dns-privacy.html [https://3c1703fe8d.site.internapcdn.net/newman/gfx/news/hires/2018/dnsservicean.jpg] DNS service announced, puts privacy first techxplore.com A new service that is offering privacy protection when you browse the web was announced Sunday. The security company Cloudflare is delivering a consumer DNS service called 1.1.1.1. > > > Not associated with Cloudflare in any way. > > > Regards, > > > Roderick. > Mildly interesting but very much old news. The new Cloudflare DNS has been discussed extensively right here on NANOG for the last few days. -Andy From andy at newslink.com Tue Apr 3 14:12:47 2018 From: andy at newslink.com (Andy Ringsmuth) Date: Tue, 3 Apr 2018 09:12:47 -0500 Subject: New DNS Service In-Reply-To: References: <79E31D85-2178-43FF-9058-7D5B5E3578A5@andyring.com> Message-ID: On Apr 3, 2018, at 9:06 AM, Rod Beck wrote: > > And any consensus regarding the service? My layman question is how does this provide privacy? The routers still need to know the IP address of the far end point. I would assume that it would be easy to deduce the domain name from the IP address. > > - R. > > > From: Andy Ringsmuth > Sent: Tuesday, April 3, 2018 4:03 PM > To: Rod Beck > Cc: nanog at nanog.org > Subject: Re: New DNS Service > > > > On Apr 3, 2018, at 8:55 AM, Rod Beck wrote: > > > > https://techxplore.com/news/2018-04-dns-privacy.html > > DNS service announced, puts privacy first > techxplore.com > A new service that is offering privacy protection when you browse the web was announced Sunday. The security company Cloudflare is delivering a consumer DNS service called 1.1.1.1. > > > > > > > Not associated with Cloudflare in any way. > > > > > > Regards, > > > > > > Roderick. > > > > Mildly interesting but very much old news. The new Cloudflare DNS has been discussed extensively right here on NANOG for the last few days. > > > -Andy A couple points, Rod: 1. I believe bottom posting is preferred here. 2. Well, yeah, it’s easy to go “backwards” with DNS/IP addresses. You can do it from any command line interface. That’s not the point here with Cloudflare’s DNS, or other publicly available DNS services. When you default to your ISP’s DNS servers, it’s easy for them to tie DNS requests to a particular customer (you) and monetize (share, sell, etc.) that information. What I believe Cloudflare is saying with their DNS service is “Hey, we won’t do that.” -Andy From list-nanog2 at dragon.net Tue Apr 3 14:21:02 2018 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Tue, 03 Apr 2018 08:21:02 -0600 Subject: Yet another Quadruple DNS? In-Reply-To: <20180403095436.t5gleuzzgv7xutjf@nic.fr> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <20180403095436.t5gleuzzgv7xutjf@nic.fr> Message-ID: <20180403142102.B61AA54D5C2@fafnir.remote.dragon.net> ebersman> And EDNS client subnet mostly works. bortzmeyer> It is awful, privacy-wise, complicates the cache a lot and bortzmeyer> seriously decreases hit rate in cache (since the key to a bortzmeyer> cached resource is no longer type+name but bortzmeyer> type+name+source_address). I was trying to be kind. Yes. It was a hack that solved a problem for a particular pair of CDN and anycast resolver but tends to be a bad idea for much of the world. But it's there and does sometimes improve CDN performance. I seem to recall that quad9 has (or will shortly) different IPs so you can choose if you want to have ECS in your queries or not. bortzmeyer> It is not just an issue of knowledge and skills. Even if you bortzmeyer> have both, you may lack time, and prefer a shrink-wrapped bortzmeyer> solution. The future is in "boxes" which are both bortzmeyer> ready-to-use (for the guy who lacks sysadmin skills, and/or bortzmeyer> lacks time) and open (for the tinkerer). The Turris Omnia bortzmeyer> is a very good example. Indeed. The vast majority of the world doesn't even know DNS exists, much less wants to dive into all sorts of obscure settings. They want to go to the local big-box electronics store and buy a "solution". And the Turris box is a great solution but way more than most consumers will spend. I have hopes the new Turris modular approach will mean a lower price point so we have more of these and less cheap/crappy CPEs on the internet. In the pipe dream category, it would be great to think that as IoT becomes unavoidable, we'll get more boxes that do auto-update. But I'm not holding my breath... From rsk at gsp.org Tue Apr 3 14:54:34 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 3 Apr 2018 10:54:34 -0400 Subject: Yet another Quadruple DNS? In-Reply-To: <20180403142102.B61AA54D5C2@fafnir.remote.dragon.net> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <20180403095436.t5gleuzzgv7xutjf@nic.fr> <20180403142102.B61AA54D5C2@fafnir.remote.dragon.net> Message-ID: <20180403145434.GA19936@gsp.org> On Tue, Apr 03, 2018 at 08:21:02AM -0600, Paul Ebersman wrote: > In the pipe dream category, it would be great to think that as IoT > becomes unavoidable, we'll get more boxes that do auto-update. Watch what you wish for: you might get it. The number of attack/abuse vectors (and the severity of their consequences for security and privacy) involved in doing auto-update may rival those involved in not doing auto-update. ---rsk From bortzmeyer at nic.fr Tue Apr 3 15:04:02 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 3 Apr 2018 17:04:02 +0200 Subject: Yet another Quadruple DNS? In-Reply-To: <20180403145434.GA19936@gsp.org> References: <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <20180403095436.t5gleuzzgv7xutjf@nic.fr> <20180403142102.B61AA54D5C2@fafnir.remote.dragon.net> <20180403145434.GA19936@gsp.org> Message-ID: <20180403150402.7jv34fnxd3d6vlv2@nic.fr> On Tue, Apr 03, 2018 at 10:54:34AM -0400, Rich Kulawiec wrote a message of 10 lines which said: > Watch what you wish for: you might get it. The number of > attack/abuse vectors (and the severity of their consequences for > security and privacy) involved in doing auto-update may rival those > involved in not doing auto-update. Also, there is the risk of getting updates that will disable some features, if there is a change in the commercial strategy of the vendor . All these risks are documented in RFC 8240, a highly recommended reading. From sethm at rollernet.us Tue Apr 3 15:21:49 2018 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 3 Apr 2018 08:21:49 -0700 Subject: From Nov 2017... In-Reply-To: References: <5AC2E5CF.4020508@hawaii.edu> <5AC31F0B.1080903@hawaii.edu> <96FDCBF9-0BAE-4CA5-AD66-48FB178257FD@pch.net> <5AC3252F.7010501@hawaii.edu> Message-ID: On 4/3/18 12:15 AM, Bill Woodcock wrote: > Ok, sorry if I was being overly persnickety. My apologies. I’ve been spending too much time answering questions on “social media” and it’s making me antisocial. Commenting on social media is like having to write a dissertation perfectly with your first draft in 5 seconds. From ler762 at gmail.com Tue Apr 3 15:25:13 2018 From: ler762 at gmail.com (Lee) Date: Tue, 3 Apr 2018 11:25:13 -0400 Subject: New DNS Service In-Reply-To: References: <79E31D85-2178-43FF-9058-7D5B5E3578A5@andyring.com> Message-ID: On 4/3/18, Rod Beck wrote: > And any consensus regarding the service? My layman question is how does this > provide privacy? You have to look for it & know what you're looking for: https://developers.cloudflare.com/1.1.1.1/dns-over-https/ https://developers.cloudflare.com/1.1.1.1/dns-over-tls/ > The routers still need to know the IP address of the far > end point. I would assume that it would be easy to deduce the domain name > from the IP address. It depends. If the web site is hosted on.. let's say cloudflare, there could be hundreds of names pointing to the same IP address. Lee From list-nanog2 at dragon.net Tue Apr 3 15:30:02 2018 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Tue, 03 Apr 2018 09:30:02 -0600 Subject: Yet another Quadruple DNS? In-Reply-To: <20180403145434.GA19936@gsp.org> References: <149e01d3c6c0$9b9bdd20$d2d39760$@payam124.com> <1522541287.2007090.1322515112.66A3D1DE@webmail.messagingengine.com> <20180401200341.EAAED53DCBB@fafnir.remote.dragon.net> <20180403095436.t5gleuzzgv7xutjf@nic.fr> <20180403142102.B61AA54D5C2@fafnir.remote.dragon.net> <20180403145434.GA19936@gsp.org> Message-ID: <20180403153002.46FF354DD54@fafnir.remote.dragon.net> ebersman> In the pipe dream category, it would be great to think that as ebersman> IoT becomes unavoidable, we'll get more boxes that do ebersman> auto-update. rsk> Watch what you wish for: you might get it. The number of rsk> attack/abuse vectors (and the severity of their consequences for rsk> security and privacy) involved in doing auto-update may rival those rsk> involved in not doing auto-update. I used to hate auto-update but after doing some large scale consumer work, less than I used to. It's all "pick your poison". As Stephane points out too, all sorts of issues patching vs not patching. I'm thinking the "let's go to the movies" idea is looking better all the time... From jhellenthal at dataix.net Tue Apr 3 15:42:41 2018 From: jhellenthal at dataix.net (Jason Hellenthal) Date: Tue, 3 Apr 2018 10:42:41 -0500 Subject: New DNS Service In-Reply-To: References: <79E31D85-2178-43FF-9058-7D5B5E3578A5@andyring.com> Message-ID: Like a wildcard DNS entry ! -- The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Apr 3, 2018, at 10:25, Lee wrote: > > It depends. If the web site is hosted on.. let's say cloudflare, > there could be hundreds of names pointing to the same IP address. > > Lee From blakangel at gmail.com Mon Apr 2 15:53:56 2018 From: blakangel at gmail.com (blakangel at gmail.com) Date: Mon, 02 Apr 2018 08:53:56 -0700 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> Message-ID: <5AC25214.9050909@gmail.com> From lux+mailinglists at melted.me Mon Apr 2 18:58:20 2018 From: lux+mailinglists at melted.me (Rhys Williams) Date: Mon, 02 Apr 2018 18:58:20 +0000 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: <20180402153537.GS31411@dilbert.slimey.org> References: <20180402153537.GS31411@dilbert.slimey.org> <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> Message-ID: Yep, Because you should have been setting up your networks correctly in the first place. There's plenty of private space assigned, use it. Regards, Rhys Williams April 2, 2018 4:54 PM, "Simon Lockhart" wrote: > and now suddenly it's our responsibility to make significant changes to live > infrastructures just so they can continue to look clever with the IP address. From jcrowe215 at gmail.com Tue Apr 3 02:43:03 2018 From: jcrowe215 at gmail.com (J Crowe) Date: Mon, 2 Apr 2018 22:43:03 -0400 Subject: From Nov 2017... In-Reply-To: <56998e3a-93bf-2b00-3fe8-64718294af24@rollernet.us> References: <5AC2E5CF.4020508@hawaii.edu> <56998e3a-93bf-2b00-3fe8-64718294af24@rollernet.us> Message-ID: That database could possibly be ingested and used locally. Traffic may not even be traversing to the database hosted by IBM. At least they are open about where they are getting the data that allows for blocking to certain FQDNs. On Mon, Apr 2, 2018 at 10:36 PM, Seth Mattinen wrote: > On 4/2/18 7:24 PM, Robert Mathews (OSIA) wrote: > >> To be clear..... >> >> *DNS resolver 9.9.9.9 will check requests against IBM threat database* >> > > > To be clear on what? That an IBM database is queried, just like it says on > their website? That doesn't mean they are recording who is making what > requests. > From george.skorup at cbcast.com Tue Apr 3 05:57:21 2018 From: george.skorup at cbcast.com (George Skorup) Date: Tue, 3 Apr 2018 00:57:21 -0500 Subject: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london In-Reply-To: References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> <1b15ef27-00db-8d1d-b6ab-bef7840b03a4@rivervalleyinternet.net> Message-ID: <14aa4d81-389b-ae75-c42d-5f912060379e@cbcast.com> 1.1.1.1 not usable via Windstream peering in Chicago. # traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets ...  3  be4.agr01.chcg02-il.us.windstream.net (40.136.99.22)  5.158 ms 5.116 ms  7.565 ms  4  ae13-0.cr01.chcg01-il.us.windstream.net (40.136.99.44)  4.673 ms  4.644 ms  4.600 ms  5  et8-0-0-0.cr02.dlls01-tx.us.windstream.net (40.128.10.135) 27.136 ms  27.099 ms  27.053 ms  6  xe0-2-3-0.cr02.dnvt01-co.us.windstream.net (40.136.97.125) 29.075 ms  28.381 ms  28.336 ms  7  xe3-3-1-0.pe03.dums01-tx.us.windstream.net (173.189.57.195) 46.121 ms  46.193 ms  46.148 ms  8  * * *  9  * * * 10  * * * 11  * * * 12  * * * 13  *^C # ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=248 time=43.2 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=248 time=43.9 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=248 time=42.8 ms ^C --- 1.1.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 42.892/43.344/43.915/0.489 ms # nslookup > server 1.1.1.1 Default server: 1.1.1.1 Address: 1.1.1.1#53 > google.com ;; connection timed out; trying next origin ;; connection timed out; no servers could be reached From amp at transtelco.net Tue Apr 3 16:01:19 2018 From: amp at transtelco.net (Alejandra Moreno) Date: Tue, 3 Apr 2018 10:01:19 -0600 Subject: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london In-Reply-To: References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> <1b15ef27-00db-8d1d-b6ab-bef7840b03a4@rivervalleyinternet.net> Message-ID: Great article! Thanks for sharing :) On Mon, Apr 2, 2018 at 11:12 PM, Hank Nussbacher wrote: > On 03/04/2018 01:39, Matt Hoppes wrote: > > You might be interested in these links which compare the services: > https://medium.com/@nykolas.z/dns-resolvers-performance- > compared-cloudflare-x-google-x-quad9-x-opendns-149e803734e5 > https://webxtrakt.com/public-dns-performance > > -Hank > > > So in all this discussion, what I'm finding interesting is that > > 8.8.8.8 is actually more hops away from me than either 9.9.9.9 or 1.1.1.1 > > > > On 4/2/18 6:06 PM, Seth Mattinen wrote: > >> On 4/2/18 14:58, Marty Strong via NANOG wrote: > >>> Routing from ~150 locations, plenty of redundancy. > >>> > >>> https://www.cloudflare.com/network/ > >> > >> > >> I recommend 9.9.9.9 to people (if they must use a public resolver) > >> because Quad9/PCH serves local markets of all sizes with anycast > >> nodes and peering, not just "major markets". Since I'm not in a major > >> market I want to support those who support the small markets that are > >> overlooked by the big guys. > > > > From spencer at intentionet.com Mon Apr 2 18:35:20 2018 From: spencer at intentionet.com (Spencer Fraint) Date: Mon, 2 Apr 2018 11:35:20 -0700 Subject: Network Info Anonymizer Message-ID: Sharing network configuration files (e.g. to get help debugging) can be quite tricky because they contain sensitive information. At the same time, simply removing the sensitive information (e.g. removing or changing all IP addresses) removes important structure from the files, defeating the purpose of sharing. We created Netconan to help. Netconan is an open source Python tool that anonymizes sensitive network information from text files, while preserving important structure. For example: it can take in router configuration files and remove passwords and anonymize IP addresses, while preserving IP address relationships (prefixes/subnets that matched before anonymization will still match after anonymization). Check it out on PyPI (https://pypi.python.org/pypi/netconan/) or GitHub ( https://github.com/intentionet/netconan) and let us know what you think! Thanks, Spencer From list at satchell.net Tue Apr 3 17:34:14 2018 From: list at satchell.net (Stephen Satchell) Date: Tue, 3 Apr 2018 10:34:14 -0700 Subject: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE In-Reply-To: References: <20180402153537.GS31411@dilbert.slimey.org> <20180402150821.GA24937@cmadams.net> <20180402151748.222E423FB428@ary.qy> Message-ID: <96bf518a-1b7f-aab3-d786-0735f43a02b2@satchell.net> On 04/02/2018 11:58 AM, Rhys Williams wrote: > Yep, Because you should have been setting up your networks correctly in the first place. There's plenty of private space assigned, use it. > > Regards, > > Rhys Williams > > April 2, 2018 4:54 PM, "Simon Lockhart" wrote: >> and now suddenly it's our responsibility to make significant changes to live >> infrastructures just so they can continue to look clever with the IP address. (ah, the top-posting) We go by the guidance of our vendors, and in this case the vendors are the one who made inappropriate use of Net 1. Many of them. So to put the onus on just Mr. Lockhart is plainly inappropriate. "Fixing the blame" is not going to take us very far. We as a community need to "fix the problem" -- that road will lead to proper functioning of all of our networks. Even the little ones. From lists-nanog at gadd.is Tue Apr 3 17:41:04 2018 From: lists-nanog at gadd.is (Jeremy L. Gaddis) Date: Tue, 3 Apr 2018 13:41:04 -0400 Subject: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london In-Reply-To: <20180403072230.07a785b7@echo.ms.redpill-linpro.com> References: <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> <20180403072230.07a785b7@echo.ms.redpill-linpro.com> Message-ID: <20180403174104.xiibec7y4j3el2v4@gadd.is> On 2018-04-03 (Tue) at 01:22 EDT, Tore Anderson wrote: > Any plans to support NSID and/or "hostname.bind" to allow clients to > identify which node is serving their requests? For example: FWIW: $ dig @1.0.0.1 id.server. CH TXT [...] ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1536 ;; QUESTION SECTION: ;id.server. CH TXT ;; ANSWER SECTION: id.server. 0 CH TXT "dtw01" [...] -- Jeremy L. Gaddis From a.slastenov at gmail.com Tue Apr 3 18:36:05 2018 From: a.slastenov at gmail.com (Andrey Slastenov) Date: Tue, 3 Apr 2018 21:36:05 +0300 Subject: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london In-Reply-To: <20180403174104.xiibec7y4j3el2v4@gadd.is> References: <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> <20180403072230.07a785b7@echo.ms.redpill-linpro.com> <20180403174104.xiibec7y4j3el2v4@gadd.is> Message-ID: <1D1FA9F3-955E-4288-920D-747C3A9C0EFD@gmail.com> Very interesting... I just heard about this problem today from one of my friend’s who supports of the big SP network (Russia). He got complains from one of their peer. After short investigation he found that they blackholing 1.1.1.1. When I asked him about the reasons, he can’t explain because as he said “it was there from the Big Bang times”. BR, Andrey Slastenov > 3 апр. 2018 г., в 20:41, Jeremy L. Gaddis написал(а): > >> On 2018-04-03 (Tue) at 01:22 EDT, Tore Anderson wrote: >> Any plans to support NSID and/or "hostname.bind" to allow clients to >> identify which node is serving their requests? For example: > > FWIW: > > $ dig @1.0.0.1 id.server. CH TXT > [...] > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1536 > ;; QUESTION SECTION: > ;id.server. CH TXT > > ;; ANSWER SECTION: > id.server. 0 CH TXT "dtw01" > [...] > > > -- > Jeremy L. Gaddis > From dhubbard at dino.hostasaurus.com Tue Apr 3 19:20:37 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 3 Apr 2018 19:20:37 +0000 Subject: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london In-Reply-To: <14aa4d81-389b-ae75-c42d-5f912060379e@cbcast.com> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> <4A5D72D3-5088-44CB-AAF0-B1387C13BE32@gt86car.org.uk> <1b15ef27-00db-8d1d-b6ab-bef7840b03a4@rivervalleyinternet.net> <14aa4d81-389b-ae75-c42d-5f912060379e@cbcast.com> Message-ID: <0684D86F-94A2-4A9E-A543-C4389D300ABC@dino.hostasaurus.com> I'm finding it unreachable from at least one Level 3 router. I'm seeing behavior which makes me suspect 1.1.1.1/32 has been incorrectly defined an interface IP on that device; one of our locations gets an immediate ping response for 1.1.1.1, and a traceroute of one hop, which is that first upstream hop. 1.0.0.1 is reachable like normal across several hops. On 4/3/18, 1:36 PM, "NANOG on behalf of George Skorup" wrote: 1.1.1.1 not usable via Windstream peering in Chicago. # traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets ... 3 be4.agr01.chcg02-il.us.windstream.net (40.136.99.22) 5.158 ms 5.116 ms 7.565 ms 4 ae13-0.cr01.chcg01-il.us.windstream.net (40.136.99.44) 4.673 ms 4.644 ms 4.600 ms 5 et8-0-0-0.cr02.dlls01-tx.us.windstream.net (40.128.10.135) 27.136 ms 27.099 ms 27.053 ms 6 xe0-2-3-0.cr02.dnvt01-co.us.windstream.net (40.136.97.125) 29.075 ms 28.381 ms 28.336 ms 7 xe3-3-1-0.pe03.dums01-tx.us.windstream.net (173.189.57.195) 46.121 ms 46.193 ms 46.148 ms 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 *^C # ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=248 time=43.2 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=248 time=43.9 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=248 time=42.8 ms ^C --- 1.1.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 42.892/43.344/43.915/0.489 ms # nslookup > server 1.1.1.1 Default server: 1.1.1.1 Address: 1.1.1.1#53 > google.com ;; connection timed out; trying next origin ;; connection timed out; no servers could be reached From bjorn at mork.no Tue Apr 3 20:00:47 2018 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 03 Apr 2018 22:00:47 +0200 Subject: Why doesn't "Cloudflare 1.1.1.1" compress root answers? Message-ID: <87a7ukxdow.fsf@miraculix.mork.no> At first I thought they had disabled compression: bjorn at miraculix:~$ dig . ns @1.1.1.1|grep SIZE ;; MSG SIZE rcvd: 431 bjorn at miraculix:~$ dig . ns @8.8.8.8|grep SIZE ;; MSG SIZE rcvd: 239 bjorn at miraculix:~$ dig . ns @9.9.9.9|grep SIZE ;; MSG SIZE rcvd: 239 But then I noticed that they *do* compress other names: bjorn at miraculix:~$ dig net ns @1.1.1.1|grep SIZE ;; MSG SIZE rcvd: 253 bjorn at miraculix:~$ dig net ns @8.8.8.8|grep SIZE ;; MSG SIZE rcvd: 253 bjorn at miraculix:~$ dig net ns @9.9.9.9|grep SIZE ;; MSG SIZE rcvd: 253 Which just makes it even more confusing. What's so special about root? Except for the obvious :-) Bjørn From mehmet at akcin.net Tue Apr 3 20:20:26 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Tue, 3 Apr 2018 16:20:26 -0400 Subject: Why doesn't "Cloudflare 1.1.1.1" compress root answers? In-Reply-To: <87a7ukxdow.fsf@miraculix.mork.no> References: <87a7ukxdow.fsf@miraculix.mork.no> Message-ID: I am sure they will after this ;) On Tue, Apr 3, 2018 at 4:00 PM, Bjørn Mork wrote: > At first I thought they had disabled compression: > > bjorn at miraculix:~$ dig . ns @1.1.1.1|grep SIZE > ;; MSG SIZE rcvd: 431 > bjorn at miraculix:~$ dig . ns @8.8.8.8|grep SIZE > ;; MSG SIZE rcvd: 239 > bjorn at miraculix:~$ dig . ns @9.9.9.9|grep SIZE > ;; MSG SIZE rcvd: 239 > > > But then I noticed that they *do* compress other names: > > bjorn at miraculix:~$ dig net ns @1.1.1.1|grep SIZE > ;; MSG SIZE rcvd: 253 > bjorn at miraculix:~$ dig net ns @8.8.8.8|grep SIZE > ;; MSG SIZE rcvd: 253 > bjorn at miraculix:~$ dig net ns @9.9.9.9|grep SIZE > ;; MSG SIZE rcvd: 253 > > > Which just makes it even more confusing. What's so special about root? > Except for the obvious :-) > > > > Bjørn > > From dmburgess at linktechs.net Tue Apr 3 21:46:27 2018 From: dmburgess at linktechs.net (Dennis Burgess) Date: Tue, 3 Apr 2018 21:46:27 +0000 Subject: COX contact Message-ID: <3e413bbf39bc475896d98e4735a973f8@linktechs.net> Can I get a network engineer from COX to give me a call or email me please :) I have a routing issue that I need taken a look at.. 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 Create Wireless Coverage's with www.towercoverage.com From surfer at mauigateway.com Tue Apr 3 22:07:27 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 3 Apr 2018 15:07:27 -0700 Subject: Yet another Quadruple DNS? Message-ID: <20180403150727.8D655BCA@m0117566.ppops.net> --- bortzmeyer at nic.fr wrote: From: Stephane Bortzmeyer Rich Kulawiec wrote a message of 10 lines which said: > Watch what you wish for: you might get it. The number of > attack/abuse vectors (and the severity of their consequences for > security and privacy) involved in doing auto-update may rival those > involved in not doing auto-update. Also, there is the risk of getting updates that will disable some features, if there is a change in the commercial strategy of the vendor . All these risks are documented in RFC 8240, a highly recommended reading. ------------------------------------------- Regarding the HP example story, won't natural attrition fix this? My stuff has been in storage for well over a year for various reasons and if I pull out my HP printer (which has non-HP cartridges) and it does this to me, I surely won't get another one. I'm also sure I'd be the norm on this as it would anger other non-technical HP customers, as well. (I was on the fence with HP anyway as they try to take over my equipment too much) scott ps. Who knows, I don't let my printer talk outside my network anyway, so maybe I didn't get the update. From bill at herrin.us Tue Apr 3 22:32:19 2018 From: bill at herrin.us (William Herrin) Date: Tue, 3 Apr 2018 18:32:19 -0400 Subject: Are any of you starting to get AI robocalls? Message-ID: Howdy. Have any of you started to get AI robocalls? I've had a couple of calls recently where I get the connect silence of a predictive dialer followed by a woman speaking with call center background noise. She gives her name and asks how I'm doing. The first time it happened it seemed off for reasons I can't quite articulate, so I asked: "Are you a robot or a person?" She responded "yes" and then launched in to a sales pitch. The next time I asked, "where can I direct your call?" She responded "that's good" and launched in to her pitch. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From math at sizone.org Tue Apr 3 22:48:30 2018 From: math at sizone.org (Ken Chase) Date: Tue, 3 Apr 2018 18:48:30 -0400 Subject: Are any of you starting to get AI robocalls? In-Reply-To: References: Message-ID: <20180403224830.GI20300@sizone.org> Just throw a dial tree plan in front of getting ahold of you. "Press 1 to speak to a human." this foils most dialers which wait for a human to answer before they throw anyone (anything?) on the line. They may also have the AI get through the unpleasantries before they stick a human on it. Many voip providers offer a dial tree. I have a provider with a snazzy web drag n drop tree construction system, so you dont need to learn m4/asterisk/linenoise and even directs SMS's to email for me. I've set it up for my wife and myself (hit 1 for me, 2 for her) and I use it on all my online ordering stuff because I know they'll be hacked sooner or later and my info leaked into the wild for abuse. I dont know how cell companies expect to be able to continue to offer any voice services with the lack of enforcement against robodialing - I get calls in the middle of the night (and have to leave my phone on for on-call from random customers I dont know the ph# for). Even though I give my direct cel # out to almost no one, I get 3-5 random calls a week. (I dont doubt that phone hacks are uploading people's contact lists to the cloud for further infection/robodials, as well as plain war-dial trawls). I have a spam contact with > 150 ph#s in it. (I need an app to share these and subscribe to autoblock but havent gotten a round tuit it yet.) Worse, they're spoofing real ph#s - I call back calls I didnt answer and they all claim they didnt call me - because a robodialer spoofed a legit ph# to avoid mass filter lists. (Beware ph#s that use your NXX - human gut reaction is to answer ph#s that look like your own supposedly, but its likely a robodial). All this boils my blood. I am not sure why/how spoofing ph#s is legal. I get sms mass spam too. Too much control is left in the sending side, need way better filtering tools on the receiver. Soon enough however I hope to just be able to dispense with voice communication and point customers at something else (even SMS would be better). Im not sure we're at the point you can enforce that without pissing off customers but we're close. (I dont support capital punishment for much, but this might be one thing... :) /kc On Tue, Apr 03, 2018 at 06:32:19PM -0400, William Herrin said: >Howdy. > >Have any of you started to get AI robocalls? I've had a couple of >calls recently where I get the connect silence of a predictive dialer >followed by a woman speaking with call center background noise. She >gives her name and asks how I'm doing. The first time it happened it >seemed off for reasons I can't quite articulate, so I asked: "Are you >a robot or a person?" She responded "yes" and then launched in to a >sales pitch. The next time I asked, "where can I direct your call?" >She responded "that's good" and launched in to her pitch. > >Regards, >Bill Herrin > > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Dirtside Systems ......... Web: -- Ken Chase - math at sizone.org Guelph Canada From joelja at bogus.com Tue Apr 3 22:58:39 2018 From: joelja at bogus.com (joel jaeggli) Date: Tue, 3 Apr 2018 15:58:39 -0700 Subject: Are any of you starting to get AI robocalls? In-Reply-To: References: Message-ID: <33a966e1-ac42-7a1e-e79b-d9d31bb88382@bogus.com> On 4/3/18 3:32 PM, William Herrin wrote: > Howdy. > > Have any of you started to get AI robocalls? I've had a couple of > calls recently where I get the connect silence of a predictive dialer > followed by a woman speaking with call center background noise. She > gives her name and asks how I'm doing. The first time it happened it > seemed off for reasons I can't quite articulate, so I asked: "Are you > a robot or a person?" She responded "yes" and then launched in to a > sales pitch. The next time I asked, "where can I direct your call?" > She responded "that's good" and launched in to her pitch. They're more in the domain of artificially stupid but yes. https://www.theverge.com/2018/1/1/16837814/robocall-spam-phone-call-increase-2017-ftc-report The anti spoofing/spam app I have that screens calls to several DIDs I have pointed at one phone reports a dozen or so calls per day. I would generally assume that the current rate will hasten the demise of the remaining pots services. > Regards, > Bill Herrin > > From jlewis at lewis.org Tue Apr 3 23:26:36 2018 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 3 Apr 2018 19:26:36 -0400 (EDT) Subject: Are any of you starting to get AI robocalls? In-Reply-To: <20180403224830.GI20300@sizone.org> References: <20180403224830.GI20300@sizone.org> Message-ID: On Tue, 3 Apr 2018, Ken Chase wrote: > All this boils my blood. I am not sure why/how spoofing ph#s is legal. I get > sms mass spam too. Whether or not its legal is irrelevant. It's trivial to do if your link to the PSTN is digital and you have a provider not filtering based on sent caller-id. It's kind of the PSTN version of the Internet's BCP-38 issue. All providers should be filtering based on "valid" caller-id...but so many don't do it, and the spoofing is nearly impossible to trace back to the origin, so those who do it can safely ignore other laws because they know they won't be caught. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From gerardo.perales at axtel.com.mx Tue Apr 3 23:46:22 2018 From: gerardo.perales at axtel.com.mx (Jose Gerardo Perales Soto) Date: Tue, 3 Apr 2018 23:46:22 +0000 Subject: CDN-provided caching platforms? In-Reply-To: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> References: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> Message-ID: Ericsson UDN https://www.ericsson.com/en/tech-innovation/offerings/udn/service-providers Gerardo -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Russell Berg Sent: lunes, 26 de marzo de 2018 08:26 p. m. To: nanog at nanog.org Subject: CDN-provided caching platforms? I work for a regional Midwestern US "Tier 2" ISP that provides both wholesale and enterprise Internet connectivity. We have caching platforms in place from the likes of Akamai, Google, Netflix, and Facebook; I was wondering if there are other CDN caching platforms out there we should be researching/deploying? PM me if more appropriate... TIA Russ Russell Berg Chief Technology Officer WIN / Airstream Communications (AS 11796) P: 715-832-3726 | C: 715-579-8227 www.wins.net ________________________________ NOTA: La información de este correo es de propiedad exclusiva y confidencial. Este mensaje es sólo para el destinatario señalado, si usted no lo es, destrúyalo de inmediato. Ninguna información aquí contenida debe ser entendida como dada o avalada por AXTEL, S.A.B. de C.V, sus subsidiarias o sus empleados, salvo cuando ello expresamente se indique. Es responsabilidad de quien recibe este correo de asegurarse que esté libre de virus, por lo tanto ni AXTEL, S.A.B. de C.V, sus subsidiarias ni sus empleados aceptan responsabilidad alguna. NOTE: The information in this email is proprietary and confidential. This message is for the designated recipient only, if you are not the intended recipient, you should destroy it immediately. Any information in this message shall not be understood as given or endorsed by AXTEL, S.A.B. de C.V, its subsidiaries or their employees, unless expressly so stated. It is the responsibility of the recipient to ensure that this email is virus free, therefore neither AXTEL, S.A.B. de C.V, its subsidiaries nor their employees accept any responsibility. From math at sizone.org Wed Apr 4 00:38:04 2018 From: math at sizone.org (Ken Chase) Date: Tue, 3 Apr 2018 20:38:04 -0400 Subject: Are any of you starting to get AI robocalls? In-Reply-To: References: <20180403224830.GI20300@sizone.org> Message-ID: <20180404003804.GJ20300@sizone.org> And revenues wont be impacted because few have a cell for voice anymore. With increasing data reliability we can move to voip on phones and provider of choice who offer proper filtering and our our own skill testing AI attendants (Im thinking something along the lines of 'unladen swallow'.) /kc On Tue, Apr 03, 2018 at 07:26:36PM -0400, Jon Lewis said: >On Tue, 3 Apr 2018, Ken Chase wrote: > >>All this boils my blood. I am not sure why/how spoofing ph#s is legal. I get >>sms mass spam too. > >Whether or not its legal is irrelevant. It's trivial to do if your link >to the PSTN is digital and you have a provider not filtering based on sent >caller-id. It's kind of the PSTN version of the Internet's BCP-38 issue. >All providers should be filtering based on "valid" caller-id...but so many >don't do it, and the spoofing is nearly impossible to trace back to the >origin, so those who do it can safely ignore other laws because they know >they won't be caught. > >---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > | therefore you are >_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -- Ken Chase - math at sizone.org Guelph Canada From aaron1 at gvtc.com Wed Apr 4 02:08:47 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 3 Apr 2018 21:08:47 -0500 Subject: CDN-provided caching platforms? In-Reply-To: <7149.1522164172@turing-police.cc.vt.edu> References: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> <7149.1522164172@turing-police.cc.vt.edu> Message-ID: <001b01d3cbb9$de974440$9bc5ccc0$@gvtc.com> I'm wondering if/when Amazon Prime Video will have a CDN system to roll-out to ISP's like OCA, FNA, GGC, etc Anyone here anything about Amazon Video or any other big names like that ? - Aaron -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of valdis.kletnieks at vt.edu Sent: Tuesday, March 27, 2018 10:23 AM To: Russell Berg Cc: nanog at nanog.org Subject: Re: CDN-provided caching platforms? On Tue, 27 Mar 2018 02:26:24 -0000, Russell Berg said: > I was wondering if there are other CDN caching platforms out there we > should be researching/deploying? Does traffic analysis show any other destinations that have enough traffic that caching might help? From telmnstr at 757.org Wed Apr 4 05:01:04 2018 From: telmnstr at 757.org (Ethan O'Toole) Date: Wed, 4 Apr 2018 01:01:04 -0400 (EDT) Subject: Are any of you starting to get AI robocalls? In-Reply-To: References: <20180403224830.GI20300@sizone.org> Message-ID: > do it, and the spoofing is nearly impossible to trace back to the origin, so > those who do it can safely ignore other laws because they know they won't be > caught. Forward to an 800, grab it from the ANI versus CID? - Ethan O'Toole From nanog at jima.us Wed Apr 4 05:44:54 2018 From: nanog at jima.us (Jima) Date: Tue, 3 Apr 2018 23:44:54 -0600 Subject: NG Firewalls & IPv6 In-Reply-To: References: Message-ID: <7E627496-4343-4B34-9EBB-94850A3D3FCD@jima.us> Hey Joe, I don't know how next-gen they'd be considered, but I've had reasonably good luck with Cisco ASA (v9+), and to a lesser degree Juniper ScreenOS (v6.3+). Modern-ish ASA does v6-only pretty well; ScreenOS has more v4-dependent nuances, that I've found. I do like the NAT64 support in ASA (although it sadly doesn't support the Well-Known Prefix) -- no love in ScreenOS, as far as I've ever found. - Jima > On Apr 2, 2018, at 16:58, Joe Klein wrote: > > All, > > At security and network tradeshows over the last 15 years, I have asked > companies if their products supported "IPv6". They all claimed they did, > but were unable to verify any successful installations. Later they told me > it was on their "Roadmap" but were unable to provide an estimated year, > because it was a trade secret. > > Starting this last year at BlackHat US, I again visited every product > booth, asking if their products supported dual-stack or IPv6 only > operations. Receiving only the same unsupported answers, I decided to focus > on one product category. > > To the gurus of the NANOG community, What are your experiences with > installing and managing Next Generations firewalls? Do they support IPv6 > only environments? Details? Stories? > > If you prefer not to disparage those poor product companies, please contact > me off the list. > > Thanks, > > Joe Klein > > "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) > PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 From spedersen.lists at gmail.com Wed Apr 4 14:44:30 2018 From: spedersen.lists at gmail.com (Sean Pedersen) Date: Wed, 4 Apr 2018 07:44:30 -0700 Subject: Are any of you starting to get AI robocalls? In-Reply-To: References: Message-ID: <001f01d3cc23$711e01f0$535a05d0$@gmail.com> Yep. Add it to the list of IRS scams, fake arrest warrants, credit repair, free vacations, etc. The rate of calls has increased dramatically in the past year, especially with the "neighborhood scam" where they spoof their CLID to a local area code and prefix + 0000 through 9999 and blast you with calls, trying to trick you into thinking it's someone local and thus important or legitimate. I have a second phone I use for work and on-call, so that goes on DND from 6PM to 6AM with a VIP list of people/numbers that can ring through. No problems there, and somehow that number isn't (yet) on anyone's list, so I don't get many calls. On my personal cell, I started to use an app called Hiya that has been pretty successful. It's available for both iPhone and Android. It powers a lot of the carrier-specific apps like AT&T Call Protect, but unlike them, it doesn't suck. It's a giant database of reports that rate calling numbers and classify them as fraud, scam, neighborhood spoofing, etc. and you can flag them or route them right to voicemail. The only time it doesn’t work is when it hasn't updated its list in a little while and a few sneak through. They just realized a premium version that added some features. I haven't explored it yet. Went from about 20 calls a week to almost nothing. Carriers seem to be either uncapable or unwilling to address the issue other than the occasional lip-service reply about "taking customer's $variable seriously." -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William Herrin Sent: Tuesday, April 3, 2018 3:32 PM To: nanog at nanog.org Subject: Are any of you starting to get AI robocalls? Howdy. Have any of you started to get AI robocalls? I've had a couple of calls recently where I get the connect silence of a predictive dialer followed by a woman speaking with call center background noise. She gives her name and asks how I'm doing. The first time it happened it seemed off for reasons I can't quite articulate, so I asked: "Are you a robot or a person?" She responded "yes" and then launched in to a sales pitch. The next time I asked, "where can I direct your call?" She responded "that's good" and launched in to her pitch. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From nanog at shankland.org Wed Apr 4 15:08:15 2018 From: nanog at shankland.org (Jim Shankland) Date: Wed, 4 Apr 2018 08:08:15 -0700 Subject: Are any of you starting to get AI robocalls? In-Reply-To: <001f01d3cc23$711e01f0$535a05d0$@gmail.com> References: <001f01d3cc23$711e01f0$535a05d0$@gmail.com> Message-ID: <8e7ec9ac-6edb-bc30-e9ac-07bbbb8f1da6@shankland.org> On 4/4/18 7:44 AM, Sean Pedersen wrote: > Yep. Add it to the list of IRS scams, fake arrest warrants, credit repair, free vacations, etc. The rate of calls has increased dramatically in the past year, especially with the "neighborhood scam" where they spoof their CLID to a local area code and prefix + 0000 through 9999 and blast you with calls, trying to trick you into thinking it's someone local and thus important or legitimate. > Let me also put in a good word for the Jolly Roger Telephone Co. (http://www.jollyrogertelco.com). Don't just defend, fight back. Jim From adamkennedy at watchcomm.net Wed Apr 4 15:26:43 2018 From: adamkennedy at watchcomm.net (Adam Kennedy) Date: Wed, 4 Apr 2018 11:26:43 -0400 Subject: NG Firewalls & IPv6 In-Reply-To: <7E627496-4343-4B34-9EBB-94850A3D3FCD@jima.us> References: <7E627496-4343-4B34-9EBB-94850A3D3FCD@jima.us> Message-ID: We've deployed about a dozen Sophos SG and XG firewalls with IPv6 on WAN, LAN and VPN with great success. The XG is the firmware with the more modern appearance and a couple latest-gen features. But the SG is just as "next gen" and still has good IPv6 capability. -- Adam Kennedy, Network & Systems Engineer adamkennedy at watchcomm.net *Watch Communications* (866) 586-1518 On Wed, Apr 4, 2018 at 1:44 AM, Jima wrote: > Hey Joe, > > I don't know how next-gen they'd be considered, but I've had reasonably > good luck with Cisco ASA (v9+), and to a lesser degree Juniper ScreenOS > (v6.3+). Modern-ish ASA does v6-only pretty well; ScreenOS has more > v4-dependent nuances, that I've found. > > I do like the NAT64 support in ASA (although it sadly doesn't support the > Well-Known Prefix) -- no love in ScreenOS, as far as I've ever found. > > - Jima > > > On Apr 2, 2018, at 16:58, Joe Klein wrote: > > > > All, > > > > At security and network tradeshows over the last 15 years, I have asked > > companies if their products supported "IPv6". They all claimed they did, > > but were unable to verify any successful installations. Later they told > me > > it was on their "Roadmap" but were unable to provide an estimated year, > > because it was a trade secret. > > > > Starting this last year at BlackHat US, I again visited every product > > booth, asking if their products supported dual-stack or IPv6 only > > operations. Receiving only the same unsupported answers, I decided to > focus > > on one product category. > > > > To the gurus of the NANOG community, What are your experiences with > > installing and managing Next Generations firewalls? Do they support IPv6 > > only environments? Details? Stories? > > > > If you prefer not to disparage those poor product companies, please > contact > > me off the list. > > > > Thanks, > > > > Joe Klein > > > > "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene > 1) > > PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 > From rwebb at ropeguru.com Wed Apr 4 16:06:49 2018 From: rwebb at ropeguru.com (Robert Webb) Date: Wed, 4 Apr 2018 16:06:49 +0000 Subject: NG Firewalls & IPv6 In-Reply-To: References: <7E627496-4343-4B34-9EBB-94850A3D3FCD@jima.us> Message-ID: Just don't plan on using dhcp-pd on any of those anytime soon. My understanding is that it is not even on the roadmap or even considered to have a need for it even though people have been wanting it for quite a while. Robert -----Original Message----- From: NANOG On Behalf Of Adam Kennedy via NANOG Sent: Wednesday, April 4, 2018 11:27 AM To: NANOG list Subject: Re: NG Firewalls & IPv6 We've deployed about a dozen Sophos SG and XG firewalls with IPv6 on WAN, LAN and VPN with great success. The XG is the firmware with the more modern appearance and a couple latest-gen features. But the SG is just as "next gen" and still has good IPv6 capability. -- Adam Kennedy, Network & Systems Engineer adamkennedy at watchcomm.net *Watch Communications* (866) 586-1518 On Wed, Apr 4, 2018 at 1:44 AM, Jima wrote: > Hey Joe, > > I don't know how next-gen they'd be considered, but I've had > reasonably good luck with Cisco ASA (v9+), and to a lesser degree > Juniper ScreenOS (v6.3+). Modern-ish ASA does v6-only pretty well; > ScreenOS has more v4-dependent nuances, that I've found. > > I do like the NAT64 support in ASA (although it sadly doesn't support > the Well-Known Prefix) -- no love in ScreenOS, as far as I've ever found. > > - Jima > > > On Apr 2, 2018, at 16:58, Joe Klein wrote: > > > > All, > > > > At security and network tradeshows over the last 15 years, I have > > asked companies if their products supported "IPv6". They all claimed > > they did, but were unable to verify any successful installations. > > Later they told > me > > it was on their "Roadmap" but were unable to provide an estimated > > year, because it was a trade secret. > > > > Starting this last year at BlackHat US, I again visited every > > product booth, asking if their products supported dual-stack or IPv6 > > only operations. Receiving only the same unsupported answers, I > > decided to > focus > > on one product category. > > > > To the gurus of the NANOG community, What are your experiences with > > installing and managing Next Generations firewalls? Do they support > > IPv6 only environments? Details? Stories? > > > > If you prefer not to disparage those poor product companies, please > contact > > me off the list. > > > > Thanks, > > > > Joe Klein > > > > "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, > > Scene > 1) > > PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 > From nanog-list at contactdaniel.net Tue Apr 3 20:39:24 2018 From: nanog-list at contactdaniel.net (Daniel Dent) Date: Tue, 3 Apr 2018 13:39:24 -0700 Subject: Cloudflare 1.1.1.1 public DNS broken w/ Xerox Phaser MFP In-Reply-To: <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> References: <20180401205952.wnfyvw7nobrc6not@gadd.is> <38AFCA0F-5978-4701-B680-F10E5FFC31B7@rivervalleyinternet.net> <7DB5FAC7-972A-4EB6-89D9-B305A723334F@cloudflare.com> <53B55D8A-FB82-4CA3-8E9D-72B2A4EFC0D3@cloudflare.com> Message-ID: <581274f2-a791-3605-7b12-70e222bb8284@ddent.net> On a Xerox Phaser 3635MFP printer running the latest firmware, when attempting to configure it to use 1.1.1.1 for DNS, it throws the following error: "The following Alternate DNS Server 1 addresses are not permitted: 1.1.1.1 and 255.255.255.255". I suspect this was intended to prevent people from putting in an "invalid" placeholder, but the assumption that 1.1.1.1 would never be an actual DNS server that somebody might actually wish to use appears to have been unwise. Daniel Dent https://www.danieldent.com On 2018-04-02 12:32 PM, Marty Strong via NANOG wrote: > Do you have one? > > Do you know what is causing it to fail? i.e. IP on internal interface etc. > > Regards, > Marty Strong > -------------------------------------- > Cloudflare - AS13335 > Network Engineer > marty at cloudflare.com > +44 7584 906 055 > smartflare (Skype) > > https://www.peeringdb.com/asn/13335 > >> On 2 Apr 2018, at 19:24, Rubens Kuhl wrote: >> >> D-Link DMG-6661 as well. >> >> >> Rubens >> >> >> On Mon, Apr 2, 2018 at 12:26 PM, Marty Strong via NANOG wrote: >> So far we know about a few CPEs which answer for 1.1.1.1 themselves: >> >> - Pace 5268 >> - Calix GigaCenter >> - Various Cisco Wifi access points >> >> If you know of others please send them my way so we can investigate. >> >> Regards, >> Marty Strong >> -------------------------------------- >> Cloudflare - AS13335 >> Network Engineer >> marty at cloudflare.com >> +44 7584 906 055 >> smartflare (Skype) >> >> https://www.peeringdb.com/asn/13335 >> >>> On 2 Apr 2018, at 16:16, Jason Kuehl wrote: >>> >>> Just like "S3 dependency check day" Thus begins "National 1.1.1.1 change >>> week" I've already around a few peaces of equipment sets with 1.1.1.1 >>> >>> On Mon, Apr 2, 2018 at 11:05 AM, Matt Hoppes < >>> mattlists at rivervalleyinternet.net> wrote: >>> >>>> Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this is >>>> causing odd issues. >>>> >>>>> On Apr 2, 2018, at 11:03, Darin Steffl wrote: >>>>> >>>>> I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my >>>> router >>>>> and not any further. When I enter the IP into my browser, it opens the >>>>> login page for my router. So it appears 1.1.1.1 is used as a loopback in >>>> my >>>>> Calix router. >>>>> >>>>> 1.0.0.1 goes to the proper place fine. >>>>> >>>>> On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis >>>>> wrote: >>>>> >>>>>> Greetings, >>>>>> >>>>>> If anyone at 7018 wants to pass a message along to the correct folks, >>>>>> please let them know that Cloudflare's new public DNS service (1.1.1.1) >>>>>> is completely unusable for at least some of AT&T's customers. >>>>>> >>>>>> There is apparently a bug with some CPE (including the 5268AC). From >>>>>> behind such CPE, the services at 1.1.1.1 are completely unreachable, >>>>>> whether via (ICMP) ping, DNS, or HTTPS. >>>>>> >>>>>> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns >>>>>> the following results: >>>>>> >>>>>> ping successful: icmp seq:0, time=2.364 ms >>>>>> ping successful: icmp seq:1, time=1.085 ms >>>>>> ping successful: icmp seq:2, time=1.160 ms >>>>>> ping successful: icmp seq:3, time=1.245 ms >>>>>> ping successful: icmp seq:4, time=0.739 ms >>>>>> >>>>>> RTTs to the CPE's default gateway are, at minimum, ~20 ms. >>>>>> >>>>>> A traceroute (using the same web-based diagnostic tool built-in to the >>>>>> CPE) reports, simply: >>>>>> >>>>>> traceroute 1.1.1.1 with: 64 bytes of data >>>>>> >>>>>> 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms >>>>>> >>>>>> I haven't bothered to report this to AT&T through the standard customer >>>>>> support channels (for reasons that should be obvious to anyone who has >>>>>> ever called AT&T's consumer/residential technical support) but if anyone >>>>>> at AT&T wants to pass the info along to the appropriate group, it would >>>>>> certainly be appreciated. >>>>>> >>>>>> Thanks, >>>>>> -Jeremy >>>>>> >>>>>> -- >>>>>> Jeremy L. Gaddis >>>>>> >>>>>> >>>>>> "The total budget at all receivers for solving senders' problems is >>>>>> $0. If you want them to accept your mail and manage it the way you >>>>>> want, send it the way the spec says to." --John Levine >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Darin Steffl >>>>> Minnesota WiFi >>>>> www.mnwifi.com >>>>> 507-634-WiFi >>>>> Like us on Facebook >>>>> >>> >>> >>> -- >>> Sincerely, >>> >>> Jason W Kuehl >>> Cell 920-419-8983 >>> jason.w.kuehl at gmail.com >> From don.thomasjacob at gmail.com Wed Apr 4 07:28:45 2018 From: don.thomasjacob at gmail.com (Don Thomas Jacob) Date: Wed, 4 Apr 2018 12:58:45 +0530 Subject: validating reachability via an ISP In-Reply-To: References: Message-ID: Hi, If you are fine with a commercial tool, Packet Design Route Explorer product supports peering analysis: BGP-RIB-Visualization-1.png is one among its features. https://www.packetdesign.com/solutions/peering-analysis/ Disclaimer: I work for Packet Design Thanks, Don - Don Thomas Jacob LinkedIn | Twitter On Thu, Mar 29, 2018 at 8:39 PM, Alexander Azimov wrote: > Hi Andy, > > You can use Qrator.Radar API: https://api.radar.qrator.net/. > The get-all-paths method will return the set of active paths for selected > prefix. > > > 2018-03-29 2:22 GMT+03:00 Andy Litzinger : > > > Hi all, > > I have an enterprise network and do not provide transit. In one of our > > datacenters we have our own prefixes and rely on two ISPs as BGP > neighbors > > to provide global reachability for our prefixes. One is a large regional > > provider and the other is a large global provider. > > > > Recently we took our link to the global provider offline to perform > > maintenance on our router. Nearly immediately we were hit with alerts > that > > our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted > our > > route had been withdrawn. We were not unreachable from every AS, but we > > certainly were from some of the largest. > > > > The root cause is that the our prefix is not being adequately > > re-distributed globally by the regional ISP. This is unexpected and we > are > > working through this with them now. > > > > My question is, how can I monitor global reachability for a prefix via > this > > or any specific provider I use over time? Are there various > route-servers > > I can programmatically query for my prefix and get results that include > AS > > paths? Then I could verify that an "acceptable" number of paths exist > that > > include the AS of the all the ISPs I rely upon. And what would an > > "acceptable" number of alternate paths be? > > > > > > thanks in advance, > > -andy > > > > > > -- > | Alexander Azimov | HLL l QRATOR > | tel.: +7 499 241 81 92 > | mob.: +7 915 360 08 86 > | skype: mitradir > | mailto: aa at qrator.net > | visit: www.qrator.net > From dkitchen at razorblue.com Wed Apr 4 10:47:45 2018 From: dkitchen at razorblue.com (Dan Kitchen) Date: Wed, 4 Apr 2018 10:47:45 +0000 Subject: NG Firewalls & IPv6 In-Reply-To: References: Message-ID: We run PaloAlto dual stack with no problems at all, that’s full dynamic routing with OSPF and BGP, web filtering, IPS, VPN access using GlobalProtect, etc. I must admit GlobalProtect IPv6 support was only introduced in PanOS 8 which was a little late in my opinion – but it was delivered and works. Dan Kitchen Managing Director razorblue | IT Solutions for Business ddi:0330 122 7143 | t: 0333 344 6 344 | e: dkitchen at razorblue.com | w: razorblue.com Legal and address information for all Razorblue Group companies can be found at www.razorblue.com/contact. From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joe Klein Sent: 02 April 2018 23:58 To: NANOG list Subject: NG Firewalls & IPv6 WARNING: This e-mail originated from outside the Razorblue Group corporate network All, At security and network tradeshows over the last 15 years, I have asked companies if their products supported "IPv6". They all claimed they did, but were unable to verify any successful installations. Later they told me it was on their "Roadmap" but were unable to provide an estimated year, because it was a trade secret. Starting this last year at BlackHat US, I again visited every product booth, asking if their products supported dual-stack or IPv6 only operations. Receiving only the same unsupported answers, I decided to focus on one product category. To the gurus of the NANOG community, What are your experiences with installing and managing Next Generations firewalls? Do they support IPv6 only environments? Details? Stories? If you prefer not to disparage those poor product companies, please contact me off the list. Thanks, Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 From cra at WPI.EDU Wed Apr 4 18:41:50 2018 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 4 Apr 2018 14:41:50 -0400 Subject: NG Firewalls & IPv6 In-Reply-To: References: Message-ID: <20180404184150.sabx4s7uzofryegc@angus.ind.wpi.edu> Also, IPv6 BGP support was only introduced in PanOS 8. But everything works fine here too. On Wed, Apr 04, 2018 at 10:47:45AM +0000, Dan Kitchen wrote: > We run PaloAlto dual stack with no problems at all, that’s full dynamic routing with OSPF and BGP, web filtering, IPS, VPN access using GlobalProtect, etc. > > I must admit GlobalProtect IPv6 support was only introduced in PanOS 8 which was a little late in my opinion – but it was delivered and works. > > > > > Dan Kitchen > Managing Director > razorblue | IT Solutions for Business > > ddi:0330 122 7143 | t: 0333 344 6 344 | e: dkitchen at razorblue.com | w: razorblue.com > > Legal and address information for all Razorblue Group companies can be found > at www.razorblue.com/contact. > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joe Klein > Sent: 02 April 2018 23:58 > To: NANOG list > Subject: NG Firewalls & IPv6 > > WARNING: This e-mail originated from outside the Razorblue Group corporate network > > All, > > At security and network tradeshows over the last 15 years, I have asked > companies if their products supported "IPv6". They all claimed they did, > but were unable to verify any successful installations. Later they told me > it was on their "Roadmap" but were unable to provide an estimated year, > because it was a trade secret. > > Starting this last year at BlackHat US, I again visited every product > booth, asking if their products supported dual-stack or IPv6 only > operations. Receiving only the same unsupported answers, I decided to focus > on one product category. > > To the gurus of the NANOG community, What are your experiences with > installing and managing Next Generations firewalls? Do they support IPv6 > only environments? Details? Stories? > > If you prefer not to disparage those poor product companies, please contact > me off the list. > > Thanks, > > Joe Klein From johnl at iecc.com Wed Apr 4 19:31:30 2018 From: johnl at iecc.com (John Levine) Date: 4 Apr 2018 15:31:30 -0400 Subject: Are any of you starting to get AI robocalls? In-Reply-To: Message-ID: <20180404193131.7BC342412E7E@ary.qy> In article you write: >> do it, and the spoofing is nearly impossible to trace back to the origin, so >> those who do it can safely ignore other laws because they know they won't be >> caught. > >Forward to an 800, grab it from the ANI versus CID? Won't help. If you do the forward, the ANI is yours. From me at anuragbhatia.com Wed Apr 4 21:31:35 2018 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 5 Apr 2018 03:01:35 +0530 Subject: CDN-provided caching platforms? In-Reply-To: <001b01d3cbb9$de974440$9bc5ccc0$@gvtc.com> References: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> <7149.1522164172@turing-police.cc.vt.edu> <001b01d3cbb9$de974440$9bc5ccc0$@gvtc.com> Message-ID: Hi Aaron I see the Amazon Prime video streams coming from Amazon Web Services Cloudfront CDN. Unsure of other places. Hard to do a global check on available platforms like say RIPE Atlas. And AWS Cloudfront does has the option of edge locations not connected to their backbone. On Wed, Apr 4, 2018 at 7:38 AM, Aaron Gould wrote: > I'm wondering if/when Amazon Prime Video will have a CDN system to roll-out > to ISP's like OCA, FNA, GGC, etc > > Anyone here anything about Amazon Video or any other big names like that ? > > - Aaron > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > valdis.kletnieks at vt.edu > Sent: Tuesday, March 27, 2018 10:23 AM > To: Russell Berg > Cc: nanog at nanog.org > Subject: Re: CDN-provided caching platforms? > > On Tue, 27 Mar 2018 02:26:24 -0000, Russell Berg said: > > > I was wondering if there are other CDN caching platforms out there we > > should be researching/deploying? > > Does traffic analysis show any other destinations that have enough traffic > that caching might help? > > > -- Anurag Bhatia anuragbhatia.com From kmedcalf at dessus.com Wed Apr 4 23:04:35 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 04 Apr 2018 17:04:35 -0600 Subject: Are any of you starting to get AI robocalls? In-Reply-To: <001f01d3cc23$711e01f0$535a05d0$@gmail.com> Message-ID: Why would the carriers want to do anything? They are making money from call termination fees. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean >Pedersen >Sent: Wednesday, 4 April, 2018 08:45 >To: nanog at nanog.org >Subject: RE: Are any of you starting to get AI robocalls? > >Yep. Add it to the list of IRS scams, fake arrest warrants, credit >repair, free vacations, etc. The rate of calls has increased >dramatically in the past year, especially with the "neighborhood >scam" where they spoof their CLID to a local area code and prefix + >0000 through 9999 and blast you with calls, trying to trick you into >thinking it's someone local and thus important or legitimate. > >I have a second phone I use for work and on-call, so that goes on DND >from 6PM to 6AM with a VIP list of people/numbers that can ring >through. No problems there, and somehow that number isn't (yet) on >anyone's list, so I don't get many calls. > >On my personal cell, I started to use an app called Hiya that has >been pretty successful. It's available for both iPhone and Android. >It powers a lot of the carrier-specific apps like AT&T Call Protect, >but unlike them, it doesn't suck. It's a giant database of reports >that rate calling numbers and classify them as fraud, scam, >neighborhood spoofing, etc. and you can flag them or route them right >to voicemail. The only time it doesn’t work is when it hasn't updated >its list in a little while and a few sneak through. They just >realized a premium version that added some features. I haven't >explored it yet. > >Went from about 20 calls a week to almost nothing. > >Carriers seem to be either uncapable or unwilling to address the >issue other than the occasional lip-service reply about "taking >customer's $variable seriously." > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William >Herrin >Sent: Tuesday, April 3, 2018 3:32 PM >To: nanog at nanog.org >Subject: Are any of you starting to get AI robocalls? > >Howdy. > >Have any of you started to get AI robocalls? I've had a couple of >calls recently where I get the connect silence of a predictive dialer >followed by a woman speaking with call center background noise. She >gives her name and asks how I'm doing. The first time it happened it >seemed off for reasons I can't quite articulate, so I asked: "Are you >a robot or a person?" She responded "yes" and then launched in to a >sales pitch. The next time I asked, "where can I direct your call?" >She responded "that's good" and launched in to her pitch. > >Regards, >Bill Herrin > > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Dirtside Systems ......... Web: From andy.litzinger.lists at gmail.com Wed Apr 4 23:04:58 2018 From: andy.litzinger.lists at gmail.com (Andy Litzinger) Date: Wed, 4 Apr 2018 16:04:58 -0700 Subject: validating reachability via an ISP In-Reply-To: References: Message-ID: Hi Alex, Thanks for the link to the qrator API. The get-all-paths is interesting and the output does seem to show exactly the type of data I'm looking for. Is there some place on the site that lists who Qrator peers with to get your data? I searched through the site and couldn't find it. I'm trying to get an idea of the breadth of data and whether i can comfortably rely on it giving me a global view. Also, how do I authorize programmatic requests to the API? I created a user and can use it to run the queries from the web page, but I don't see how to use it directly with the API. thanks! -andy On Thu, Mar 29, 2018 at 8:23 AM, Alexander Azimov wrote: > Hi Andy, > > You can use Qrator.Radar API: https://api.radar.qrator.net/. > The get-all-paths method will return the set of active paths for selected > prefix. > > PS: I'm sorry if you receive this message two times, something funny is > happening with my emails on NANOG mailing list. > > 2018-03-29 18:09 GMT+03:00 Alexander Azimov : > >> Hi Andy, >> >> You can use Qrator.Radar API: https://api.radar.qrator.net/. >> The get-all-paths method will return the set of active paths for selected >> prefix. >> >> >> 2018-03-29 2:22 GMT+03:00 Andy Litzinger >> : >> >>> Hi all, >>> I have an enterprise network and do not provide transit. In one of our >>> datacenters we have our own prefixes and rely on two ISPs as BGP >>> neighbors >>> to provide global reachability for our prefixes. One is a large regional >>> provider and the other is a large global provider. >>> >>> Recently we took our link to the global provider offline to perform >>> maintenance on our router. Nearly immediately we were hit with alerts >>> that >>> our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted >>> our >>> route had been withdrawn. We were not unreachable from every AS, but we >>> certainly were from some of the largest. >>> >>> The root cause is that the our prefix is not being adequately >>> re-distributed globally by the regional ISP. This is unexpected and we >>> are >>> working through this with them now. >>> >>> My question is, how can I monitor global reachability for a prefix via >>> this >>> or any specific provider I use over time? Are there various >>> route-servers >>> I can programmatically query for my prefix and get results that include >>> AS >>> paths? Then I could verify that an "acceptable" number of paths exist >>> that >>> include the AS of the all the ISPs I rely upon. And what would an >>> "acceptable" number of alternate paths be? >>> >>> >>> thanks in advance, >>> -andy >>> >> >> >> >> -- >> | Alexander Azimov | HLL l QRATOR >> | tel.: +7 499 241 81 92 >> | mob.: +7 915 360 08 86 >> | skype: mitradir >> | mailto: aa at qrator.net >> | visit: www.qrator.net >> > > > > -- > | Alexander Azimov | HLL l QRATOR > | tel.: +7 499 241 81 92 > | mob.: +7 915 360 08 86 > | skype: mitradir > | mailto: aa at qrator.net > | visit: www.qrator.net > From shawnl at up.net Wed Apr 4 23:17:40 2018 From: shawnl at up.net (Shawn L) Date: Wed, 4 Apr 2018 19:17:40 -0400 (EDT) Subject: =?utf-8?Q?RE=3A_Are_any_of_you_starting_to_get_AI_robocalls=3F?= In-Reply-To: References: Message-ID: <1522883860.6047750@upnet.mymailsrvr.com> Honestly, most carriers I've talked to are fed up as well, and just want to find a way to make it stop. As some one said, it's exactly like BCP38 --- the carriers that care keep their clients from spoofing caller id, etc. The ones that don't make everyone else look bad. -----Original Message----- From: "Keith Medcalf" Sent: Wednesday, April 4, 2018 7:04pm To: "nanog at nanog.org" Subject: RE: Are any of you starting to get AI robocalls? Why would the carriers want to do anything? They are making money from call termination fees. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean >Pedersen >Sent: Wednesday, 4 April, 2018 08:45 >To: nanog at nanog.org >Subject: RE: Are any of you starting to get AI robocalls? > >Yep. Add it to the list of IRS scams, fake arrest warrants, credit >repair, free vacations, etc. The rate of calls has increased >dramatically in the past year, especially with the "neighborhood >scam" where they spoof their CLID to a local area code and prefix + >0000 through 9999 and blast you with calls, trying to trick you into >thinking it's someone local and thus important or legitimate. > >I have a second phone I use for work and on-call, so that goes on DND >from 6PM to 6AM with a VIP list of people/numbers that can ring >through. No problems there, and somehow that number isn't (yet) on >anyone's list, so I don't get many calls. > >On my personal cell, I started to use an app called Hiya that has >been pretty successful. It's available for both iPhone and Android. >It powers a lot of the carrier-specific apps like AT&T Call Protect, >but unlike them, it doesn't suck. It's a giant database of reports >that rate calling numbers and classify them as fraud, scam, >neighborhood spoofing, etc. and you can flag them or route them right >to voicemail. The only time it doesn’t work is when it hasn't updated >its list in a little while and a few sneak through. They just >realized a premium version that added some features. I haven't >explored it yet. > >Went from about 20 calls a week to almost nothing. > >Carriers seem to be either uncapable or unwilling to address the >issue other than the occasional lip-service reply about "taking >customer's $variable seriously." > >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William >Herrin >Sent: Tuesday, April 3, 2018 3:32 PM >To: nanog at nanog.org >Subject: Are any of you starting to get AI robocalls? > >Howdy. > >Have any of you started to get AI robocalls? I've had a couple of >calls recently where I get the connect silence of a predictive dialer >followed by a woman speaking with call center background noise. She >gives her name and asks how I'm doing. The first time it happened it >seemed off for reasons I can't quite articulate, so I asked: "Are you >a robot or a person?" She responded "yes" and then launched in to a >sales pitch. The next time I asked, "where can I direct your call?" >She responded "that's good" and launched in to her pitch. > >Regards, >Bill Herrin > > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Dirtside Systems ......... Web: From andy.litzinger.lists at gmail.com Wed Apr 4 23:24:19 2018 From: andy.litzinger.lists at gmail.com (Andy Litzinger) Date: Wed, 4 Apr 2018 16:24:19 -0700 Subject: validating reachability via an ISP In-Reply-To: References: Message-ID: Hi Andrew, thanks for sharing your repo, it looks very relevant and I should be able to get it to do what I want with a slight tweak to the regex's. Hopefully the route-views collectors or some other ones I dig up will be able to adequately show at least 3 AS path hops through my regional provider to get to my AS/prefix. I really want to see AS paths where there are at least 2 different AS hops before my regional providers AS. This will help me feel good that the global partners of my regional ISP are re-advertising my prefix to their peers. Otherwise if the AS path only includes the first and second hop upstream I can only infer that the 2nd hop AS is accepting routes from the 1st hop AS (my regional ISP), but not that the 2nd hop AS is actually re-advertising the route to anyone else. thanks! -andy On Thu, Mar 29, 2018 at 7:51 AM, Andrew Wentzell wrote: > On Wed, Mar 28, 2018 at 7:22 PM, Andy Litzinger > wrote: > > Hi all, > > I have an enterprise network and do not provide transit. In one of our > > datacenters we have our own prefixes and rely on two ISPs as BGP > neighbors > > to provide global reachability for our prefixes. One is a large regional > > provider and the other is a large global provider. > > > > Recently we took our link to the global provider offline to perform > > maintenance on our router. Nearly immediately we were hit with alerts > that > > our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted > our > > route had been withdrawn. We were not unreachable from every AS, but we > > certainly were from some of the largest. > > > > The root cause is that the our prefix is not being adequately > > re-distributed globally by the regional ISP. This is unexpected and we > are > > working through this with them now. > > > > My question is, how can I monitor global reachability for a prefix via > this > > or any specific provider I use over time? Are there various > route-servers > > I can programmatically query for my prefix and get results that include > AS > > paths? Then I could verify that an "acceptable" number of paths exist > that > > include the AS of the all the ISPs I rely upon. And what would an > > "acceptable" number of alternate paths be? > > I did something similar a few years ago, by querying routeviews and > validating AS paths using python and pexpect. You could adapt it for > your use pretty easily. The code's here: > > https://github.com/awentzell/check-as-path > From dovid at telecurve.com Wed Apr 4 23:53:59 2018 From: dovid at telecurve.com (Dovid Bender) Date: Wed, 4 Apr 2018 19:53:59 -0400 Subject: Are any of you starting to get AI robocalls? In-Reply-To: <1522883860.6047750@upnet.mymailsrvr.com> References: <1522883860.6047750@upnet.mymailsrvr.com> Message-ID: As carriers who get these calls for our clients we hate them. Short duration calls have the same cost as far as channels, keeping cdr's etc yet since they are so short there isn't much to be made. This is worse then BCP38 since with the internet there is no reason for anyone at home or a small office to be sending out a packet that is not with their IP. When it comes to telephony say I have a PBX, I get a call and then want to send it out to my on call tech. I want him to see the real callers number. I need to now "spoof" that number so my tech see's the real caller. There is a lot more room for abuse. Now the carriers terminating the calls (the ones getting them from the spammers) they love them. Since it's dialer/short termination they can charge and arm and a leg. On Wed, Apr 4, 2018 at 7:17 PM, Shawn L via NANOG wrote: > > Honestly, most carriers I've talked to are fed up as well, and just want > to find a way to make it stop. As some one said, it's exactly like BCP38 > --- the carriers that care keep their clients from spoofing caller id, > etc. The ones that don't make everyone else look bad. > > -----Original Message----- > From: "Keith Medcalf" > Sent: Wednesday, April 4, 2018 7:04pm > To: "nanog at nanog.org" > Subject: RE: Are any of you starting to get AI robocalls? > > > > Why would the carriers want to do anything? They are making money from > call termination fees. > > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says > a lot about anticipated traffic volume. > > >-----Original Message----- > >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean > >Pedersen > >Sent: Wednesday, 4 April, 2018 08:45 > >To: nanog at nanog.org > >Subject: RE: Are any of you starting to get AI robocalls? > > > >Yep. Add it to the list of IRS scams, fake arrest warrants, credit > >repair, free vacations, etc. The rate of calls has increased > >dramatically in the past year, especially with the "neighborhood > >scam" where they spoof their CLID to a local area code and prefix + > >0000 through 9999 and blast you with calls, trying to trick you into > >thinking it's someone local and thus important or legitimate. > > > >I have a second phone I use for work and on-call, so that goes on DND > >from 6PM to 6AM with a VIP list of people/numbers that can ring > >through. No problems there, and somehow that number isn't (yet) on > >anyone's list, so I don't get many calls. > > > >On my personal cell, I started to use an app called Hiya that has > >been pretty successful. It's available for both iPhone and Android. > >It powers a lot of the carrier-specific apps like AT&T Call Protect, > >but unlike them, it doesn't suck. It's a giant database of reports > >that rate calling numbers and classify them as fraud, scam, > >neighborhood spoofing, etc. and you can flag them or route them right > >to voicemail. The only time it doesn’t work is when it hasn't updated > >its list in a little while and a few sneak through. They just > >realized a premium version that added some features. I haven't > >explored it yet. > > > >Went from about 20 calls a week to almost nothing. > > > >Carriers seem to be either uncapable or unwilling to address the > >issue other than the occasional lip-service reply about "taking > >customer's $variable seriously." > > > >-----Original Message----- > >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William > >Herrin > >Sent: Tuesday, April 3, 2018 3:32 PM > >To: nanog at nanog.org > >Subject: Are any of you starting to get AI robocalls? > > > >Howdy. > > > >Have any of you started to get AI robocalls? I've had a couple of > >calls recently where I get the connect silence of a predictive dialer > >followed by a woman speaking with call center background noise. She > >gives her name and asks how I'm doing. The first time it happened it > >seemed off for reasons I can't quite articulate, so I asked: "Are you > >a robot or a person?" She responded "yes" and then launched in to a > >sales pitch. The next time I asked, "where can I direct your call?" > >She responded "that's good" and launched in to her pitch. > > > >Regards, > >Bill Herrin > > > > > >-- > >William Herrin ................ herrin at dirtside.com bill at herrin.us > >Dirtside Systems ......... Web: > > > > > > From andy at nosignal.org Thu Apr 5 07:49:19 2018 From: andy at nosignal.org (Andy Davidson) Date: Thu, 5 Apr 2018 07:49:19 +0000 Subject: validating reachability via an ISP In-Reply-To: References: Message-ID: <0FE8DB6F-F7EB-438C-A4A1-13D3D40A97B1@nosignal.org> On 29/03/2018, 00:22, Andy Litzinger wrote: > >> The root cause is that the our prefix is not being adequately >> re-distributed globally by the regional ISP. This is unexpected and we are >> working through this with them now. Hi, Andy — Are you failing to advertise it, or are they filtering it on ingress, or are they failing to send it to their other peers? One configuration mishap which is starting to come along more and more partial or poor reachability caused by route objects which are not correctly published in the IRRDB. It is going to be essential to make sure that you have properly recorded IRR route objects in, for instance, RADB. More BGP speakers properly filter their peers using information that is published there. Avoid future reachability problems by checking this today! Yours, A friendly route-server operator with strict filtering -a -- Andy Davidson Asteroid International BV https://www.asteroidhq.com @asteroidhq @andyd -------------------------------------------------- Local interconnection. Where you need it. From uwcableguy at gmail.com Thu Apr 5 11:16:47 2018 From: uwcableguy at gmail.com (Ben Bartsch) Date: Thu, 5 Apr 2018 06:16:47 -0500 Subject: validating reachability via an ISP In-Reply-To: <0FE8DB6F-F7EB-438C-A4A1-13D3D40A97B1@nosignal.org> References: <0FE8DB6F-F7EB-438C-A4A1-13D3D40A97B1@nosignal.org> Message-ID: +1 for Route Explorer On Thu, Apr 5, 2018 at 2:49 AM, Andy Davidson wrote: > > > > > > On 29/03/2018, 00:22, Andy Litzinger > wrote: > > > >> The root cause is that the our prefix is not being adequately > >> re-distributed globally by the regional ISP. This is unexpected and we > are > >> working through this with them now. > > Hi, Andy — > > Are you failing to advertise it, or are they filtering it on ingress, or > are they failing to send it to their other peers? > > One configuration mishap which is starting to come along more and more > partial or poor reachability caused by route objects which are not > correctly published in the IRRDB. It is going to be essential to make sure > that you have properly recorded IRR route objects in, for instance, RADB. > More BGP speakers properly filter their peers using information that is > published there. Avoid future reachability problems by checking this today! > > Yours, > A friendly route-server operator with strict filtering > > -a > > > > -- > Andy Davidson Asteroid International BV > https://www.asteroidhq.com @asteroidhq @andyd > -------------------------------------------------- > Local interconnection. Where you need it. > > From sahin at eurecom.fr Thu Apr 5 12:07:58 2018 From: sahin at eurecom.fr (Merve Sahin) Date: Thu, 5 Apr 2018 14:07:58 +0200 Subject: Are any of you starting to get AI robocalls? In-Reply-To: <8e7ec9ac-6edb-bc30-e9ac-07bbbb8f1da6@shankland.org> References: <001f01d3cc23$711e01f0$535a05d0$@gmail.com> <8e7ec9ac-6edb-bc30-e9ac-07bbbb8f1da6@shankland.org> Message-ID: There is also Lenny : https://www.youtube.com/playlist?list=PLduL71_GKzHHk4hLga0nOGWrXlhl-i_3g And here is our paper on using chatbots against voice spam: https://www.usenix.org/conference/soups2017/technical-sessions/presentation/sahin It seems the future of voice spam will be the chatbots talking to each other! Merve On 04/04/2018 17:08, Jim Shankland wrote: > On 4/4/18 7:44 AM, Sean Pedersen wrote: >> Yep. Add it to the list of IRS scams, fake arrest warrants, credit >> repair, free vacations, etc. The rate of calls has increased >> dramatically in the past year, especially with the "neighborhood scam" >> where they spoof their CLID to a local area code and prefix + 0000 >> through 9999 and blast you with calls, trying to trick you into >> thinking it's someone local and thus important or legitimate. >> > Let me also put in a good word for the Jolly Roger Telephone Co. > (http://www.jollyrogertelco.com). Don't just defend, fight back. > > Jim > From cb.list6 at gmail.com Thu Apr 5 12:42:48 2018 From: cb.list6 at gmail.com (Ca By) Date: Thu, 05 Apr 2018 12:42:48 +0000 Subject: Are any of you starting to get AI robocalls? In-Reply-To: <1522883860.6047750@upnet.mymailsrvr.com> References: <1522883860.6047750@upnet.mymailsrvr.com> Message-ID: On Wed, Apr 4, 2018 at 4:19 PM Shawn L via NANOG wrote: > > Honestly, most carriers I've talked to are fed up as well, and just want > to find a way to make it stop. As some one said, it's exactly like BCP38 > --- the carriers that care keep their clients from spoofing caller id, > etc. The ones that don't make everyone else look bad. > Some carriers have a free scam call block feature https://newsroom.t-mobile.com/news-and-blogs/scam-block.htm > -----Original Message----- > From: "Keith Medcalf" > Sent: Wednesday, April 4, 2018 7:04pm > To: "nanog at nanog.org" > Subject: RE: Are any of you starting to get AI robocalls? > > > > Why would the carriers want to do anything? They are making money from > call termination fees. > > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says > a lot about anticipated traffic volume. > > >-----Original Message----- > >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Sean > >Pedersen > >Sent: Wednesday, 4 April, 2018 08:45 > >To: nanog at nanog.org > >Subject: RE: Are any of you starting to get AI robocalls? > > > >Yep. Add it to the list of IRS scams, fake arrest warrants, credit > >repair, free vacations, etc. The rate of calls has increased > >dramatically in the past year, especially with the "neighborhood > >scam" where they spoof their CLID to a local area code and prefix + > >0000 through 9999 and blast you with calls, trying to trick you into > >thinking it's someone local and thus important or legitimate. > > > >I have a second phone I use for work and on-call, so that goes on DND > >from 6PM to 6AM with a VIP list of people/numbers that can ring > >through. No problems there, and somehow that number isn't (yet) on > >anyone's list, so I don't get many calls. > > > >On my personal cell, I started to use an app called Hiya that has > >been pretty successful. It's available for both iPhone and Android. > >It powers a lot of the carrier-specific apps like AT&T Call Protect, > >but unlike them, it doesn't suck. It's a giant database of reports > >that rate calling numbers and classify them as fraud, scam, > >neighborhood spoofing, etc. and you can flag them or route them right > >to voicemail. The only time it doesn’t work is when it hasn't updated > >its list in a little while and a few sneak through. They just > >realized a premium version that added some features. I haven't > >explored it yet. > > > >Went from about 20 calls a week to almost nothing. > > > >Carriers seem to be either uncapable or unwilling to address the > >issue other than the occasional lip-service reply about "taking > >customer's $variable seriously." > > > >-----Original Message----- > >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William > >Herrin > >Sent: Tuesday, April 3, 2018 3:32 PM > >To: nanog at nanog.org > >Subject: Are any of you starting to get AI robocalls? > > > >Howdy. > > > >Have any of you started to get AI robocalls? I've had a couple of > >calls recently where I get the connect silence of a predictive dialer > >followed by a woman speaking with call center background noise. She > >gives her name and asks how I'm doing. The first time it happened it > >seemed off for reasons I can't quite articulate, so I asked: "Are you > >a robot or a person?" She responded "yes" and then launched in to a > >sales pitch. The next time I asked, "where can I direct your call?" > >She responded "that's good" and launched in to her pitch. > > > >Regards, > >Bill Herrin > > > > > >-- > >William Herrin ................ herrin at dirtside.com bill at herrin.us > >Dirtside Systems ......... Web: > > > > > > From SNaslund at medline.com Thu Apr 5 14:02:08 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 5 Apr 2018 14:02:08 +0000 Subject: Are any of you starting to get AI robocalls? In-Reply-To: References: <1522883860.6047750@upnet.mymailsrvr.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402A8741496@MUNPRDMBXA1.medline.com> If the scam caller is spoofing the numbers then I am not quite sure how T-Mobile can implement the block without blocking the legit owner of the number. The way to correct this as an industry is for them to inspect the caller-id coming in from their customer and if that customer does not own the number or toll free DN they are presenting, the call gets blocked. I know they can do this because our SIP carrier AT&T will not accept outbound calls from us unless we present a number assigned to our account so they can bill back for the call. Truthfully, the carriers do not have a real incentive to stop this because someone is paying to make all of those calls. I don't believe for a minute that they could not stop this immediately. A simple rule that you cannot make a commercial call without presenting a valid callback number would fix this. There is also the FTC problem. They do almost nothing to stop the violations of the Do Not Call list and you get nothing out of reporting the violations. If the enforcement was anywhere near the requirements of the DCMA regulations, this would be reduced drastically. First step would be to make the carriers liable for providing service to these scammers, then they might actually care. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ca By Sent: Thursday, April 05, 2018 7:43 AM To: Shawn L Cc: nanog at nanog.org Subject: Re: Are any of you starting to get AI robocalls? On Wed, Apr 4, 2018 at 4:19 PM Shawn L via NANOG wrote: > > Honestly, most carriers I've talked to are fed up as well, and just > want to find a way to make it stop. As some one said, it's exactly > like BCP38 > --- the carriers that care keep their clients from spoofing caller > id, etc. The ones that don't make everyone else look bad. > Some carriers have a free scam call block feature https://newsroom.t-mobile.com/news-and-blogs/scam-block.htm From dovid at telecurve.com Thu Apr 5 14:06:46 2018 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 05 Apr 2018 10:06:46 -0400 Subject: Are any of you starting to get AI robocalls? In-Reply-To: <9578293AE169674F9A048B2BC9A081B402A8741496@MUNPRDMBXA1.medline.com> Message-ID: Steve, Any customer with a PBX has a valid reason to pass CLI that isn't theirs if they are passing through a call. Regards, Dovid   Original Message   From: SNaslund at medline.com Sent: April 5, 2018 10:03 To: nanog at nanog.org Subject: RE: Are any of you starting to get AI robocalls? If the scam caller is spoofing the numbers then I am not quite sure how T-Mobile can implement the block without blocking the legit owner of the number.  The way to correct this as an industry is for them to inspect the caller-id coming in from their customer and if that customer does not own the number or toll free DN they are presenting, the call gets blocked.  I know they can do this because our SIP carrier AT&T will not accept outbound calls from us unless we present a number assigned to our account so they can bill back for the call.  Truthfully, the carriers do not have a real incentive to stop this because someone is paying to make all of those calls.  I don't believe for a minute that they could not stop this immediately.  A simple rule that you cannot make a commercial call without presenting a valid callback number would fix this.  There is also the FTC problem.  They do almost nothing to stop the violations of the Do Not Call list and you get nothing out of reporting the violations.  If the enforcement was anywhere near the requirements of the DCMA regulations, this would be reduced drastically.  First step would be to make the carriers liable for providing service to these scammers, then they might actually care. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ca By Sent: Thursday, April 05, 2018 7:43 AM To: Shawn L Cc: nanog at nanog.org Subject: Re: Are any of you starting to get AI robocalls? On Wed, Apr 4, 2018 at 4:19 PM Shawn L via NANOG wrote: > > Honestly, most carriers I've talked to are fed up as well, and just > want to find a way to make it stop.  As some one said, it's exactly > like BCP38 > ---  the carriers that care keep their clients from spoofing caller > id, etc.  The ones that don't make everyone else look bad. > Some carriers have a free scam call block feature https://newsroom.t-mobile.com/news-and-blogs/scam-block.htm From bill at herrin.us Thu Apr 5 14:20:29 2018 From: bill at herrin.us (William Herrin) Date: Thu, 5 Apr 2018 10:20:29 -0400 Subject: Are any of you starting to get AI robocalls? In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B402A8741496@MUNPRDMBXA1.medline.com> Message-ID: On Thu, Apr 5, 2018 at 10:06 AM, Dovid Bender wrote: > Any customer with a PBX has a valid reason to pass CLI that isn't theirs if they are passing through a call. Hi Dovid, For example, Vonage implementing Simultaneous Ring, you want to see the original caller id on your cell phone, not your vonage number even though Vonage is bridging the call to your cell phone. More, the PBX may have trunks from multiple vendors and may use a different outbound vendor than the call arrives on, so you can't even reliably implement a rule that the outbound caller ID is rejected unless there's an active inbound call with the same caller id. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From Brian at ampr.org Thu Apr 5 14:55:36 2018 From: Brian at ampr.org (Brian Kantor) Date: Thu, 5 Apr 2018 07:55:36 -0700 Subject: Are any of you starting to get AI robocalls? In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B402A8741496@MUNPRDMBXA1.medline.com> Message-ID: <20180405145536.GA45423@meow.BKantor.net> On Thu, Apr 05, 2018 at 10:20:29AM -0400, William Herrin wrote: > For example, Vonage implementing Simultaneous Ring, you want to see > the original caller id on your cell phone, not your vonage number even > though Vonage is bridging the call to your cell phone. > > More, the PBX may have trunks from multiple vendors and may use a > different outbound vendor than the call arrives on, so you can't even > reliably implement a rule that the outbound caller ID is rejected > unless there's an active inbound call with the same caller id. > > Regards, > Bill Herrin So the logical conclusion is that caller ID is useless as an anti-vspam measure and the situation is hopeless, so the only solution is to not personally answer the phone at all -- let voice mail take a message. This is what I have adopted on my personal landline. With the ringers disconnected. Although I get probably a half-dozen incoming calls a day, perhaps one a week will leave a message. Most of those messages are recorded announcements that started playing even before the voicemail greeting finished. - Brian From brian at nc-ct.net Thu Apr 5 15:12:53 2018 From: brian at nc-ct.net (Brian) Date: Thu, 05 Apr 2018 11:12:53 -0400 Subject: Are any of you starting to get AI robocalls? In-Reply-To: <20180405145536.GA45423@meow.BKantor.net> References: <9578293AE169674F9A048B2BC9A081B402A8741496@MUNPRDMBXA1.medline.com> <20180405145536.GA45423@meow.BKantor.net> Message-ID: <1522941173.14880.30.camel@n1uro> On Thu, 2018-04-05 at 07:55 -0700, Brian Kantor wrote: > So the logical conclusion is that caller ID is useless as an > anti-vspam measure and the situation is hopeless, so the only > solution is to not personally answer the phone at all -- let voice > mail take a message. Pretty much. We've received calls here with the CID displaying as our own info, and others coming up as a neighbor's number. Some even appear as law enforcement when they're scammers looking for donations to charities that don't exist. I suppose if you're going to commit one crime, go for broke. > This is what I have adopted on my personal landline. With the > ringers disconnected. Although I get probably a half-dozen incoming > calls a day, perhaps one a week will leave a message. Most of those > messages are recorded announcements that started playing even before > the voicemail greeting finished. I've been enjoying quiet on a VoIP line with asterisk. Those who I know/expect/desire calls from I can route them directly to my extension, those others get the IVR. It works parallel to IP routing. I can go a few days without hearing my phone ring yet my logs are filled with spammers/telemarketing calls. Robo-dialers have no clue which extension a human may be at, and I've been doing this for over 15 years with great success. With a digium wildcard, this can work for POTS lines as well. From adamkennedy at watchcomm.net Thu Apr 5 15:46:20 2018 From: adamkennedy at watchcomm.net (Adam Kennedy) Date: Thu, 5 Apr 2018 11:46:20 -0400 Subject: NG Firewalls & IPv6 In-Reply-To: <20180404184150.sabx4s7uzofryegc@angus.ind.wpi.edu> References: <20180404184150.sabx4s7uzofryegc@angus.ind.wpi.edu> Message-ID: We've been using DHCP-PD with Sophos SG/XG on a couple Comcast connections and it works fine. It will even go through all your firewall objects and automatically change the IPv6 prefix from the old to new if the prefix from PD changes. -- Adam Kennedy, Network & Systems Engineer adamkennedy at watchcomm.net *Watch Communications* (866) 586-1518 On Wed, Apr 4, 2018 at 2:41 PM, Chuck Anderson wrote: > Also, IPv6 BGP support was only introduced in PanOS 8. But everything > works fine here too. > > On Wed, Apr 04, 2018 at 10:47:45AM +0000, Dan Kitchen wrote: > > We run PaloAlto dual stack with no problems at all, that’s full dynamic > routing with OSPF and BGP, web filtering, IPS, VPN access using > GlobalProtect, etc. > > > > I must admit GlobalProtect IPv6 support was only introduced in PanOS 8 > which was a little late in my opinion – but it was delivered and works. > > > > > > > > > > Dan Kitchen > > Managing Director > > razorblue | IT Solutions for Business > > > > ddi:0330 122 7143 | t: 0333 344 6 344 | e: dkitchen at razorblue.com > | w: razorblue.com > > > > Legal and address information for all Razorblue Group companies can be > found > > at www.razorblue.com/contact. > > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joe Klein > > Sent: 02 April 2018 23:58 > > To: NANOG list > > Subject: NG Firewalls & IPv6 > > > > WARNING: This e-mail originated from outside the Razorblue Group > corporate network > > > > All, > > > > At security and network tradeshows over the last 15 years, I have asked > > companies if their products supported "IPv6". They all claimed they did, > > but were unable to verify any successful installations. Later they told > me > > it was on their "Roadmap" but were unable to provide an estimated year, > > because it was a trade secret. > > > > Starting this last year at BlackHat US, I again visited every product > > booth, asking if their products supported dual-stack or IPv6 only > > operations. Receiving only the same unsupported answers, I decided to > focus > > on one product category. > > > > To the gurus of the NANOG community, What are your experiences with > > installing and managing Next Generations firewalls? Do they support IPv6 > > only environments? Details? Stories? > > > > If you prefer not to disparage those poor product companies, please > contact > > me off the list. > > > > Thanks, > > > > Joe Klein > From blake at ispn.net Thu Apr 5 17:12:52 2018 From: blake at ispn.net (Blake Hudson) Date: Thu, 5 Apr 2018 12:12:52 -0500 Subject: NG Firewalls & IPv6 In-Reply-To: References: Message-ID: I've used pfSense (BSD firewall) in a dual stack setup. Not all features are at parity with v4 (the captive portal doesn't support v6, for example), but the core features of stateful firewall, DHCPv6, etc seemed to work without any fuss. Joe Klein wrote on 4/2/2018 5:58 PM: > All, > > At security and network tradeshows over the last 15 years, I have asked > companies if their products supported "IPv6". They all claimed they did, > but were unable to verify any successful installations. Later they told me > it was on their "Roadmap" but were unable to provide an estimated year, > because it was a trade secret. > > Starting this last year at BlackHat US, I again visited every product > booth, asking if their products supported dual-stack or IPv6 only > operations. Receiving only the same unsupported answers, I decided to focus > on one product category. > > To the gurus of the NANOG community, What are your experiences with > installing and managing Next Generations firewalls? Do they support IPv6 > only environments? Details? Stories? > > If you prefer not to disparage those poor product companies, please contact > me off the list. > > Thanks, > > Joe Klein > > "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) > PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 From andy.litzinger.lists at gmail.com Thu Apr 5 17:30:58 2018 From: andy.litzinger.lists at gmail.com (Andy Litzinger) Date: Thu, 5 Apr 2018 10:30:58 -0700 Subject: validating reachability via an ISP In-Reply-To: <0FE8DB6F-F7EB-438C-A4A1-13D3D40A97B1@nosignal.org> References: <0FE8DB6F-F7EB-438C-A4A1-13D3D40A97B1@nosignal.org> Message-ID: Hi Andy, The root cause was they regional ISP was failing to advertise my prefix due to a mistake in their export policy. While I'm glad we were able to figure out the issue I'm generally more interested in figuring out a way that I can programmatically monitor that my ISPs are providing me with good reachability, even when their route isn't necessarily the best/installed route to me. I do have route objects defined in an IRR for this prefix. Perhaps you wouldn't mind explaining to me how route-server or ISP operators generally validate route-objects before accepting routes? Especially in the case where I'm not peering with your route server but my ISP is. Do you query the IRR DB to recurse from the ISP AS to my AS and validate route objects there? thanks! -andy On Thu, Apr 5, 2018 at 12:49 AM, Andy Davidson wrote: > > > > > > On 29/03/2018, 00:22, Andy Litzinger > wrote: > > > >> The root cause is that the our prefix is not being adequately > >> re-distributed globally by the regional ISP. This is unexpected and we > are > >> working through this with them now. > > Hi, Andy — > > Are you failing to advertise it, or are they filtering it on ingress, or > are they failing to send it to their other peers? > > One configuration mishap which is starting to come along more and more > partial or poor reachability caused by route objects which are not > correctly published in the IRRDB. It is going to be essential to make sure > that you have properly recorded IRR route objects in, for instance, RADB. > More BGP speakers properly filter their peers using information that is > published there. Avoid future reachability problems by checking this today! > > Yours, > A friendly route-server operator with strict filtering > > -a > > > > -- > Andy Davidson Asteroid International BV > https://www.asteroidhq.com @asteroidhq @andyd > -------------------------------------------------- > Local interconnection. Where you need it. > > From SNaslund at medline.com Thu Apr 5 17:43:57 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 5 Apr 2018 17:43:57 +0000 Subject: Are any of you starting to get AI robocalls? In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B402A8741496@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402A87428EB@MUNPRDMBXA1.medline.com> There are plenty of ways to handle that. There are P-asserted identities that can be passed with the call in addition to the CLID. In SIP, there is also call history data that can give you all of the PBX hops identified. If a customer with a PBX wants to forward calls back into the PSTN then the carrier can have an option to allow them to do that but they better also have a way of tracking those calls since they are open to abuse and they are obscuring the routing of the call. I am OK with that as long as the carrier is responsible for tracking back any abuse complaints. I do think every PBX in the call path should be identified. We have had instances where some stupid PBX is forwarding calls to the wrong number generating abuse complaints that track back to the wrong place because the PBX forwarded the original caller-id. So you call that person back and they correctly claim that they never called you. Steven Naslund Chicago IL >-----Original Message----- >From: Dovid Bender [mailto:dovid at telecurve.com] >Sent: Thursday, April 05, 2018 9:07 AM >To: Naslund, Steve; NANOG list >Subject: Re: Are any of you starting to get AI robocalls? > >Steve, > >Any customer with a PBX has a valid reason to pass CLI that isn't theirs if they are passing through a call. > > >Regards, > >Dovid From dovid at telecurve.com Thu Apr 5 17:44:09 2018 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 5 Apr 2018 13:44:09 -0400 Subject: Are any of you starting to get AI robocalls? In-Reply-To: <1522941173.14880.30.camel@n1uro> References: <9578293AE169674F9A048B2BC9A081B402A8741496@MUNPRDMBXA1.medline.com> <20180405145536.GA45423@meow.BKantor.net> <1522941173.14880.30.camel@n1uro> Message-ID: On Thu, Apr 5, 2018 at 11:12 AM, Brian wrote: > On Thu, 2018-04-05 at 07:55 -0700, Brian Kantor wrote: > > > So the logical conclusion is that caller ID is useless as an > > anti-vspam measure and the situation is hopeless, so the only > > solution is to not personally answer the phone at all -- let voice > > mail take a message. > > Pretty much. We've received calls here with the CID displaying as our > own info, and others coming up as a neighbor's number. Some even appear > as law enforcement when they're scammers looking for donations to > charities that don't exist. I suppose if you're going to commit one > crime, go for broke. > > > This is what I have adopted on my personal landline. With the > > ringers disconnected. Although I get probably a half-dozen incoming > > calls a day, perhaps one a week will leave a message. Most of those > > messages are recorded announcements that started playing even before > > the voicemail greeting finished. > > I've been enjoying quiet on a VoIP line with asterisk. Those who I > know/expect/desire calls from I can route them directly to my extension, > those others get the IVR. It works parallel to IP routing. I can go a > few days without hearing my phone ring yet my logs are filled with > spammers/telemarketing calls. Robo-dialers have no clue which extension > a human may be at, and I've been doing this for over 15 years with great > success. With a digium wildcard, this can work for POTS lines as well. > > > A simple "Thank you for calling the line of $NAME. To prove you are not a robot press 1". That seems to weed out most of them. From rwebb at ropeguru.com Thu Apr 5 18:02:21 2018 From: rwebb at ropeguru.com (Robert Webb) Date: Thu, 5 Apr 2018 18:02:21 +0000 Subject: NG Firewalls & IPv6 In-Reply-To: References: <20180404184150.sabx4s7uzofryegc@angus.ind.wpi.edu> Message-ID: Really?? I was looking to install and use as a vm to test with and everything I was reading said it was not implemented and was not on the horizon. Only version I found from Sophos that was capable was the old Astaro version. I may have to take a second look. Do you have any links to the configuration from their site you could send off list? Or on list if anyone else is interested. Thanks, Robert -----Original Message----- From: NANOG On Behalf Of Adam Kennedy via NANOG Sent: Thursday, April 5, 2018 11:46 AM To: NANOG list Subject: Re: NG Firewalls & IPv6 We've been using DHCP-PD with Sophos SG/XG on a couple Comcast connections and it works fine. It will even go through all your firewall objects and automatically change the IPv6 prefix from the old to new if the prefix from PD changes. -- Adam Kennedy, Network & Systems Engineer adamkennedy at watchcomm.net *Watch Communications* (866) 586-1518 On Wed, Apr 4, 2018 at 2:41 PM, Chuck Anderson wrote: > Also, IPv6 BGP support was only introduced in PanOS 8. But everything > works fine here too. > > On Wed, Apr 04, 2018 at 10:47:45AM +0000, Dan Kitchen wrote: > > We run PaloAlto dual stack with no problems at all, that’s full > > dynamic > routing with OSPF and BGP, web filtering, IPS, VPN access using > GlobalProtect, etc. > > > > I must admit GlobalProtect IPv6 support was only introduced in PanOS > > 8 > which was a little late in my opinion – but it was delivered and works. > > > > > > > > > > Dan Kitchen > > Managing Director > > razorblue | IT Solutions for Business > > > > ddi:0330 122 7143 | t: 0333 344 6 344 | e: dkitchen at razorblue.com > | w: razorblue.com > > > > Legal and address information for all Razorblue Group companies can > > be > found > > at www.razorblue.com/contact. > > > > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joe Klein > > Sent: 02 April 2018 23:58 > > To: NANOG list > > Subject: NG Firewalls & IPv6 > > > > WARNING: This e-mail originated from outside the Razorblue Group > corporate network > > > > All, > > > > At security and network tradeshows over the last 15 years, I have > > asked companies if their products supported "IPv6". They all claimed > > they did, but were unable to verify any successful installations. > > Later they told > me > > it was on their "Roadmap" but were unable to provide an estimated > > year, because it was a trade secret. > > > > Starting this last year at BlackHat US, I again visited every > > product booth, asking if their products supported dual-stack or IPv6 > > only operations. Receiving only the same unsupported answers, I > > decided to > focus > > on one product category. > > > > To the gurus of the NANOG community, What are your experiences with > > installing and managing Next Generations firewalls? Do they support > > IPv6 only environments? Details? Stories? > > > > If you prefer not to disparage those poor product companies, please > contact > > me off the list. > > > > Thanks, > > > > Joe Klein > From keiths at neilltech.com Thu Apr 5 19:44:45 2018 From: keiths at neilltech.com (Keith Stokes) Date: Thu, 5 Apr 2018 19:44:45 +0000 Subject: NG Firewalls & IPv6 In-Reply-To: References: Message-ID: I’ve been using PfSense @ home dual-stack on Cox for a year or two. As far as I can tell any IPv6 problems are Cox issues. On Apr 5, 2018, at 12:12 PM, Blake Hudson > wrote: I've used pfSense (BSD firewall) in a dual stack setup. Not all features are at parity with v4 (the captive portal doesn't support v6, for example), but the core features of stateful firewall, DHCPv6, etc seemed to work without any fuss. Joe Klein wrote on 4/2/2018 5:58 PM: All, At security and network tradeshows over the last 15 years, I have asked companies if their products supported "IPv6". They all claimed they did, but were unable to verify any successful installations. Later they told me it was on their "Roadmap" but were unable to provide an estimated year, because it was a trade secret. Starting this last year at BlackHat US, I again visited every product booth, asking if their products supported dual-stack or IPv6 only operations. Receiving only the same unsupported answers, I decided to focus on one product category. To the gurus of the NANOG community, What are your experiences with installing and managing Next Generations firewalls? Do they support IPv6 only environments? Details? Stories? If you prefer not to disparage those poor product companies, please contact me off the list. Thanks, Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 --- Keith Stokes From hal.lightwood at tbaytel.net Thu Apr 5 19:34:08 2018 From: hal.lightwood at tbaytel.net (HAL) Date: Thu, 5 Apr 2018 15:34:08 -0400 Subject: Are any of you starting to get AI robocalls? In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B402A8741496@MUNPRDMBXA1.medline.com> <20180405145536.GA45423@meow.BKantor.net> <1522941173.14880.30.camel@n1uro> Message-ID: I've worked at a telco for 15 years and I can say this problem is not going away anytime soon. The issue is the SS7 network that carriers use inherently trusts calls from long distance trunks without verification... I've analyzed incoming spoofed calls from our STP and they all come from foreign point codes on the SS7 network somewhere else in the world. One potential solution was to block incoming calls from an LD trunk with a local NXX, but since number portability came into play this would also block legitimate calls and couldn't be implemented without also having a whitelist of ported numbers to let through. While you could in theory customize your SS7 STP to do this, the manufactures of that equipment are not very interested in that development work without being paid to do it, and since the FCC/CRTC and other regulatory bodies haven't forced it yet... nobody is voluntarily going to cough up the $$$. This is very similar, in a way, to how email used to be in the 90s.. with open SMTP relays all over the place and anyone could spoof email.. all you need to do to access it is have some sort of digital interface (like a PRI for example) to be able to connect directly and specify (ie spoof) your ANI when placing a call). *--* On Thu, Apr 5, 2018 at 1:44 PM, Dovid Bender wrote: > On Thu, Apr 5, 2018 at 11:12 AM, Brian wrote: > > > On Thu, 2018-04-05 at 07:55 -0700, Brian Kantor wrote: > > > > > So the logical conclusion is that caller ID is useless as an > > > anti-vspam measure and the situation is hopeless, so the only > > > solution is to not personally answer the phone at all -- let voice > > > mail take a message. > > > > Pretty much. We've received calls here with the CID displaying as our > > own info, and others coming up as a neighbor's number. Some even appear > > as law enforcement when they're scammers looking for donations to > > charities that don't exist. I suppose if you're going to commit one > > crime, go for broke. > > > > > This is what I have adopted on my personal landline. With the > > > ringers disconnected. Although I get probably a half-dozen incoming > > > calls a day, perhaps one a week will leave a message. Most of those > > > messages are recorded announcements that started playing even before > > > the voicemail greeting finished. > > > > I've been enjoying quiet on a VoIP line with asterisk. Those who I > > know/expect/desire calls from I can route them directly to my extension, > > those others get the IVR. It works parallel to IP routing. I can go a > > few days without hearing my phone ring yet my logs are filled with > > spammers/telemarketing calls. Robo-dialers have no clue which extension > > a human may be at, and I've been doing this for over 15 years with great > > success. With a digium wildcard, this can work for POTS lines as well. > > > > > > > > A simple "Thank you for calling the line of $NAME. To prove you are not a > robot press 1". That seems to weed out most of them. > -- 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 email. Please notify the sender immediately by e-mail if you have received this email 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 me at anuragbhatia.com Thu Apr 5 20:22:55 2018 From: me at anuragbhatia.com (Anurag Bhatia) Date: Fri, 6 Apr 2018 01:52:55 +0530 Subject: Why doesn't "Cloudflare 1.1.1.1" compress root answers? In-Reply-To: <87a7ukxdow.fsf@miraculix.mork.no> References: <87a7ukxdow.fsf@miraculix.mork.no> Message-ID: Hi Bjørn Never realised of such compression on answered. Is this is something well documented? Curious. Thanks for sharing. On Wed, Apr 4, 2018 at 1:30 AM, Bjørn Mork wrote: > At first I thought they had disabled compression: > > bjorn at miraculix:~$ dig . ns @1.1.1.1|grep SIZE > ;; MSG SIZE rcvd: 431 > bjorn at miraculix:~$ dig . ns @8.8.8.8|grep SIZE > ;; MSG SIZE rcvd: 239 > bjorn at miraculix:~$ dig . ns @9.9.9.9|grep SIZE > ;; MSG SIZE rcvd: 239 > > > But then I noticed that they *do* compress other names: > > bjorn at miraculix:~$ dig net ns @1.1.1.1|grep SIZE > ;; MSG SIZE rcvd: 253 > bjorn at miraculix:~$ dig net ns @8.8.8.8|grep SIZE > ;; MSG SIZE rcvd: 253 > bjorn at miraculix:~$ dig net ns @9.9.9.9|grep SIZE > ;; MSG SIZE rcvd: 253 > > > Which just makes it even more confusing. What's so special about root? > Except for the obvious :-) > > > > Bjørn > > -- Anurag Bhatia anuragbhatia.com From joe at breathe-underwater.com Thu Apr 5 20:57:51 2018 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Thu, 5 Apr 2018 13:57:51 -0700 Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state Message-ID: I have cases open with both Cisco and Juniper on this, but wanted to see if anyone else had seen an issue like this because support has no idea. I have a Juniper QFX 5100 Core running in Virtual Chassis mode with 4 switches. I have 4 separate stacks of Cisco 3750 switches with 2x1GB uplinks bound into 4 different LACP trunks. I have had it happen twice now where I apply a trunk port config(not an LACP trunk) to a port that isn't a part of any of the LACP trunks and it causes all 4 of the Etherchannels on the Cisco stacked switches to go into an err-disable state with these messages: Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Gi1/0/48, putting Gi1/0/48 in err-disable state Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Po17, putting Gi1/0/48 in err-disable state Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Po17, putting Po17 in err-disable state Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/48, changed state to down Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Gi2/0/48, putting Gi2/0/48 in err-disable state (CA-TOR-1-7-2) Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/48, changed state to down Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel17, changed state to down Here is the config I am applying to the port that has caused this issue to happen twice now: set interfaces ge-0/0/67 description "Firewall Port" set interfaces ge-0/0/67 unit 0 family ethernet-switching interface-mode trunk set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 9-10 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 29 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 31-32 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 43 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 50-51 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 56 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 58 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 66 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 68 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 90 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 143 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 170 The issue happens within a couple of minutes of committing the config on the Juniper side, there are no cables plugged into port 0/0/67 so technically there shouldn't be any BPDU's sent out since there isn't a port change. Juniper Support wants me to turn on trace option and then run though a bunch of scenarios, the issue is that testing this takes down my network. Just wanted to put it out there to see if anyone else had run into a situation similar to this. TIA Joe From rwebb at ropeguru.com Thu Apr 5 21:10:01 2018 From: rwebb at ropeguru.com (Robert Webb) Date: Thu, 5 Apr 2018 21:10:01 +0000 Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state In-Reply-To: References: Message-ID: I don't see any issue with the snippet of the config you provided for the "Firewall Port". Is there a chance that the port ge-0/0/67 is referenced somewhere else in the Juniper config that when applying your trunk setup is causing issues? Just throw that out off the top of my head and not really thinking it through. Robert -----Original Message----- From: NANOG On Behalf Of Joseph Jenkins Sent: Thursday, April 5, 2018 4:58 PM To: nanog at nanog.org Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state I have cases open with both Cisco and Juniper on this, but wanted to see if anyone else had seen an issue like this because support has no idea. I have a Juniper QFX 5100 Core running in Virtual Chassis mode with 4 switches. I have 4 separate stacks of Cisco 3750 switches with 2x1GB uplinks bound into 4 different LACP trunks. I have had it happen twice now where I apply a trunk port config(not an LACP trunk) to a port that isn't a part of any of the LACP trunks and it causes all 4 of the Etherchannels on the Cisco stacked switches to go into an err-disable state with these messages: Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Gi1/0/48, putting Gi1/0/48 in err-disable state Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Po17, putting Gi1/0/48 in err-disable state Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Po17, putting Po17 in err-disable state Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/48, changed state to down Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Gi2/0/48, putting Gi2/0/48 in err-disable state (CA-TOR-1-7-2) Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/48, changed state to down Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel17, changed state to down Here is the config I am applying to the port that has caused this issue to happen twice now: set interfaces ge-0/0/67 description "Firewall Port" set interfaces ge-0/0/67 unit 0 family ethernet-switching interface-mode trunk set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 9-10 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 29 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 31-32 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 43 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 50-51 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 56 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 58 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 66 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 68 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 90 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 143 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 170 The issue happens within a couple of minutes of committing the config on the Juniper side, there are no cables plugged into port 0/0/67 so technically there shouldn't be any BPDU's sent out since there isn't a port change. Juniper Support wants me to turn on trace option and then run though a bunch of scenarios, the issue is that testing this takes down my network. Just wanted to put it out there to see if anyone else had run into a situation similar to this. TIA Joe From hf0002+nanog at uah.edu Thu Apr 5 21:11:14 2018 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Thu, 05 Apr 2018 21:11:14 +0000 Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state In-Reply-To: References: Message-ID: On Thu, Apr 5, 2018 at 3:58 PM Joseph Jenkins wrote: > Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected > on Po17, putting Po17 in err-disable state > We have to do this on all of our Cisco Port-channels that lead to Brocade ICX switches: no spanning-tree etherchannel guard misconfig If we don't do it, after a couple of days, the Cisco will err-disable the Port-channel just as you describe. I guess the misconfig detection is incompatible with the Brocade OS. We have seen no ill effects from this, as we are using "mode active" on all our Port-channels. So if there is a misconfiguration, the LAG does not come up for that port on either end, and we're good. Hope that helps. -- -- Hunter Fuller Network Engineer VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Systems and Infrastructure From joe at breathe-underwater.com Thu Apr 5 21:16:12 2018 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Thu, 5 Apr 2018 14:16:12 -0700 Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state In-Reply-To: References: Message-ID: No there isn't, but from what I am getting responses both onlist and off list is to just run this on the Cisco switches: no spanning-tree etherchannel guard misconfig and that should resolve the issue. Thanks Everyone. On Thu, Apr 5, 2018 at 2:10 PM, Robert Webb wrote: > I don't see any issue with the snippet of the config you provided for the > "Firewall Port". Is there a chance that the port ge-0/0/67 is referenced > somewhere else in the Juniper config that when applying your trunk setup is > causing issues? > > Just throw that out off the top of my head and not really thinking it > through. > > Robert > > -----Original Message----- > From: NANOG On Behalf Of Joseph Jenkins > Sent: Thursday, April 5, 2018 4:58 PM > To: nanog at nanog.org > Subject: Juniper Config Commit causes Cisco Etherchannels to go into > err-disable state > > I have cases open with both Cisco and Juniper on this, but wanted to see > if anyone else had seen an issue like this because support has no idea. > > I have a Juniper QFX 5100 Core running in Virtual Chassis mode with 4 > switches. I have 4 separate stacks of Cisco 3750 switches with 2x1GB > uplinks bound into 4 different LACP trunks. I have had it happen twice now > where I apply a trunk port config(not an LACP trunk) to a port that isn't a > part of any of the LACP trunks and it causes all 4 of the Etherchannels on > the Cisco stacked switches to go into an err-disable state with these > messages: > > Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected > on Gi1/0/48, putting Gi1/0/48 in err-disable state > > Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected > on Po17, putting Gi1/0/48 in err-disable state > > Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected > on Po17, putting Po17 in err-disable state > > Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface > GigabitEthernet1/0/48, changed state to down > > Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected > on Gi2/0/48, putting Gi2/0/48 in err-disable state (CA-TOR-1-7-2) > > Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface > GigabitEthernet2/0/48, changed state to down > > Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface > Port-channel17, changed state to down > > Here is the config I am applying to the port that has caused this issue to > happen twice now: > > set interfaces ge-0/0/67 description "Firewall Port" > set interfaces ge-0/0/67 unit 0 family ethernet-switching interface-mode > trunk set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan > members 9-10 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan > members 29 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan > members 31-32 set interfaces ge-0/0/67 unit 0 family ethernet-switching > vlan members 43 set interfaces ge-0/0/67 unit 0 family ethernet-switching > vlan members 50-51 set interfaces ge-0/0/67 unit 0 family > ethernet-switching vlan members 56 set interfaces ge-0/0/67 unit 0 family > ethernet-switching vlan members 58 set interfaces ge-0/0/67 unit 0 family > ethernet-switching vlan members 66 set interfaces ge-0/0/67 unit 0 family > ethernet-switching vlan members 68 set interfaces ge-0/0/67 unit 0 family > ethernet-switching vlan members 90 set interfaces ge-0/0/67 unit 0 family > ethernet-switching vlan members 143 set interfaces ge-0/0/67 unit 0 family > ethernet-switching vlan members 170 > > The issue happens within a couple of minutes of committing the config on > the Juniper side, there are no cables plugged into port 0/0/67 so > technically there shouldn't be any BPDU's sent out since there isn't a port > change. > > Juniper Support wants me to turn on trace option and then run though a > bunch of scenarios, the issue is that testing this takes down my network. > > Just wanted to put it out there to see if anyone else had run into a > situation similar to this. > > TIA > > Joe > From SNaslund at medline.com Thu Apr 5 21:22:46 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 5 Apr 2018 21:22:46 +0000 Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B402A8742B39@MUNPRDMBXA1.medline.com> I am kind of confused by your configuration. If the Cisco side is configured as LACP trunk, then the Juniper side also needs to be configured as LACP trunks. Spanning-tree would be getting confused because the Cisco is treating the LACP trunk as a single interface for purposes of spanning-tree (which should be configured at the port-channel level), Juniper is considering them to all be individual ports and would be sending BPDUs over each individual interface. The Cisco is correctly error disabling the port because it detects individual port BPDUs and determines that the channel is misconfigured. Or am I missing something in your config completely? If you are configuring ports other than the connected ports as trunks then your case makes sense. One thing that might cause you issue is the VLAN access of the LACP trunk. If one side has an vlan access list and the other side does not, you might get a spanning tree error when you configure a port on a new VLAN. Essentially you have a "trunk all" on one side and a new VLAN is showing up on a trunk that is not allowed on the other side. It would also help to see your spanning tree configuration (i.e. are both side running the same spanning tree mode?). The clue here is that the event triggers even though the port is not up yet. If you configure a new port on a VLAN that is not currently up, the VLAN will come up on all trunks that are allowed to have all VLANs immediately. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joseph Jenkins >Sent: Thursday, April 05, 2018 3:58 PM >To: nanog at nanog.org >ubject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state > >I have cases open with both Cisco and Juniper on this, but wanted to see if anyone else had seen an issue like this because support has no idea. > >I have a Juniper QFX 5100 Core running in Virtual Chassis mode with 4 switches. I have 4 separate stacks of Cisco 3750 switches with 2x1GB uplinks >bound into 4 different LACP trunks. I have had it happen twice now where I apply a trunk port config(not an LACP trunk) to a port that isn't a part of >any of the LACP trunks and it causes all 4 of the Etherchannels on the Cisco stacked switches to go into an err-disable state with these >messages: > >Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Gi1/0/48, putting Gi1/0/48 in err-disable state > >Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Po17, putting Gi1/0/48 in err-disable state > >Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Po17, putting Po17 in err-disable state > >Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/48, changed state to down > >Mar 14 07:11:33: %PM-4-ERR_DISABLE: channel-misconfig (STP) error detected on Gi2/0/48, putting Gi2/0/48 in err-disable state (CA-TOR-1-7-2) > >Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/48, changed state to down > >Mar 14 07:11:34: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel17, changed state to down > >Here is the config I am applying to the port that has caused this issue to happen twice now: > >set interfaces ge-0/0/67 description "Firewall Port" >set interfaces ge-0/0/67 unit 0 family ethernet-switching interface-mode trunk set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members >9-10 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 29 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members >31-32 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 43 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members >50-51 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 56 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members >58 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 66 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 68 >set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 90 set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 143 >set interfaces ge-0/0/67 unit 0 family ethernet-switching vlan members 170 > >The issue happens within a couple of minutes of committing the config on the Juniper side, there are no cables plugged into port 0/0/67 so technically >there shouldn't be any BPDU's sent out since there isn't a port change. > >Juniper Support wants me to turn on trace option and then run though a bunch of scenarios, the issue is that testing this takes down my network. > >Just wanted to put it out there to see if anyone else had run into a situation similar to this. > >TIA > >Joe From SNaslund at medline.com Thu Apr 5 21:26:14 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 5 Apr 2018 21:26:14 +0000 Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B402A8742B4B@MUNPRDMBXA1.medline.com> It really does not resolve anything it just allows a bad configuration to work. The guard is there so that if one side is configured as a channel and the other side is not, the channel gets shut down. Allowing it to remain up can cause a BPDU loop. Your spanning tree is trying to tell you something, you should listen or you could get really hard to isolate issues. Steven Naslund Chicago IL >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joseph Jenkins >Sent: Thursday, April 05, 2018 4:16 PM >To: Robert Webb >Cc: nanog at nanog.org >Subject: Re: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state > >No there isn't, but from what I am getting responses both onlist and off list is to just run this on the Cisco switches: > >no spanning-tree etherchannel guard misconfig > >and that should resolve the issue. > >Thanks Everyone. From joe at breathe-underwater.com Thu Apr 5 21:34:07 2018 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Thu, 5 Apr 2018 14:34:07 -0700 Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state In-Reply-To: <9578293AE169674F9A048B2BC9A081B402A8742B4B@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B402A8742B4B@MUNPRDMBXA1.medline.com> Message-ID: Steve let me clarify the config I am applying has nothing to do with an LACP trunk or any of my existing LACP trunks. It is a completely different configuration on a completely different interface, the only similarity is that I am trying to configure a trunk interface on the Juniper side for multiple vlans. There is no LACP configuration involved. On Thu, Apr 5, 2018 at 2:26 PM, Naslund, Steve wrote: > It really does not resolve anything it just allows a bad configuration to > work. The guard is there so that if one side is configured as a channel > and the other side is not, the channel gets shut down. Allowing it to > remain up can cause a BPDU loop. Your spanning tree is trying to tell you > something, you should listen or you could get really hard to isolate issues. > > Steven Naslund > Chicago IL > > >-----Original Message----- > >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joseph Jenkins > >Sent: Thursday, April 05, 2018 4:16 PM > >To: Robert Webb > >Cc: nanog at nanog.org > >Subject: Re: Juniper Config Commit causes Cisco Etherchannels to go into > err-disable state > > > >No there isn't, but from what I am getting responses both onlist and off > list is to just run this on the Cisco switches: > > > >no spanning-tree etherchannel guard misconfig > > > >and that should resolve the issue. > > > >Thanks Everyone. > > From joe at breathe-underwater.com Thu Apr 5 21:38:15 2018 From: joe at breathe-underwater.com (Joseph Jenkins) Date: Thu, 5 Apr 2018 14:38:15 -0700 Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B402A8742B4B@MUNPRDMBXA1.medline.com> Message-ID: This are also no new vlans being used at all. They are all already existing on the switches involved and nothing is being added. In fact what makes this even weirder is that I already have that exact same port configuration running on port 1/0/67 of the Juniper and it doesn't cause me any issues nor did it cause any issues when the config was applied. This existing port 1/0/67 has gone down/up as the firewall has been rebooted and doesn't cause any issues or hiccups on the network. For reference the attached firewall is an ASA which doesn't do spanning tree anyways. set interfaces ge-1/0/67 description "Firewall Port-2" set interfaces ge-1/0/67 unit 0 family ethernet-switching interface-mode trunk set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 9-10 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 29 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 31-32 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 43 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 50-51 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 56 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 58 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 66 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 68 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 90 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 143 set interfaces ge-1/0/67 unit 0 family ethernet-switching vlan members 170 On Thu, Apr 5, 2018 at 2:34 PM, Joseph Jenkins wrote: > Steve let me clarify the config I am applying has nothing to do with an > LACP trunk or any of my existing LACP trunks. It is a completely different > configuration on a completely different interface, the only similarity is > that I am trying to configure a trunk interface on the Juniper side for > multiple vlans. There is no LACP configuration involved. > > On Thu, Apr 5, 2018 at 2:26 PM, Naslund, Steve > wrote: > >> It really does not resolve anything it just allows a bad configuration to >> work. The guard is there so that if one side is configured as a channel >> and the other side is not, the channel gets shut down. Allowing it to >> remain up can cause a BPDU loop. Your spanning tree is trying to tell you >> something, you should listen or you could get really hard to isolate issues. >> >> Steven Naslund >> Chicago IL >> >> >-----Original Message----- >> >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joseph Jenkins >> >Sent: Thursday, April 05, 2018 4:16 PM >> >To: Robert Webb >> >Cc: nanog at nanog.org >> >Subject: Re: Juniper Config Commit causes Cisco Etherchannels to go into >> err-disable state >> > >> >No there isn't, but from what I am getting responses both onlist and off >> list is to just run this on the Cisco switches: >> > >> >no spanning-tree etherchannel guard misconfig >> > >> >and that should resolve the issue. >> > >> >Thanks Everyone. >> >> > From SNaslund at medline.com Thu Apr 5 21:39:56 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 5 Apr 2018 21:39:56 +0000 Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B402A8742B4B@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402A8742B78@MUNPRDMBXA1.medline.com> Got it. Do any of those trunks add a new VLAN to the switch that was not active before? If so, that would cause a BPDU over all trunks that allow that VLAN. Even if the port is not up yet, by adding the VLAN to ANY trunk you are implying that it should be active on ALL trunks that are not VLAN limited. Steve >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joseph Jenkins >Sent: Thursday, April 05, 2018 4:34 PM >To: nanog at nanog.org >Subject: Re: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state > >Steve let me clarify the config I am applying has nothing to do with an LACP trunk or any of my existing LACP trunks. It is a completely different >configuration on a completely different interface, the only similarity is that I am trying to configure a trunk interface on the Juniper side for >multiple vlans. There is no LACP configuration involved. From jared at puck.nether.net Thu Apr 5 21:57:17 2018 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 5 Apr 2018 17:57:17 -0400 Subject: Why doesn't "Cloudflare 1.1.1.1" compress root answers? In-Reply-To: References: <87a7ukxdow.fsf@miraculix.mork.no> Message-ID: <83488519-54C1-47C1-9B03-D970A803B887@puck.nether.net> Yes.. Check 4.1.4 of https://www.ietf.org/rfc/rfc1035.txt > On Apr 5, 2018, at 4:22 PM, Anurag Bhatia wrote: > > Hi Bjørn > > > Never realised of such compression on answered. Is this is something well > documented? Curious. > > From bjorn at mork.no Thu Apr 5 22:00:01 2018 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 06 Apr 2018 00:00:01 +0200 Subject: Why doesn't "Cloudflare 1.1.1.1" compress root answers? In-Reply-To: (Anurag Bhatia's message of "Fri, 6 Apr 2018 01:52:55 +0530") References: <87a7ukxdow.fsf@miraculix.mork.no> Message-ID: <87muyhuxem.fsf@miraculix.mork.no> Anurag Bhatia writes: > Never realised of such compression on answered. Is this is something well > documented? Curious. https://tools.ietf.org/html/rfc1035#section-4.1.4 Bjørn From dkenline at hotmail.com Thu Apr 5 20:32:17 2018 From: dkenline at hotmail.com (Doug Kenline) Date: Thu, 5 Apr 2018 20:32:17 +0000 Subject: CDN-provided caching platforms? In-Reply-To: References: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> <7149.1522164172@turing-police.cc.vt.edu> <001b01d3cbb9$de974440$9bc5ccc0$@gvtc.com>, Message-ID: I received this in my email today.......seemed timely regarding this thread..........please forgive if not appropriate use of list......does this add anything to the conversation? stll learning here....i like the picture.........thank you... doug kenline reston, virginia Dear Doug, We are hearing from our global service provider customers about their frustrations with understanding their CDN traffic. Since CDN traffic can originate from multiple locations, including caches outside of the CDN’s own network, it’s difficult to see which traffic is associated with each CDN, where that traffic enters your network, and how it changes over time. Kentik excels at tagging and labeling network flow data with additional context, including labels to identify traffic that’s associated with CDNs. By filtering or grouping traffic per CDN our customers can make more informed traffic engineering decisions, find and fix CDN traffic origin misconfigurations, and negotiate with CDN operators using data-driven insights.. Kentik’s view of current traffic inbound to Sprint’s network, broken out by geography, prefix and top talker IP address. Daniel Garcia Kentik.com | 408.781.6664 m 625 Second Street, Suite 100, San Francisco, CA 94107 LinkedIn ________________________________ From: NANOG on behalf of Anurag Bhatia Sent: Wednesday, April 4, 2018 5:31 PM To: Aaron Gould Cc: NANOG Mailing List Subject: Re: CDN-provided caching platforms? Hi Aaron I see the Amazon Prime video streams coming from Amazon Web Services Cloudfront CDN. Unsure of other places. Hard to do a global check on available platforms like say RIPE Atlas. And AWS Cloudfront does has the option of edge locations not connected to their backbone. On Wed, Apr 4, 2018 at 7:38 AM, Aaron Gould wrote: > I'm wondering if/when Amazon Prime Video will have a CDN system to roll-out > to ISP's like OCA, FNA, GGC, etc > > Anyone here anything about Amazon Video or any other big names like that ? > > - Aaron > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of > valdis.kletnieks at vt.edu > Sent: Tuesday, March 27, 2018 10:23 AM > To: Russell Berg > Cc: nanog at nanog.org > Subject: Re: CDN-provided caching platforms? > > On Tue, 27 Mar 2018 02:26:24 -0000, Russell Berg said: > > > I was wondering if there are other CDN caching platforms out there we > > should be researching/deploying? > > Does traffic analysis show any other destinations that have enough traffic > that caching might help? > > > -- Anurag Bhatia anuragbhatia.com From aaron1 at gvtc.com Fri Apr 6 14:46:42 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 6 Apr 2018 09:46:42 -0500 Subject: CDN-provided caching platforms? In-Reply-To: References: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> <7149.1522164172@turing-police.cc.vt.edu> <001b01d3cbb9$de974440$9bc5ccc0$@gvtc.com>, Message-ID: <000701d3cdb6$147b6750$3d7235f0$@gvtc.com> Thanks Doug, Kentik sounds familiar, I think I've spoken with them at a conference once or twice... a quick like at their website reminds me that they focus on ddos and understanding traffic better... not sure how this applies to the thread originated by Russell. -Aaron From aaron1 at gvtc.com Fri Apr 6 14:59:27 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 6 Apr 2018 09:59:27 -0500 Subject: CDN-provided caching platforms? In-Reply-To: References: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> <7149.1522164172@turing-police.cc.vt.edu> <001b01d3cbb9$de974440$9bc5ccc0$@gvtc.com> Message-ID: <000901d3cdb7$dc3fbbf0$94bf33d0$@gvtc.com> Thanks Anurag, is there anyone on the list from Amazon AWS Cloudfront that can speak to this ? “And AWS Cloudfront does has the option of edge locations not connected to their backbone.“ I’m an ISP and have fb fna, nf oca, ggc, and Akamai aanp, … does Amazon AWS Cloudfront ship servers to locations like mine ? -Aaron From peter.phaal at gmail.com Fri Apr 6 15:39:46 2018 From: peter.phaal at gmail.com (Peter Phaal) Date: Fri, 6 Apr 2018 08:39:46 -0700 Subject: Juniper releases sFlow support for MX routers Message-ID: Hi All, I thought there might be interest in availability of sFlow in Junos OS Release 18.1R1 for MX routers: https://blog.sflow.com/2018/04/sflow-available-on-juniper-mx-series.html Peter From hugo at slabnet.com Fri Apr 6 16:18:49 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 6 Apr 2018 09:18:49 -0700 Subject: CDN-provided caching platforms? In-Reply-To: <000701d3cdb6$147b6750$3d7235f0$@gvtc.com> References: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> <7149.1522164172@turing-police.cc.vt.edu> <001b01d3cbb9$de974440$9bc5ccc0$@gvtc.com> <000701d3cdb6$147b6750$3d7235f0$@gvtc.com> Message-ID: <20180406161849.GA4155@bamboo.slabnet.com> On Fri 2018-Apr-06 09:46:42 -0500, Aaron Gould wrote: >Thanks Doug, Kentik sounds familiar, I think I've spoken with them at a >conference once or twice... a quick like at their website reminds me that >they focus on ddos and understanding traffic better... not sure how this >applies to the thread originated by Russell. * Use Kentik (or other netflow/visibility tools) to identify your top traffic sources * focus effort on those to work out if you can peer with them or get caching appliances from them * profit -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From erich at gotfusion.net Fri Apr 6 16:25:12 2018 From: erich at gotfusion.net (Kaiser, Erich) Date: Fri, 6 Apr 2018 11:25:12 -0500 Subject: CDN-provided caching platforms? In-Reply-To: <20180406161849.GA4155@bamboo.slabnet.com> References: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> <7149.1522164172@turing-police.cc.vt.edu> <001b01d3cbb9$de974440$9bc5ccc0$@gvtc.com> <000701d3cdb6$147b6750$3d7235f0$@gvtc.com> <20180406161849.GA4155@bamboo.slabnet.com> Message-ID: AS-stats works well for this and its free... Erich Kaiser The Fusion Network erich at gotfusion.net Office: 815-570-3101 On Fri, Apr 6, 2018 at 11:18 AM, Hugo Slabbert wrote: > On Fri 2018-Apr-06 09:46:42 -0500, Aaron Gould wrote: > > Thanks Doug, Kentik sounds familiar, I think I've spoken with them at a >> conference once or twice... a quick like at their website reminds me that >> they focus on ddos and understanding traffic better... not sure how this >> applies to the thread originated by Russell. >> > > * Use Kentik (or other netflow/visibility tools) to identify your top > traffic sources > * focus effort on those to work out if you can peer with them or get > caching appliances from them > * profit > > -- > Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com > pgp key: B178313E | also on Signal > From erich at gotfusion.net Fri Apr 6 16:28:39 2018 From: erich at gotfusion.net (Kaiser, Erich) Date: Fri, 6 Apr 2018 11:28:39 -0500 Subject: Attn BrightCloud Message-ID: We are seeing false positives on NAt'd IPs on our customers networks, please correct this issue. This started a few days ago... Erich Kaiser The Fusion Network erich at gotfusion.net Office: 815-570-3101 From hugo at slabnet.com Fri Apr 6 16:29:21 2018 From: hugo at slabnet.com (Hugo Slabbert) Date: Fri, 6 Apr 2018 09:29:21 -0700 Subject: CDN-provided caching platforms? In-Reply-To: References: <39524233ba9648228730dd8430d55e25@exchange1.win.internal> <7149.1522164172@turing-police.cc.vt.edu> <001b01d3cbb9$de974440$9bc5ccc0$@gvtc.com> <000701d3cdb6$147b6750$3d7235f0$@gvtc.com> <20180406161849.GA4155@bamboo.slabnet.com> Message-ID: <20180406162921.GB4155@bamboo.slabnet.com> On Fri 2018-Apr-06 11:25:12 -0500, Kaiser, Erich wrote: >AS-stats works well for this and its free... +1 Or see the other recent netflow tools thread[1] for inspiration. -- Hugo Slabbert | email, xmpp/jabber: hugo at slabnet.com pgp key: B178313E | also on Signal [1] https://mailman.nanog.org/pipermail/nanog/2018-March/094490.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From eyeronic.design at gmail.com Fri Apr 6 16:33:35 2018 From: eyeronic.design at gmail.com (Mike Hale) Date: Fri, 6 Apr 2018 09:33:35 -0700 Subject: Attn BrightCloud In-Reply-To: References: Message-ID: *cough* http://brightcloud.com/tools/url-ip-lookup.php You can request removals there. On Fri, Apr 6, 2018 at 9:28 AM, Kaiser, Erich wrote: > We are seeing false positives on NAt'd IPs on our customers networks, > please correct this issue. This started a few days ago... > > > Erich Kaiser > The Fusion Network > erich at gotfusion.net > Office: 815-570-3101 -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From cscora at apnic.net Fri Apr 6 18:03:30 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Apr 2018 04:03:30 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180406180330.EC9C412A7@thyme.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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. 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 07 Apr, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 690896 Prefixes after maximum aggregation (per Origin AS): 266872 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 332608 Total ASes present in the Internet Routing Table: 60156 Prefixes per ASN: 11.49 Origin-only ASes present in the Internet Routing Table: 51982 Origin ASes announcing only one prefix: 22730 Transit ASes present in the Internet Routing Table: 8174 Transit-only ASes present in the Internet Routing Table: 266 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 50 Number of instances of unregistered ASNs: 50 Number of 32-bit ASNs allocated by the RIRs: 22082 Number of 32-bit ASNs visible in the Routing Table: 17722 Prefixes from 32-bit ASNs in the Routing Table: 73655 Number of bogon 32-bit ASNs visible in the Routing Table: 20 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 310 Number of addresses announced to Internet: 2861813986 Equivalent to 170 /8s, 147 /16s and 208 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 230077 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 188751 Total APNIC prefixes after maximum aggregation: 53654 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 187714 Unique aggregates announced from the APNIC address blocks: 76628 APNIC Region origin ASes present in the Internet Routing Table: 8693 APNIC Prefixes per ASN: 21.59 APNIC Region origin ASes announcing only one prefix: 2439 APNIC Region transit ASes present in the Internet Routing Table: 1288 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 24 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3653 Number of APNIC addresses announced to Internet: 766814946 Equivalent to 45 /8s, 180 /16s and 170 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 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: 206144 Total ARIN prefixes after maximum aggregation: 98618 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 206770 Unique aggregates announced from the ARIN address blocks: 97746 ARIN Region origin ASes present in the Internet Routing Table: 18123 ARIN Prefixes per ASN: 11.41 ARIN Region origin ASes announcing only one prefix: 6693 ARIN Region transit ASes present in the Internet Routing Table: 1795 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2332 Number of ARIN addresses announced to Internet: 1109310624 Equivalent to 66 /8s, 30 /16s and 188 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 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: 188163 Total RIPE prefixes after maximum aggregation: 90863 RIPE Deaggregation factor: 2.07 Prefixes being announced from the RIPE address blocks: 184468 Unique aggregates announced from the RIPE address blocks: 109731 RIPE Region origin ASes present in the Internet Routing Table: 24935 RIPE Prefixes per ASN: 7.40 RIPE Region origin ASes announcing only one prefix: 11306 RIPE Region transit ASes present in the Internet Routing Table: 3476 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6819 Number of RIPE addresses announced to Internet: 715437952 Equivalent to 42 /8s, 164 /16s and 183 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 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: 89159 Total LACNIC prefixes after maximum aggregation: 19670 LACNIC Deaggregation factor: 4.53 Prefixes being announced from the LACNIC address blocks: 90546 Unique aggregates announced from the LACNIC address blocks: 40664 LACNIC Region origin ASes present in the Internet Routing Table: 6983 LACNIC Prefixes per ASN: 12.97 LACNIC Region origin ASes announcing only one prefix: 1923 LACNIC Region transit ASes present in the Internet Routing Table: 1286 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4514 Number of LACNIC addresses announced to Internet: 172503776 Equivalent to 10 /8s, 72 /16s and 50 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 18627 Total AfriNIC prefixes after maximum aggregation: 4027 AfriNIC Deaggregation factor: 4.63 Prefixes being announced from the AfriNIC address blocks: 21088 Unique aggregates announced from the AfriNIC address blocks: 7581 AfriNIC Region origin ASes present in the Internet Routing Table: 1131 AfriNIC Prefixes per ASN: 18.65 AfriNIC Region origin ASes announcing only one prefix: 368 AfriNIC Region transit ASes present in the Internet Routing Table: 227 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 404 Number of AfriNIC addresses announced to Internet: 97351680 Equivalent to 5 /8s, 205 /16s and 120 /24s 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 4538 5416 4192 74 ERX-CERNET-BKB China Education and Rese 7545 3870 413 428 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2843 11130 778 KIXS-AS-KR Korea Telecom, KR 9829 2814 1499 544 BSNL-NIB National Internet Backbone, IN 7552 2716 1155 67 VIETEL-AS-AP Viettel Group, VN 9394 2631 4923 29 CTTNET China TieTong Telecommunications 45899 2585 1570 160 VNPT-AS-VN VNPT Corp, VN 17974 2322 928 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2178 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2089 417 216 TATACOMM-AS TATA Communications formerl 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 6327 3352 1323 85 SHAW - Shaw Communications Inc., CA 22773 3286 2988 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2167 405 108 MEGAPATH5-US - MegaPath Corporation, US 20115 2092 2484 447 CHARTER-NET-HKY-NC - Charter Communicat 16509 2043 4411 635 AMAZON-02 - Amazon.com, Inc., US 30036 1955 341 181 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1922 5071 607 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 11492 1793 228 537 CABLEONE - CABLE ONE, INC., US 16625 1707 831 1222 AKAMAI-AS - Akamai Technologies, Inc., 7018 1706 20205 1257 ATT-INTERNET4 - AT&T Services, Inc., US 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 12479 4059 1513 474 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 20940 2735 767 2003 AKAMAI-ASN1, US 8551 2114 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2036 1859 706 ROSTELECOM-AS, RU 34984 2018 334 480 TELLCOM-AS, TR 9121 1956 1692 19 TTNET, TR 13188 1607 100 46 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1233 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 8151 4328 3385 574 Uninet S.A. de C.V., MX 10620 3598 540 268 Telmex Colombia S.A., CO 11830 2641 369 85 Instituto Costarricense de Electricidad 6503 1625 437 53 Axtel, S.A.B. de C.V., MX 7303 1510 1023 192 Telecom Argentina S.A., AR 28573 1032 2251 174 CLARO S.A., BR 6147 1016 377 31 Telefonica del Peru S.A.A., PE 3816 1005 504 121 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 928 126 85 Alestra, S. de R.L. de C.V., MX 18881 908 1074 29 TELEF�NICA BRASIL S.A, BR 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 1143 396 44 LINKdotNET-AS, EG 37611 821 107 9 Afrihost, ZA 36903 741 372 137 MT-MPLS, MA 36992 705 1412 41 ETISALAT-MISR, EG 24835 638 850 15 RAYA-AS, EG 8452 631 1730 18 TE-AS TE-AS, EG 29571 471 68 12 ORANGE-COTE-IVOIRE, CI 37492 450 376 81 ORANGE-, TN 15399 364 35 7 WANANCHI-, KE 37342 360 32 1 MOVITEL, MZ 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 4538 5416 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4328 3385 574 Uninet S.A. de C.V., MX 12479 4059 1513 474 UNI2-AS, ES 7545 3870 413 428 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3598 540 268 Telmex Colombia S.A., CO 6327 3352 1323 85 SHAW - Shaw Communications Inc., CA 22773 3286 2988 151 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2843 11130 778 KIXS-AS-KR Korea Telecom, KR 9829 2814 1499 544 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 39891 3778 3758 ALJAWWALSTC-AS, SA 8151 4328 3754 Uninet S.A. de C.V., MX 12479 4059 3585 UNI2-AS, ES 7545 3870 3442 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3598 3330 Telmex Colombia S.A., CO 6327 3352 3267 SHAW - Shaw Communications Inc., CA 22773 3286 3135 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2716 2649 VIETEL-AS-AP Viettel Group, VN 9394 2631 2602 CTTNET China TieTong Telecommunications Corpora 11830 2641 2556 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 267359 UNALLOCATED 45.234.36.0/22 264144 ASAP GLOBAL TELECOM, BR 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.78.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.80.0/22 39407 CHITATELECOM-AS, RU 64111 UNALLOCATED 98.159.5.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.7.0/24 19555 KMI-NETWORK - Kinder Morgan, I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 100.127.16.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM 100.127.18.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 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:15 /9:12 /10:37 /11:100 /12:288 /13:564 /14:1098 /15:1900 /16:13371 /17:7800 /18:13591 /19:25132 /20:39238 /21:45076 /22:85970 /23:69237 /24:385229 /25:841 /26:604 /27:661 /28:35 /29:20 /30:17 /31:4 /32:56 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3141 3352 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 12479 2783 4059 UNI2-AS, ES 22773 2538 3286 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2061 2167 MEGAPATH5-US - MegaPath Corporation, US 11830 1989 2641 Instituto Costarricense de Electricidad y Telec 30036 1706 1955 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1604 3598 Telmex Colombia S.A., CO 8551 1577 2114 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 1554 1793 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1549 2:826 4:19 5:2759 6:59 7:1 8:1123 12:1881 13:183 14:1737 15:30 16:3 17:196 18:68 20:47 21:4 23:2542 24:2156 25:2 27:2197 31:1948 32:87 35:26 36:494 37:2680 38:1450 39:237 40:118 41:3030 42:598 43:1937 44:103 45:4024 46:3000 47:203 49:1289 50:1048 51:304 52:988 54:371 55:4 56:12 57:42 58:1505 59:1015 60:428 61:2134 62:1807 63:1797 64:4754 65:2217 66:4585 67:2346 68:1148 69:3194 70:1141 71:560 72:2096 74:2709 75:412 76:426 77:1541 78:1684 79:1917 80:1464 81:1414 82:1076 83:783 84:1034 85:2083 86:586 87:1312 88:934 89:2319 90:208 91:6272 92:1157 93:2384 94:2380 95:2758 96:658 97:357 98:935 99:133 100:79 101:1234 102:41 103:17264 104:3264 105:229 106:647 107:1765 108:710 109:2676 110:1578 111:1775 112:1267 113:1331 114:1121 115:1652 116:1640 117:1703 118:2114 119:1655 120:955 121:1061 122:2452 123:1805 124:1448 125:1882 128:982 129:640 130:448 131:1585 132:651 133:196 134:1005 135:226 136:455 137:499 138:1911 139:582 140:424 141:688 142:790 143:962 144:807 145:458 146:1164 147:760 148:1585 149:710 150:715 151:1058 152:760 153:310 154:1024 155:754 156:865 157:780 158:627 159:1663 160:932 161:747 162:2585 163:531 164:1040 165:1408 166:423 167:1408 168:3037 169:809 170:3716 171:428 172:1042 173:1962 174:883 175:750 176:1867 177:3969 178:2406 179:1202 180:2240 181:2200 182:2290 183:1143 184:913 185:13091 186:3573 187:2367 188:2747 189:2014 190:8133 191:1447 192:9820 193:5868 194:4777 195:3950 196:2493 197:1414 198:5507 199:5874 200:7395 201:4992 202:10321 203:10109 204:4523 205:2864 206:3071 207:3195 208:3981 209:3938 210:4026 211:2108 212:3018 213:2727 214:907 215:60 216:5859 217:2133 218:900 219:620 220:1724 221:1000 222:1042 223:1240 End of report From ktims at stargate.ca Fri Apr 6 18:31:17 2018 From: ktims at stargate.ca (Keenan Tims) Date: Fri, 6 Apr 2018 11:31:17 -0700 Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state In-Reply-To: <9578293AE169674F9A048B2BC9A081B402A8742B4B@MUNPRDMBXA1.medline.com> References: <9578293AE169674F9A048B2BC9A081B402A8742B4B@MUNPRDMBXA1.medline.com> Message-ID: What it's telling you is totally unclear, though. I've asked TAC to explain to me the packet behaviour that generates this errdisable, and haven't been able to get a clear answer from them. It seems to come out of 'nowhere' on multi-vendor networks, where all other vendors are perfectly happy and no operational or configuration issue is evident, other than Cisco shutting the port. As far as I can tell from the documentation's description of this case, it should not even be possible for it to trigger when LACP is in use (as the 'port channel' is negotiated by LACP, not configured by the user...), yet it certainly can. FWIW, I've also seen this between Juniper and Cisco, and have been forced to disable the misconfig detection. If you know exactly what Cisco's STP is telling me happened with this error, I'd really love to know, it might at least help to understand how it could be triggering, because it is definitely not 'port-channel misconfiguration'. Keenan On 2018-04-05 02:26 PM, Naslund, Steve wrote: > It really does not resolve anything it just allows a bad configuration to work. The guard is there so that if one side is configured as a channel and the other side is not, the channel gets shut down. Allowing it to remain up can cause a BPDU loop. Your spanning tree is trying to tell you something, you should listen or you could get really hard to isolate issues. > > Steven Naslund > Chicago IL > >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joseph Jenkins >> Sent: Thursday, April 05, 2018 4:16 PM >> To: Robert Webb >> Cc: nanog at nanog.org >> Subject: Re: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state >> >> No there isn't, but from what I am getting responses both onlist and off list is to just run this on the Cisco switches: >> >> no spanning-tree etherchannel guard misconfig >> >> and that should resolve the issue. >> >> Thanks Everyone. From md at bts.sk Fri Apr 6 18:50:54 2018 From: md at bts.sk (=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=) Date: Fri, 6 Apr 2018 20:50:54 +0200 Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B402A8742B4B@MUNPRDMBXA1.medline.com> Message-ID: <20180406184550.M96855@bts.sk> Please see the link below, that ugly hack should be disabled asap on all your Cisco boxes: https://supportforums.cisco.com/t5/lan-switching-and-routing/spanning-tree-etherchannel-guard-misconfig/td-p/1147273 MD On Fri, 6 Apr 2018 11:31:17 -0700, Keenan Tims wrote > What it's telling you is totally unclear, though. I've asked TAC to > explain to me the packet behaviour that generates this errdisable, and > haven't been able to get a clear answer from them. It seems to come out > of 'nowhere' on multi-vendor networks, where all other vendors are > perfectly happy and no operational or configuration issue is evident, > other than Cisco shutting the port. As far as I can tell from the > documentation's description of this case, it should not even be > possible for it to trigger when LACP is in use (as the 'port channel' > is negotiated by LACP, not configured by the user...), yet it > certainly can. > > FWIW, I've also seen this between Juniper and Cisco, and have been > forced to disable the misconfig detection. > > If you know exactly what Cisco's STP is telling me happened with this > error, I'd really love to know, it might at least help to understand > how it could be triggering, because it is definitely not 'port-channel > misconfiguration'. > > Keenan > > On 2018-04-05 02:26 PM, Naslund, Steve wrote: > > It really does not resolve anything it just allows a bad configuration to work. The guard is there so that if one side is configured as a channel and the other side is not, the channel gets shut down. Allowing it to remain up can cause a BPDU loop. Your spanning tree is trying to tell you something, you should listen or you could get really hard to isolate issues. > > > > Steven Naslund > > Chicago IL > > > >> -----Original Message----- > >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Joseph Jenkins > >> Sent: Thursday, April 05, 2018 4:16 PM > >> To: Robert Webb > >> Cc: nanog at nanog.org > >> Subject: Re: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state > >> > >> No there isn't, but from what I am getting responses both onlist and off list is to just run this on the Cisco switches: > >> > >> no spanning-tree etherchannel guard misconfig > >> > >> and that should resolve the issue. > >> > >> Thanks Everyone. From mlm at pixelgate.net Fri Apr 6 18:59:16 2018 From: mlm at pixelgate.net (Mark Milhollan) Date: Fri, 6 Apr 2018 11:59:16 -0700 (PDT) Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B402A8742B4B@MUNPRDMBXA1.medline.com> Message-ID: Sounds like the Juniper is leaking a "default" BPDU as it resets the various internal chip configurations, which the Cisco receives thus triggering the err-disable. /mark From mlm at pixelgate.net Fri Apr 6 19:04:54 2018 From: mlm at pixelgate.net (Mark Milhollan) Date: Fri, 6 Apr 2018 12:04:54 -0700 (PDT) Subject: Are any of you starting to get AI robocalls? In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B402A8741496@MUNPRDMBXA1.medline.com> <20180405145536.GA45423@meow.BKantor.net> <1522941173.14880.30.camel@n1uro> Message-ID: One can analyze the calling frequency, but even that's problematic as it can penalize a successful customer that isn't scamming. Besides as HAL wrote many of these calls are not originating in NA. If digital residential lines hadn't died they might make the original source visible making it easier to decide if the call seems legit, but for now an auto-attendant seems the easiest solution. /mark From aiunitelecom at gmail.com Fri Apr 6 15:32:53 2018 From: aiunitelecom at gmail.com (Moh Nassit) Date: Fri, 6 Apr 2018 11:32:53 -0400 Subject: Manageengine Netflowanalyzer In-Reply-To: References: Message-ID: > Hi, > It seem that Manageengine Netflowanalyzer support Netflow-lite with a > Cisco 4948E > http://help.netflowanalyzer.com/supported-devices > > Did someone get this working? I did a lot of tests but not able to get > data. Flows are correctly exported to the analyzer but no data are > displayed. > > Thanks > > > > > > From me at krygerism.com Mon Apr 9 00:34:52 2018 From: me at krygerism.com (Michael Krygeris) Date: Sun, 8 Apr 2018 20:34:52 -0400 Subject: Manageengine Netflowanalyzer In-Reply-To: References: Message-ID: You may be getting this confused with a different netflow lite. Cisco introduced 2 completely different "netflow lite" features over the last few years. It is very confusing. One is essentially a packet sample(like IPFIX PSAMP) and the other is just sampled netflow on a switch. The bad news is that the 4948E is the PSAMP style implementation, so you need to have an intermediary collector to maintain the flow cache off-switch(a bit like sflow). This makes for much more work for the collector. Most vendors just ignored it. There is only one collector/translator that I know of that will do this for you. NProbe. So you can grab an nprobe license and have it act as a translator between the 4948E and manage engine. I'm not trashing nprobe either. It's a great piece of software. I'm just saying that it's an unfortunate step that you have to take to get proper flow accounting out of the 4948E. More info here: https://www.ntop.org/products/netflow/nprobe/netflow-lite-plugin/ As an aside, the other netflow lite applies to edge switches like the 2960-X. This works well on standard NetFlow collectors. I was pretty flumuxed when they chose to use this term for 2 completely different things. Hopefully this is helpful. -Mike Krygeris On Fri, Apr 6, 2018 at 11:32 AM, Moh Nassit wrote: > > Hi, > > It seem that Manageengine Netflowanalyzer support Netflow-lite with a > > Cisco 4948E > > http://help.netflowanalyzer.com/supported-devices > > > > Did someone get this working? I did a lot of tests but not able to get > > data. Flows are correctly exported to the analyzer but no data are > > displayed. > > > > Thanks > > > > > > > > > > > > > From mehmet at akcin.net Mon Apr 9 04:26:38 2018 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 8 Apr 2018 21:26:38 -0700 Subject: TRNOG 2018 Message-ID: Hello everyone, It has been long time since we had a TRNOG meeting with external focus and international speakers. We are organizing TRNOG 2018 with international focus and we would like to extend this invite to NANOG. TRNOG 2018 will be held in Istanbul, Turkey 11 July 2018. For more details you can visit below link. https://www.eventbrite.com/e/trnog2018-tickets-44968764786 This is a fairly technically focused meeting which was held 3 times in the past bringing Academics, Turkish network engineers, System administrators and business development executives to discuss how to improve Turkish Internet. If you have any questions, feel free to reach out to me, and I can forward questions to right people. PS: program committee is still looking for great talks and if you want to present - please drop a note to pc at trnog.org Best Mehmet From ycompanys at gmail.com Sun Apr 8 23:20:17 2018 From: ycompanys at gmail.com (Yosem Companys) Date: Sun, 8 Apr 2018 16:20:17 -0700 Subject: Help Puerto Rico use tech for social good Message-ID: Dear friends and colleagues, - How should the Puerto Rican government use technology to improve quality of life and socioeconomic development, especially in the poorest and most vulnerable communities? I would appreciate your emailing me as soon as possible one-sentence proposed actions in the format of "Do X with Y to achieve Z." Feel free to share links to any case studies or articles that may show their successful implementation elsewhere. Your proposed actions could apply to any societal sector including and not limited to: - Accountability; - Affordable access to Internet, Web, mobile, or mesh, among others; - Agriculture; - Disaster relief; - Economic growth and development; - Education and training, whether primary, secondary, higher education, vocational, or online; - Entrepreneurship; - Environment; - Food; - Health; - Housing that's affordable but can resist storms; - Jobs; - Manufacturing; - Open data; - Open governance; - Pharma/Biotech; - Privacy; - Public safety; - Security, physical or cyber; - Transportation; and, - Water. Please share with your closest 1-million friends, post on all your social media accounts, or email to all your other lists. I truly appreciate your help. Thanks, Yosem From dp at datasoftcomnet.com Mon Apr 9 14:33:09 2018 From: dp at datasoftcomnet.com (DurgaPrasad - DatasoftComnet) Date: Mon, 9 Apr 2018 20:03:09 +0530 Subject: AS23456 Message-ID: <000301d3d00f$aedcf740$0c96e5c0$@datasoftcomnet.com> Hello all, What is this AS23456 - We are seeing some significant traffic in and out using AS-STATS reports. Thanks/DP --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From lists at benappy.com Mon Apr 9 14:52:47 2018 From: lists at benappy.com (Michel 'ic' Luczak) Date: Mon, 9 Apr 2018 16:52:47 +0200 Subject: AS23456 In-Reply-To: <000301d3d00f$aedcf740$0c96e5c0$@datasoftcomnet.com> References: <000301d3d00f$aedcf740$0c96e5c0$@datasoftcomnet.com> Message-ID: % Information related to 'AS23456 - AS23456' as-block: AS23456 - AS23456 descr: IANA reserved ASN block remarks: These AS numbers are reserved by IANA remarks: to represent 32bit AS numbers as remarks: 16bit AS numbers in the AS path remarks: information encoded with 16bit AS numbers. remarks: For more details please see RFC4893 remarks: http://iana.org/numbers/ org: ORG-IANA1-RIPE mnt-by: RIPE-DBM-MNT created: 2009-05-29T08:37:37Z last-modified: 2014-02-24T14:16:53Z source: RIPE > On 9 Apr 2018, at 16:33, DurgaPrasad - DatasoftComnet wrote: > > Hello all, > What is this AS23456 - We are seeing some significant traffic in and out using AS-STATS reports. > > Thanks/DP > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > From morrowc.lists at gmail.com Mon Apr 9 14:57:22 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 9 Apr 2018 10:57:22 -0400 Subject: AS23456 In-Reply-To: References: <000301d3d00f$aedcf740$0c96e5c0$@datasoftcomnet.com> Message-ID: or perhaps with more words: "maybe your stats gathering system is not AS4 ready? or something along the path(s) is not AS4 ready?" On Mon, Apr 9, 2018 at 10:52 AM, Michel 'ic' Luczak wrote: > % Information related to 'AS23456 - AS23456' > > as-block: AS23456 - AS23456 > descr: IANA reserved ASN block > remarks: These AS numbers are reserved by IANA > remarks: to represent 32bit AS numbers as > remarks: 16bit AS numbers in the AS path > remarks: information encoded with 16bit AS numbers. > remarks: For more details please see RFC4893 > remarks: http://iana.org/numbers/ > org: ORG-IANA1-RIPE > mnt-by: RIPE-DBM-MNT > created: 2009-05-29T08:37:37Z > last-modified: 2014-02-24T14:16:53Z > source: RIPE > > > > On 9 Apr 2018, at 16:33, DurgaPrasad - DatasoftComnet < > dp at datasoftcomnet.com> wrote: > > > > Hello all, > > What is this AS23456 - We are seeing some significant traffic in and out > using AS-STATS reports. > > > > Thanks/DP > > > > > > > > > > --- > > This email has been checked for viruses by Avast antivirus software. > > https://www.avast.com/antivirus > > > > From dp at datasoftcomnet.com Mon Apr 9 15:00:18 2018 From: dp at datasoftcomnet.com (DurgaPrasad - DatasoftComnet) Date: Mon, 9 Apr 2018 20:30:18 +0530 Subject: AS23456 In-Reply-To: References: <000301d3d00f$aedcf740$0c96e5c0$@datasoftcomnet.com> Message-ID: <000b01d3d013$7a0880d0$6e198270$@datasoftcomnet.com> Yes I saw that. so really concerned what is it. Regards Durga Prasad +919849111010 From: Michel 'ic' Luczak [mailto:lists at benappy.com] Sent: 09 April 2018 20:23 To: DurgaPrasad - DatasoftComnet Cc: nanog at nanog.org Subject: Re: AS23456 % Information related to 'AS23456 - AS23456' as-block: AS23456 - AS23456 descr: IANA reserved ASN block remarks: These AS numbers are reserved by IANA remarks: to represent 32bit AS numbers as remarks: 16bit AS numbers in the AS path remarks: information encoded with 16bit AS numbers. remarks: For more details please see RFC4893 remarks: http://iana.org/numbers/ org: ORG-IANA1-RIPE mnt-by: RIPE-DBM-MNT created: 2009-05-29T08:37:37Z last-modified: 2014-02-24T14:16:53Z source: RIPE On 9 Apr 2018, at 16:33, DurgaPrasad - DatasoftComnet wrote: Hello all, What is this AS23456 - We are seeing some significant traffic in and out using AS-STATS reports. Thanks/DP --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus From dp at datasoftcomnet.com Mon Apr 9 15:03:23 2018 From: dp at datasoftcomnet.com (DurgaPrasad - DatasoftComnet) Date: Mon, 9 Apr 2018 20:33:23 +0530 Subject: AS23456 In-Reply-To: References: <000301d3d00f$aedcf740$0c96e5c0$@datasoftcomnet.com> Message-ID: <001501d3d013$e7d33150$b77993f0$@datasoftcomnet.com> Thanks all. Understood. Anyone know if AS-STATS understands AS4? Regards Durga Prasad +919849111010 From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: 09 April 2018 20:27 To: Michel 'ic' Luczak Cc: DurgaPrasad - DatasoftComnet; nanog list Subject: Re: AS23456 or perhaps with more words: "maybe your stats gathering system is not AS4 ready? or something along the path(s) is not AS4 ready?" On Mon, Apr 9, 2018 at 10:52 AM, Michel 'ic' Luczak wrote: % Information related to 'AS23456 - AS23456' as-block: AS23456 - AS23456 descr: IANA reserved ASN block remarks: These AS numbers are reserved by IANA remarks: to represent 32bit AS numbers as remarks: 16bit AS numbers in the AS path remarks: information encoded with 16bit AS numbers. remarks: For more details please see RFC4893 remarks: http://iana.org/numbers/ org: ORG-IANA1-RIPE mnt-by: RIPE-DBM-MNT created: 2009-05-29T08:37:37Z last-modified: 2014-02-24T14:16:53Z source: RIPE > On 9 Apr 2018, at 16:33, DurgaPrasad - DatasoftComnet wrote: > > Hello all, > What is this AS23456 - We are seeing some significant traffic in and out using AS-STATS reports. > > Thanks/DP > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > From nanog at radu-adrian.feurdean.net Mon Apr 9 18:23:06 2018 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Mon, 09 Apr 2018 20:23:06 +0200 Subject: AS23456 In-Reply-To: <001501d3d013$e7d33150$b77993f0$@datasoftcomnet.com> References: <000301d3d00f$aedcf740$0c96e5c0$@datasoftcomnet.com> <001501d3d013$e7d33150$b77993f0$@datasoftcomnet.com> Message-ID: <1523298186.2430544.1331936304.508DD993@webmail.messagingengine.com> On Mon, Apr 9, 2018, at 17:03, DurgaPrasad - DatasoftComnet wrote: > Thanks all. Understood. > > Anyone know if AS-STATS understands AS4? > It does, if the flow source sends the information needed. From arnold at nipper.de Tue Apr 10 04:15:06 2018 From: arnold at nipper.de (Arnold Nipper) Date: Tue, 10 Apr 2018 06:15:06 +0200 Subject: Call for Presentations European Peering Forum 13 (EPF13) / NANOG Message-ID: Call for Presentations European Peering Forum 13 (EPF13) AMS-IX, DE-CIX, LINX, Netnod are happy to host the 13rd European Peering Forum (EPF) in Athens, Greece from the 17th - 19th September 2018. The event will welcome up to 300 peering managers and coordinators from networks connected to the host Internet exchanges. Besides an interesting topical agenda, the three-day event accommodates room for attendees to meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations and lightning talks related to peering and technical topics of interconnection. Your presentation should address * Interconnection Automation * Regional Peering * Interconnection / Peering Internet Governance and Regulatory Topics * Economic and Product Trends * Peering / interconnection strategies * Interesting findings about peering / interconnection * 400GE and beyond Submissions =========== Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee . Please include: * Author's name and e-mail * Presentation title * Abstract * Slides (if available) * Time requested Deadlines ========= Presentation Abstract Deadline 16/07/2018 12:00 UTC Final Selection of Speakers 27/07/2018 Presentation Slides Submission Deadline 03/09/2018 12:00 UTC More information about the event and other activities around EPF13 may be found at * https://peering-forum.eu/ * https://www.facebook.com/groups/1486607564933665/ Best regards Arnold -- Arnold Nipper email: arnold at nipper.de mobile: +49 172 2650958 From spoofer-info at caida.org Tue Apr 10 00:44:15 2018 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Mon, 9 Apr 2018 17:44:15 -0700 Subject: Spoofer Report for NANOG for Mar 2018 Message-ID: <201804100044.w3A0iFTV087598@fro.caida.org> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From rod.beck at unitedcablecompany.com Tue Apr 10 19:30:22 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Tue, 10 Apr 2018 19:30:22 +0000 Subject: TLS 1.3 Version Message-ID: https://techxplore.com/news/2018-03-internet-tls-life.html Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com New York City & Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From mahtin at mahtin.com Tue Apr 10 17:00:03 2018 From: mahtin at mahtin.com (Martin J. Levy) Date: Tue, 10 Apr 2018 10:00:03 -0700 Subject: Fixing reachability for 1.1.1.1 Message-ID: Hello all, Marty Strong, here at Cloudflare, has written an excellent blog entry summarizing all the work everyone at Cloudflare has done in the last few months cleaning up access to 1.1.1.1. https://blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally/ A large number of ASNs have already fixed their internal use of 1.1.1.0/24 (and 1.0.0.0/24) in order to let traffic flow towards 1.1.1.1 & 1.0.0.1. Thank you all. Now that 1.1.1.1 has been live for week+ (and traffic is growing significantly), it's important to say we are thankful to all the networks and hardware companies who have assisted us in this effort. The 1.1.1.0/24 space was never "private IP space" - it's not part of RFC1918 even if some think/thought it was. However, we’re not done, nor are others. Please take some time today to check your network for 1.1.1.1 reachability. Keep in mind, sometimes it could be your CPE hardware vs your network. All is explained in the link above. Thanks, Martin @ Cloudflare From brian.cruze at verizon.com Wed Apr 11 15:50:07 2018 From: brian.cruze at verizon.com (brian.cruze at verizon.com) Date: Wed, 11 Apr 2018 15:50:07 +0000 Subject: Looking for a BGP/Routing/NOC contact at NTT Message-ID: If someone could contact me off list, I would appreciate it.      From rsk at gsp.org Wed Apr 11 19:23:37 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 11 Apr 2018 15:23:37 -0400 Subject: Fwd: [Help stop Georgia S.B. 315, a bad bill for cybersecurity] Message-ID: <20180411192337.GA10349@gsp.org> ----- Forwarded message from Bennett Cyphers ----- > From: Bennett Cyphers > Date: Wed, 11 Apr 2018 11:41:40 -0700 > Subject: [ NNSquad ] Help stop Georgia S.B. 315, a bad bill for cybersecurity > Reply-To: "stop-sb315 at eff.org" > > Hello all, > > I'm Bennett Cyphers, staff technologist at EFF. For the last few months, > we have been working with local grassroots advocates and infosec experts > in Georgia to oppose S.B. 315, a bill that would expand the state's > existing hacking laws. We believe it's an unnecessary, harmful > overreach. Because of the vague definitions in the bill, we are > concerned that it will chill independent security research. Further, the > bill aims to legalize "hack back" measures which could harm innocent > users, especially victims of malware whose devices have been > appropriated by bad actors. > > We are collecting signatures from cybersecurity specialists, > technologists, computer scientists, academics, students, and others in > the industry to request Gov. Nathan Deal veto this bill. Our letter is > particularly designed for out-of-state individuals who wish to help the > effort. > > We're not ready to share the letter publicly yet, so if you are > interested in signing on, please email us (stop-sb315 at eff.org) and we > will send you the full letter off-list. We are trying to finalize > signatures by end of business on Thursday, April 12, so please get back > to us ASAP. > > For more information about the bill: > https://www.eff.org/deeplinks/2018/03/georgia-passes-anti-infosec-legislation > > For the text of the bill: > http://www.legis.ga.gov/legislation/en-US/Display/20172018/SB/315 > > Thank you for your consideration, and please do not hesitate to email us > if you have further questions. > > Sincerely, > > Bennett ----- End forwarded message ----- From matt at netfire.net Thu Apr 12 16:34:31 2018 From: matt at netfire.net (Matt Harris) Date: Thu, 12 Apr 2018 11:34:31 -0500 Subject: IPv4 and IPv6 hijacking by AS 6 Message-ID: AS 6 is now announcing several IPv4 and IPv6 blocks of mine, and it looks like I'm not alone. Does anyone have any contacts there, or know what might be going on? The number of prefixes they're currently advertising is tremendous. The phone numbers associated with AS6's RIR whois data are non-functional. I've sent emails to their contacts listed in RIR whois (Mike Abbott and John Luke Mills), but with phone numbers being dead, I'm not optimistic. If anyone is there who has any control over AS 6 or knows whom I can reach out to, please let me know. Thanks, Matt From logan at hackers.mu Thu Apr 12 16:41:58 2018 From: logan at hackers.mu (Loganaden Velvindron) Date: Thu, 12 Apr 2018 20:41:58 +0400 Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: References: Message-ID: On Thu, Apr 12, 2018 at 8:34 PM, Matt Harris wrote: > AS 6 is now announcing several IPv4 and IPv6 blocks of mine, and it looks > like I'm not alone. Does anyone have any contacts there, or know what > might be going on? The number of prefixes they're currently advertising is > tremendous. The phone numbers associated with AS6's RIR whois data are > non-functional. I've sent emails to their contacts listed in RIR whois > (Mike Abbott and John Luke Mills), but with phone numbers being dead, I'm > not optimistic. > I think that it's an issue. Perhaps, also consider filing a request here: https://www.arin.net/public/whoisinaccuracy/index.xhtml > If anyone is there who has any control over AS 6 or knows whom I can reach > out to, please let me know. > > Thanks, > Matt From lists at as23738.net Thu Apr 12 17:05:36 2018 From: lists at as23738.net (lists at as23738.net) Date: Thu, 12 Apr 2018 10:05:36 -0700 Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: References: Message-ID: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> Have you tried their IRR entries? Bull appears to redirect to Atos now (site-wise). notify: ed.gienko at atos.net notify: charlie.molnar at atos.net changed: christophe.fraule at atos.net 20180117 #18:47:40Z On Thu, Apr 12, 2018, at 9:34 AM, Matt Harris wrote: > AS 6 is now announcing several IPv4 and IPv6 blocks of mine, and it looks > like I'm not alone. Does anyone have any contacts there, or know what > might be going on? The number of prefixes they're currently advertising is > tremendous. The phone numbers associated with AS6's RIR whois data are > non-functional. I've sent emails to their contacts listed in RIR whois > (Mike Abbott and John Luke Mills), but with phone numbers being dead, I'm > not optimistic. > > If anyone is there who has any control over AS 6 or knows whom I can reach > out to, please let me know. > > Thanks, > Matt From matt at netfire.net Thu Apr 12 18:51:28 2018 From: matt at netfire.net (Matt Harris) Date: Thu, 12 Apr 2018 13:51:28 -0500 Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> References: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> Message-ID: On Thu, Apr 12, 2018 at 12:05 PM, wrote: > Have you tried their IRR entries? Bull appears to redirect to Atos now > (site-wise). > > notify: ed.gienko at atos.net > notify: charlie.molnar at atos.net > changed: christophe.fraule at atos.net 20180117 #18:47:40Z > I'm now in touch with Christophe; it looks as though perhaps there's a separate, rogue AS 6 running around with a different set of peers/transits, as he was able to confirm that none of his gear is advertising these prefixes. Thanks, Matt From job at instituut.net Thu Apr 12 19:01:44 2018 From: job at instituut.net (Job Snijders) Date: Thu, 12 Apr 2018 19:01:44 +0000 Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: References: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> Message-ID: On Thu, 12 Apr 2018 at 11:52, Matt Harris wrote: > On Thu, Apr 12, 2018 at 12:05 PM, wrote: > > > Have you tried their IRR entries? Bull appears to redirect to Atos now > > (site-wise). > > > > notify: ed.gienko at atos.net > > notify: charlie.molnar at atos.net > > changed: christophe.fraule at atos.net 20180117 #18:47:40Z > > > > I'm now in touch with Christophe; it looks as though perhaps there's a > separate, rogue AS 6 running around with a different set of peers/transits, > as he was able to confirm that none of his gear is advertising these > prefixes. That is what I feared as well. It appears the single digit ASNs often fall victim of other people’s misconfigurations or malicious activities. Hard to separate the impersonator from the real autonomous system. Job From me at anuragbhatia.com Fri Apr 13 02:25:36 2018 From: me at anuragbhatia.com (Anurag Bhatia) Date: Fri, 13 Apr 2018 07:55:36 +0530 Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: References: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> Message-ID: Similar for AS2. A view from Oregon Route-views for AS2 related paths: * 43.227.224.0/24 208.51.134.254 0 0 3549 3356 6453 4755 133711 133711 133711 2 i * 103.197.104.1 0 134708 6453 4755 133711 133711 133711 2 i * 212.66.96.126 0 20912 174 6453 4755 133711 133711 133711 2 i * 217.192.89.50 0 3303 6453 4755 133711 133711 133711 2 i * 203.62.252.83 0 1221 4637 6453 4755 133711 133711 133711 2 i * 43.227.225.0/24 208.51.134.254 0 0 3549 3356 6453 4755 133711 133711 133711 2 i * 103.197.104.1 0 134708 6453 4755 133711 133711 133711 2 i * 212.66.96.126 0 20912 174 6453 4755 133711 133711 133711 2 i * 217.192.89.50 0 3303 6453 4755 133711 133711 133711 2 i * 203.62.252.83 0 1221 4637 6453 4755 133711 133711 133711 2 i * 91.143.144.0/20 208.51.134.254 0 0 3549 3356 12389 41837 41837 2 i * 212.66.96.126 0 20912 1267 12389 41837 41837 2 i * 37.139.139.0 0 57866 6762 12389 41837 41837 2 i * 195.208.112.161 0 3277 3267 12389 41837 41837 2 i * 93.104.209.174 0 58901 51167 3356 12389 41837 41837 2 i * 193.0.0.56 0 3333 1103 12389 41837 41837 2 i * 103.63.234.0/24 208.51.134.254 0 0 3549 3356 2914 132602 58715 55406 2 134403 i * 212.66.96.126 0 20912 174 132602 58715 55406 2 65501 134403 i * 134.222.87.1 650 0 286 6762 132602 58715 55406 2 134403 i * 194.85.40.15 0 0 3267 174 132602 58715 55406 2 65501 134403 i * 12.0.1.63 0 7018 2914 132602 58715 55406 2 134403 i * 37.139.139.0 0 57866 6762 132602 58715 55406 2 134403 i (and lot more!) On Fri, Apr 13, 2018 at 12:31 AM, Job Snijders wrote: > On Thu, 12 Apr 2018 at 11:52, Matt Harris wrote: > > > On Thu, Apr 12, 2018 at 12:05 PM, wrote: > > > > > Have you tried their IRR entries? Bull appears to redirect to Atos now > > > (site-wise). > > > > > > notify: ed.gienko at atos.net > > > notify: charlie.molnar at atos.net > > > changed: christophe.fraule at atos.net 20180117 #18:47:40Z > > > > > > > I'm now in touch with Christophe; it looks as though perhaps there's a > > separate, rogue AS 6 running around with a different set of > peers/transits, > > as he was able to confirm that none of his gear is advertising these > > prefixes. > > > > That is what I feared as well. It appears the single digit ASNs often fall > victim of other people’s misconfigurations or malicious activities. Hard to > separate the impersonator from the real autonomous system. > > Job > -- Anurag Bhatia anuragbhatia.com From bernat at luffy.cx Fri Apr 13 05:27:23 2018 From: bernat at luffy.cx (Vincent Bernat) Date: Fri, 13 Apr 2018 07:27:23 +0200 Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: (Matt Harris's message of "Thu, 12 Apr 2018 13:51:28 -0500") References: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> Message-ID: <87o9in8ymc.fsf@luffy.cx> ❦ 12 avril 2018 13:51 -0500, Matt Harris  : >> Have you tried their IRR entries? Bull appears to redirect to Atos now >> (site-wise). >> >> notify: ed.gienko at atos.net >> notify: charlie.molnar at atos.net >> changed: christophe.fraule at atos.net 20180117 #18:47:40Z >> > > I'm now in touch with Christophe; it looks as though perhaps there's a > separate, rogue AS 6 running around with a different set of peers/transits, > as he was able to confirm that none of his gear is advertising these > prefixes. Maybe AS6 is used internally by the next AS on the path? -- Choose variable names that won't be confused. - The Elements of Programming Style (Kernighan & Plauger) From bjorn at mork.no Fri Apr 13 08:13:47 2018 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Fri, 13 Apr 2018 10:13:47 +0200 Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: (Anurag Bhatia's message of "Fri, 13 Apr 2018 07:55:36 +0530") References: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> Message-ID: <878t9rjzgk.fsf@miraculix.mork.no> Anurag Bhatia writes: > Similar for AS2. I believe we've seen bogus low AS number announcements a few times before, and they've usually been caused by attemts to configure AS path prepending without understanding and/or reading the docs. Someone might have wrongly assumed that set as-path prepend 133711 133711 could be written shorter like set as-path prepend 133711 2 and there you go... Bjørn From theodore at ciscodude.net Fri Apr 13 15:32:04 2018 From: theodore at ciscodude.net (Theodore Baschak) Date: Fri, 13 Apr 2018 10:32:04 -0500 Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: <87o9in8ymc.fsf@luffy.cx> References: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> <87o9in8ymc.fsf@luffy.cx> Message-ID: > On Apr 13, 2018, at 12:27 AM, Vincent Bernat wrote: > > Maybe AS6 is used internally by the next AS on the path? I've definitely seen (and sadly, interacted with) operators that solved their "why doesn't non-meshed iBGP do what I'm expecting" problems by simply using different low-numbered ASNs internally (1,2,3... 19) instead of proper private ASNs. Theo From dhubbard at dino.hostasaurus.com Fri Apr 13 16:38:31 2018 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 13 Apr 2018 16:38:31 +0000 Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: <878t9rjzgk.fsf@miraculix.mork.no> References: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> <878t9rjzgk.fsf@miraculix.mork.no> Message-ID: <2C08EE2D-FF50-4D89-8A0A-EB234FDB373B@dino.hostasaurus.com> Unfortunately, that's how it's done in route policy on XR, so people bouncing between flavors can easily make that mistake. On 4/13/18, 4:15 AM, "NANOG on behalf of Bjørn Mork" wrote: Anurag Bhatia writes: > Similar for AS2. I believe we've seen bogus low AS number announcements a few times before, and they've usually been caused by attemts to configure AS path prepending without understanding and/or reading the docs. Someone might have wrongly assumed that set as-path prepend 133711 133711 could be written shorter like set as-path prepend 133711 2 and there you go... Bjørn From cscora at apnic.net Fri Apr 13 18:03:01 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 Apr 2018 04:03:01 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180413180301.D6B4A597@thyme.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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. 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 14 Apr, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 694221 Prefixes after maximum aggregation (per Origin AS): 268062 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 333993 Total ASes present in the Internet Routing Table: 60376 Prefixes per ASN: 11.50 Origin-only ASes present in the Internet Routing Table: 52151 Origin ASes announcing only one prefix: 22835 Transit ASes present in the Internet Routing Table: 8225 Transit-only ASes present in the Internet Routing Table: 268 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 46 Number of instances of unregistered ASNs: 46 Number of 32-bit ASNs allocated by the RIRs: 22190 Number of 32-bit ASNs visible in the Routing Table: 17842 Prefixes from 32-bit ASNs in the Routing Table: 74177 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 367 Number of addresses announced to Internet: 2862806274 Equivalent to 170 /8s, 162 /16s and 245 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 231118 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 190229 Total APNIC prefixes after maximum aggregation: 53961 APNIC Deaggregation factor: 3.53 Prefixes being announced from the APNIC address blocks: 189163 Unique aggregates announced from the APNIC address blocks: 77142 APNIC Region origin ASes present in the Internet Routing Table: 8713 APNIC Prefixes per ASN: 21.71 APNIC Region origin ASes announcing only one prefix: 2428 APNIC Region transit ASes present in the Internet Routing Table: 1303 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3675 Number of APNIC addresses announced to Internet: 767084034 Equivalent to 45 /8s, 184 /16s and 198 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 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: 206423 Total ARIN prefixes after maximum aggregation: 98887 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 206893 Unique aggregates announced from the ARIN address blocks: 97703 ARIN Region origin ASes present in the Internet Routing Table: 18135 ARIN Prefixes per ASN: 11.41 ARIN Region origin ASes announcing only one prefix: 6704 ARIN Region transit ASes present in the Internet Routing Table: 1794 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2335 Number of ARIN addresses announced to Internet: 1109026464 Equivalent to 66 /8s, 26 /16s and 102 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 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: 189340 Total RIPE prefixes after maximum aggregation: 91435 RIPE Deaggregation factor: 2.07 Prefixes being announced from the RIPE address blocks: 185690 Unique aggregates announced from the RIPE address blocks: 110508 RIPE Region origin ASes present in the Internet Routing Table: 25094 RIPE Prefixes per ASN: 7.40 RIPE Region origin ASes announcing only one prefix: 11401 RIPE Region transit ASes present in the Internet Routing Table: 3486 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6884 Number of RIPE addresses announced to Internet: 716174976 Equivalent to 42 /8s, 175 /16s and 246 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 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: 89451 Total LACNIC prefixes after maximum aggregation: 19714 LACNIC Deaggregation factor: 4.54 Prefixes being announced from the LACNIC address blocks: 90842 Unique aggregates announced from the LACNIC address blocks: 40741 LACNIC Region origin ASes present in the Internet Routing Table: 7008 LACNIC Prefixes per ASN: 12.96 LACNIC Region origin ASes announcing only one prefix: 1926 LACNIC Region transit ASes present in the Internet Routing Table: 1311 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4541 Number of LACNIC addresses announced to Internet: 172652768 Equivalent to 10 /8s, 74 /16s and 120 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 18730 Total AfriNIC prefixes after maximum aggregation: 4023 AfriNIC Deaggregation factor: 4.66 Prefixes being announced from the AfriNIC address blocks: 21266 Unique aggregates announced from the AfriNIC address blocks: 7607 AfriNIC Region origin ASes present in the Internet Routing Table: 1132 AfriNIC Prefixes per ASN: 18.79 AfriNIC Region origin ASes announcing only one prefix: 375 AfriNIC Region transit ASes present in the Internet Routing Table: 227 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 407 Number of AfriNIC addresses announced to Internet: 97447936 Equivalent to 5 /8s, 206 /16s and 240 /24s 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 4538 5407 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4378 415 431 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2854 11131 783 KIXS-AS-KR Korea Telecom, KR 9829 2815 1499 544 BSNL-NIB National Internet Backbone, IN 7552 2725 1155 69 VIETEL-AS-AP Viettel Group, VN 9394 2635 4923 29 CTTNET China TieTong Telecommunications 45899 2586 1574 161 VNPT-AS-VN VNPT Corp, VN 17974 2330 928 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2171 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2091 417 215 TATACOMM-AS TATA Communications formerl 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 6327 3365 1323 85 SHAW - Shaw Communications Inc., CA 22773 3287 2988 150 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2168 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2093 2490 448 CHARTER-NET-HKY-NC - Charter Communicat 16509 2054 4413 636 AMAZON-02 - Amazon.com, Inc., US 30036 1952 338 186 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 209 1922 5070 606 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 11492 1800 227 546 CABLEONE - CABLE ONE, INC., US 16625 1750 856 1248 AKAMAI-AS - Akamai Technologies, Inc., 7018 1707 20205 1255 ATT-INTERNET4 - AT&T Services, Inc., US 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 12479 4036 1512 488 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 20940 2695 742 1980 AKAMAI-ASN1, US 8551 2126 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2029 1859 706 ROSTELECOM-AS, RU 34984 1977 333 490 TELLCOM-AS, TR 9121 1968 1692 19 TTNET, TR 13188 1608 100 47 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1226 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 8151 4345 3387 574 Uninet S.A. de C.V., MX 10620 3570 539 270 Telmex Colombia S.A., CO 11830 2641 369 85 Instituto Costarricense de Electricidad 6503 1626 437 53 Axtel, S.A.B. de C.V., MX 7303 1510 1024 192 Telecom Argentina S.A., AR 28573 1037 2254 176 CLARO S.A., BR 3816 1005 504 121 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 996 377 31 Telefonica del Peru S.A.A., PE 11172 928 126 85 Alestra, S. de R.L. de C.V., MX 18881 908 1074 29 TELEF�NICA BRASIL S.A, BR 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 1144 396 44 LINKdotNET-AS, EG 37611 824 107 9 Afrihost, ZA 36903 741 372 137 MT-MPLS, MA 36992 701 1412 41 ETISALAT-MISR, EG 8452 643 1730 18 TE-AS TE-AS, EG 24835 638 850 15 RAYA-AS, EG 29571 472 68 12 ORANGE-COTE-IVOIRE, CI 37492 451 376 81 ORANGE-, TN 15399 362 35 7 WANANCHI-, KE 37342 361 32 1 MOVITEL, MZ 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 4538 5407 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4378 415 431 TPG-INTERNET-AP TPG Telecom Limited, AU 8151 4345 3387 574 Uninet S.A. de C.V., MX 12479 4036 1512 488 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3570 539 270 Telmex Colombia S.A., CO 6327 3365 1323 85 SHAW - Shaw Communications Inc., CA 22773 3287 2988 150 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2854 11131 783 KIXS-AS-KR Korea Telecom, KR 9829 2815 1499 544 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4378 3947 TPG-INTERNET-AP TPG Telecom Limited, AU 8151 4345 3771 Uninet S.A. de C.V., MX 39891 3778 3758 ALJAWWALSTC-AS, SA 12479 4036 3548 UNI2-AS, ES 10620 3570 3300 Telmex Colombia S.A., CO 6327 3365 3280 SHAW - Shaw Communications Inc., CA 22773 3287 3137 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2725 2656 VIETEL-AS-AP Viettel Group, VN 9394 2635 2606 CTTNET China TieTong Telecommunications Corpora 11830 2641 2556 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.78.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.80.0/22 39407 CHITATELECOM-AS, RU 64111 UNALLOCATED 98.159.5.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.7.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 100.127.16.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM 100.127.18.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.48.0/24 327815 XNET, NA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 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:15 /9:12 /10:37 /11:100 /12:288 /13:564 /14:1097 /15:1902 /16:13397 /17:7836 /18:13669 /19:25227 /20:39361 /21:45193 /22:86301 /23:70047 /24:386928 /25:849 /26:607 /27:662 /28:35 /29:20 /30:17 /31:4 /32:53 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3153 3365 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 12479 2772 4036 UNI2-AS, ES 22773 2540 3287 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2061 2168 MEGAPATH5-US - MegaPath Corporation, US 11830 1989 2641 Instituto Costarricense de Electricidad y Telec 30036 1703 1952 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1599 3570 Telmex Colombia S.A., CO 8551 1589 2126 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 1558 1800 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1592 2:825 4:19 5:2869 6:59 7:1 8:1122 12:1876 13:183 14:1746 15:30 16:3 17:200 18:68 20:47 21:4 23:2549 24:2153 25:2 27:2269 31:1971 32:87 35:27 36:505 37:2757 38:1449 39:253 40:118 41:3104 42:606 43:1938 44:104 45:4100 46:3070 47:204 49:1297 50:1048 51:304 52:993 54:372 55:5 56:12 57:42 58:1532 59:1011 60:430 61:2139 62:1815 63:1803 64:4758 65:2221 66:4587 67:2351 68:1146 69:3192 70:1149 71:560 72:2093 74:2718 75:411 76:429 77:1549 78:1699 79:1929 80:1478 81:1429 82:1080 83:770 84:1040 85:2050 86:580 87:1318 88:933 89:2309 90:208 91:6310 92:1171 93:2390 94:2370 95:2781 96:659 97:357 98:943 99:133 100:81 101:1259 102:40 103:17406 104:3250 105:228 106:654 107:1763 108:711 109:2699 110:1597 111:1780 112:1267 113:1337 114:1121 115:1637 116:1641 117:1705 118:2158 119:1664 120:965 121:1057 122:2451 123:1810 124:1450 125:1891 128:979 129:638 130:449 131:1574 132:677 133:196 134:1015 135:226 136:455 137:498 138:1908 139:593 140:424 141:688 142:782 143:975 144:810 145:459 146:1178 147:766 148:1560 149:701 150:720 151:1048 152:762 153:312 154:1029 155:754 156:870 157:784 158:629 159:1667 160:923 161:747 162:2579 163:531 164:1057 165:1412 166:425 167:1403 168:3051 169:806 170:3687 171:428 172:1040 173:1946 174:887 175:750 176:1851 177:3975 178:2418 179:1218 180:2247 181:2218 182:2386 183:1138 184:919 185:13255 186:3581 187:2381 188:2764 189:2026 190:8121 191:1438 192:9829 193:5888 194:4795 195:3952 196:2505 197:1424 198:5538 199:5864 200:7392 201:5013 202:10371 203:10177 204:4520 205:2878 206:3075 207:3199 208:3979 209:3937 210:4035 211:2111 212:3017 213:2725 214:950 215:60 216:5841 217:2130 218:908 219:619 220:1748 221:995 222:1039 223:1244 End of report From cash at udel.edu Fri Apr 13 18:17:47 2018 From: cash at udel.edu (Jason S. Cash) Date: Fri, 13 Apr 2018 14:17:47 -0400 (EDT) Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: <878t9rjzgk.fsf@miraculix.mork.no> References: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> <878t9rjzgk.fsf@miraculix.mork.no> Message-ID: On Fri, 13 Apr 2018, Bjørn Mork wrote: > Date: Fri, 13 Apr 2018 10:13:47 +0200 > From: Bjørn Mork > To: Anurag Bhatia > Cc: North American Network Operators' Group > Subject: Re: IPv4 and IPv6 hijacking by AS 6 > > Anurag Bhatia writes: > >> Similar for AS2. > > I believe we've seen bogus low AS number announcements a few times > before, and they've usually been caused by attemts to configure > AS path prepending without understanding and/or reading the docs. > > Someone might have wrongly assumed that > > set as-path prepend 133711 133711 > > could be written shorter like > > set as-path prepend 133711 2 > > and there you go... Yes, ASN2 sees about 1-4 configuration related "rogue" announcements per month. What is going on right now does not appear to be a small misconfiguration. The only route we (University of Delaware) are announcing w/ ASN2 is 128.4.0.0/16. Jason Jason Cash Deputy CIO University of Delaware cash at udel.edu 302-831-0461 From job at ntt.net Fri Apr 13 19:22:59 2018 From: job at ntt.net (Job Snijders) Date: Fri, 13 Apr 2018 19:22:59 +0000 Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: References: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> <878t9rjzgk.fsf@miraculix.mork.no> Message-ID: <20180413192259.GA36148@vurt.meerval.net> Dear Jason, On Fri, Apr 13, 2018 at 02:17:47PM -0400, Jason S. Cash wrote: > Yes, ASN2 sees about 1-4 configuration related "rogue" announcements > per month. What is going on right now does not appear to be a small > misconfiguration. > > The only route we (University of Delaware) are announcing w/ ASN2 is > 128.4.0.0/16. Is this actually causing your organisation issues in terms of reachability, or additional workload for staff, or is it just a strange artifact you've learned to live with? Kind regards, Job From randy at psg.com Fri Apr 13 21:35:07 2018 From: randy at psg.com (Randy Bush) Date: Fri, 13 Apr 2018 14:35:07 -0700 Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: <878t9rjzgk.fsf@miraculix.mork.no> References: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> <878t9rjzgk.fsf@miraculix.mork.no> Message-ID: > I believe we've seen bogus low AS number announcements a few times > before, and they've usually been caused by attemts to configure > AS path prepending without understanding and/or reading the docs. > > Someone might have wrongly assumed that > > set as-path prepend 133711 133711 > > could be written shorter like > > set as-path prepend 133711 2 > > and there you go... for someone else's prefix? From morrowc.lists at gmail.com Sat Apr 14 00:13:40 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 14 Apr 2018 01:13:40 +0100 Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: References: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> <878t9rjzgk.fsf@miraculix.mork.no> Message-ID: On Fri, Apr 13, 2018 at 10:35 PM, Randy Bush wrote: > > I believe we've seen bogus low AS number announcements a few times > > before, and they've usually been caused by attemts to configure > > AS path prepending without understanding and/or reading the docs. > > > > Someone might have wrongly assumed that > > > > set as-path prepend 133711 133711 > > > > could be written shorter like > > > > set as-path prepend 133711 2 > > > > and there you go... > > for someone else's prefix? > Perhaps their policy is something like: "prepend all of transit-provider-1 prefixes by 2, their links are crappy today" followed by output policy: "permit all of my prefixes (matched by as-path-regex) and my customer prefixes (matched by community)" there's probably a bunch of ways this can go sideways, that's just one simple (and seen before) example. From bjorn at mork.no Sat Apr 14 11:26:20 2018 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Sat, 14 Apr 2018 13:26:20 +0200 Subject: IPv4 and IPv6 hijacking by AS 6 In-Reply-To: (Randy Bush's message of "Fri, 13 Apr 2018 14:35:07 -0700") References: <1523552736.3664866.1335912928.793E9F31@webmail.messagingengine.com> <878t9rjzgk.fsf@miraculix.mork.no> Message-ID: <87vacughb7.fsf@miraculix.mork.no> Randy Bush writes: >> I believe we've seen bogus low AS number announcements a few times >> before, and they've usually been caused by attemts to configure >> AS path prepending without understanding and/or reading the docs. >> >> Someone might have wrongly assumed that >> >> set as-path prepend 133711 133711 >> >> could be written shorter like >> >> set as-path prepend 133711 2 >> >> and there you go... > > for someone else's prefix? No, of course not. At least I have no reason to beliece so. I briefly looked at a couple of the examples Anurag posted. And for those, the next AS number in the path seemed consistent with the prefix owner: * 43.227.224.0/24 208.51.134.254 0 0 3549 3356 6453 4755 133711 133711 133711 2 i * 91.143.144.0/20 208.51.134.254 0 0 3549 3356 12389 41837 41837 2 i bjorn at miraculix:~$ whois 43.227.224.0/24 |grep origin origin: AS133711 origin: AS58965 bjorn at miraculix:~$ whois 91.143.144.0/20 |grep origin origin: AS41837 Bjørn From Brian at ampr.org Sat Apr 14 14:06:49 2018 From: Brian at ampr.org (Brian Kantor) Date: Sat, 14 Apr 2018 07:06:49 -0700 Subject: Is WHOIS going to go away? Message-ID: <20180414140649.GA85820@meow.BKantor.net> There is concern that the WHOIS database service will be in violation of the new European GDPR which takes effect May 25th, and may have to shut down. http://www.theregister.co.uk/2018/04/14/whois_icann_gdpr_europe/ https://www.icann.org/en/system/files/correspondence/jelinek-to-marby-11apr18-en.pdf - Brian From rubensk at gmail.com Sat Apr 14 14:13:33 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 14 Apr 2018 11:13:33 -0300 Subject: Is WHOIS going to go away? In-Reply-To: <20180414140649.GA85820@meow.BKantor.net> References: <20180414140649.GA85820@meow.BKantor.net> Message-ID: On Sat, Apr 14, 2018 at 11:06 AM, Brian Kantor wrote: > There is concern that the WHOIS database service will be in violation > of the new European GDPR which takes effect May 25th, and may have > to shut down. > > http://www.theregister.co.uk/2018/04/14/whois_icann_gdpr_europe/ > > https://www.icann.org/en/system/files/correspondence/ > jelinek-to-marby-11apr18-en.pdf > > - Brian > > Some more detailed info available at http://domainincite.com/22854-panic-stations-as-europe-plays-hardball-on-whois-privacy . TL;DR: WHOIS will have less personally identifiable information, it won't be shutdown. Rubens From fhr at fhrnet.eu Sat Apr 14 14:21:59 2018 From: fhr at fhrnet.eu (Filip Hruska) Date: Sat, 14 Apr 2018 14:21:59 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <20180414140649.GA85820@meow.BKantor.net> References: <20180414140649.GA85820@meow.BKantor.net> Message-ID: <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> EURID (.eu) WHOIS already works on a basis that no information about the registrant is available via standard WHOIS. In order to get any useful information you have to go to https://whois.eurid.eu and make a request there. Seems like a reasonable solution. -- Filip Hruska Linux System Administrator On 04/14/2018 04:06 PM, Brian Kantor wrote: > There is concern that the WHOIS database service will be in violation > of the new European GDPR which takes effect May 25th, and may have > to shut down. > > http://www.theregister.co.uk/2018/04/14/whois_icann_gdpr_europe/ > > https://www.icann.org/en/system/files/correspondence/jelinek-to-marby-11apr18-en.pdf > > - Brian > From rubensk at gmail.com Sat Apr 14 14:30:42 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 14 Apr 2018 11:30:42 -0300 Subject: Is WHOIS going to go away? In-Reply-To: <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> Message-ID: On Sat, Apr 14, 2018 at 11:21 AM, Filip Hruska wrote: > EURID (.eu) WHOIS already works on a basis that no information about the > registrant is available via standard WHOIS. > In order to get any useful information you have to go to > https://whois.eurid.eu and make a request there. > > Seems like a reasonable solution. GDPR and other privacy regimes apply to both port-43 and WebWHOIS. Rubens From daknob.mac at gmail.com Sat Apr 14 14:45:26 2018 From: daknob.mac at gmail.com (DaKnOb) Date: Sat, 14 Apr 2018 17:45:26 +0300 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> Message-ID: Currently .eu and .gr domains do not have any whois records. .eu makes them available online, but .gr is under a much stricter privacy law in Greece, and makes no whois records available to anyone. This has been so for years, and I can tell you of a few things / observations about this, since I’ve had many domains with both TLDs. First of all, anything that looks up for an e-mail in the whois records, just doesn’t work. That means that if you want a certificate for this domain, and you follow the traditional, manual, way, you either need a mail serve running there so hostmaster / postmaster / webmaster work, or the only way then is to add files. And that if you have something running on the base domain and you don’t just use this for subdomains. Second, you never get any spam. If they can’t find your e-mail address, they can’t send you spam. Third, it blocks legitimate uses of whois by people who need to know the identity of domain operators, such as abuse tracking projects, scam / phish projects, law enforcement, etc. Finally, there are two ways to contact a domain owner. The first one is to look for a contact page in the website, if there is one. The second is to contact their registrar (the details of the domain registrar are available in the whois), and have them reach out to the owner on your behalf. In my opinion, not all the information in the whois records should be there, from an individual point of view, but the all or nothing situation right now isn’t great. If I had to choose however, I would choose the no whois for now, over the other, more leaky one. I personally believe a lot of people would agree, given the fact that there’s an entire market, and a plethora of domains using Whois Guard or in general whois masking tools, for free, or for a fee. As far as abuse tracking goes, having whois available can help correlate websites, but only if the domain registrar allows only verified data to be added, whois masking is not used, or malicious actors only use the same data over and over. That last part may happen because the registrar does some verification, so it limits their choice of domain registrars. P.S.: About the first thing, some CAs may e-mail the domain registrar’s e-mail (which is usually admin / support / IT) for domain verification, which I’m not sure if fine.. :-) > On 14 Apr 2018, at 17:30, Rubens Kuhl wrote: > > On Sat, Apr 14, 2018 at 11:21 AM, Filip Hruska wrote: > >> EURID (.eu) WHOIS already works on a basis that no information about the >> registrant is available via standard WHOIS. >> In order to get any useful information you have to go to >> https://whois.eurid.eu and make a request there. >> >> Seems like a reasonable solution. > > > GDPR and other privacy regimes apply to both port-43 and WebWHOIS. > > Rubens From rsk at gsp.org Sat Apr 14 17:14:10 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 14 Apr 2018 13:14:10 -0400 Subject: Is WHOIS going to go away? In-Reply-To: <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> Message-ID: <20180414171410.GA20737@gsp.org> On Sat, Apr 14, 2018 at 02:21:59PM +0000, Filip Hruska wrote: > EURID (.eu) WHOIS already works on a basis that no information about the > registrant is available via standard WHOIS. > In order to get any useful information you have to go to > https://whois.eurid.eu and make a request there. > > Seems like a reasonable solution. It's not. All WHOIS information should be completely available with no limits, no restrictions, in bulk form to everyone -- so that everyone running every operation is identifiable to their peers and thus accountable to their peers. I understand that some people don't want to be exposed to that, and that's fine: but then they shouldn't be running an Internet-connected operation. The only people served by restriction on WHOIS availability are abusers and attackers, and the entities (e.g., registrars) who profit from them. ---rsk From matt at netfire.net Sat Apr 14 17:19:46 2018 From: matt at netfire.net (Matt Harris) Date: Sat, 14 Apr 2018 12:19:46 -0500 Subject: Is WHOIS going to go away? In-Reply-To: <20180414171410.GA20737@gsp.org> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <20180414171410.GA20737@gsp.org> Message-ID: On Sat, Apr 14, 2018 at 12:14 PM, Rich Kulawiec wrote: > > The only people served by restriction on WHOIS availability are abusers > and attackers, and the entities (e.g., registrars) who profit from them. > Not that whois data for domain names has been particularly useful for the past decade anyhow since most TLDs and registrars either provide for free, or sell as an addon, "private" registration via some "proxy corporation" or whatever. Domain name whois for most TLDs has not been the sort of accountability measure that ICANN seems to think it is for a very long time, at least in practice. I'd be much more concerned about RIPE's whois data for AS and IP address maintainers. From daknob.mac at gmail.com Sat Apr 14 17:24:05 2018 From: daknob.mac at gmail.com (DaKnOb) Date: Sat, 14 Apr 2018 20:24:05 +0300 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <20180414171410.GA20737@gsp.org> Message-ID: <08EF2654-C175-4C1C-BDE1-2C8A0D4A5D93@gmail.com> As far as IP Addresses go (and domains too), currently GDPR recognizes the rights of individuals, not companies, which means that a company can be in the whois query, since it does not have the right to privacy. My understanding is that this will only affect natural persons. > On 14 Apr 2018, at 20:19, Matt Harris wrote: > >> On Sat, Apr 14, 2018 at 12:14 PM, Rich Kulawiec wrote: >> >> The only people served by restriction on WHOIS availability are abusers >> and attackers, and the entities (e.g., registrars) who profit from them. >> > > Not that whois data for domain names has been particularly useful for the > past decade anyhow since most TLDs and registrars either provide for free, > or sell as an addon, "private" registration via some "proxy corporation" or > whatever. Domain name whois for most TLDs has not been the sort of > accountability measure that ICANN seems to think it is for a very long > time, at least in practice. > > I'd be much more concerned about RIPE's whois data for AS and IP address From fw at deneb.enyo.de Sat Apr 14 17:29:38 2018 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 14 Apr 2018 19:29:38 +0200 Subject: Is WHOIS going to go away? In-Reply-To: <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> (Filip Hruska's message of "Sat, 14 Apr 2018 14:21:59 +0000") References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> Message-ID: <87sh7xr919.fsf@mid.deneb.enyo.de> * Filip Hruska: > EURID (.eu) WHOIS already works on a basis that no information about the > registrant is available via standard WHOIS. > In order to get any useful information you have to go to > https://whois.eurid.eu and make a request there. > > Seems like a reasonable solution. Why? How does the protocol matter? Either you may publish individual personal information for use by the general public, or you may not. Adding a 4 to the port number doesn't change that. From aaron at heyaaron.com Sat Apr 14 17:29:35 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Sat, 14 Apr 2018 17:29:35 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <20180414171410.GA20737@gsp.org> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <20180414171410.GA20737@gsp.org> Message-ID: If you register a corp out of Nevada, the only person who gets to know the names of the owners is the company lawyer unless someone shows up with a warrant. It costs around $1,200 if I remember correctly. So I can spin up a legit looking company and put that info into whois and you essentially end up with useless info unless you can convince a court to issue a warrant. So why are you proposing that I can't run my *personal* "I strongly believe in {insert emotionally-charged issue} site" without letting psychos know exactly where I live? -A On Sat, Apr 14, 2018 at 10:16 AM Rich Kulawiec wrote: > On Sat, Apr 14, 2018 at 02:21:59PM +0000, Filip Hruska wrote: > > EURID (.eu) WHOIS already works on a basis that no information about the > > registrant is available via standard WHOIS. > > In order to get any useful information you have to go to > > https://whois.eurid.eu and make a request there. > > > > Seems like a reasonable solution. > > It's not. All WHOIS information should be completely available > with no limits, no restrictions, in bulk form to everyone -- so that > everyone running every operation is identifiable to their peers and thus > accountable to their peers. I understand that some people don't want to > be exposed to that, and that's fine: but then they shouldn't be running > an Internet-connected operation. > > The only people served by restriction on WHOIS availability are abusers > and attackers, and the entities (e.g., registrars) who profit from them. > > ---rsk > From rubensk at gmail.com Sat Apr 14 17:38:58 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 14 Apr 2018 14:38:58 -0300 Subject: Is WHOIS going to go away? In-Reply-To: <08EF2654-C175-4C1C-BDE1-2C8A0D4A5D93@gmail.com> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <20180414171410.GA20737@gsp.org> <08EF2654-C175-4C1C-BDE1-2C8A0D4A5D93@gmail.com> Message-ID: On Sat, Apr 14, 2018 at 2:24 PM, DaKnOb wrote: > As far as IP Addresses go (and domains too), currently GDPR recognizes the > rights of individuals, not companies, which means that a company can be in > the whois query, since it does not have the right to privacy. > > My understanding is that this will only affect natural persons. > > The domain contacts of a domain owned by a legal entity are natural persons, and are also protected by GDPR. So unless a domain contact is something generic like "Technical Contact - techpoc at example.com" or similar role accounts, that contact data is also considered PII. Rubens From list at satchell.net Sat Apr 14 18:19:38 2018 From: list at satchell.net (Stephen Satchell) Date: Sat, 14 Apr 2018 11:19:38 -0700 Subject: Is WHOIS going to go away? In-Reply-To: <08EF2654-C175-4C1C-BDE1-2C8A0D4A5D93@gmail.com> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <20180414171410.GA20737@gsp.org> <08EF2654-C175-4C1C-BDE1-2C8A0D4A5D93@gmail.com> Message-ID: On 04/14/2018 10:24 AM, DaKnOb wrote: > As far as IP Addresses go (and domains too), currently GDPR recognizes the rights of individuals, not companies, which means that a company can be in the whois query, since it does not have the right to privacy. > > My understanding is that this will only affect natural persons. How does this affect a SWIP of a range of IP addresses where a natural person is the one who is the target of the sub-assignment? Does the GDPR restrict the unlimited publication of abuse@ addresses associated with the IP range, whether for natural person or legal person? From fhr at fhrnet.eu Sat Apr 14 20:20:06 2018 From: fhr at fhrnet.eu (Filip Hruska) Date: Sat, 14 Apr 2018 20:20:06 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <87sh7xr919.fsf@mid.deneb.enyo.de> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> Message-ID: <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> On 04/14/2018 07:29 PM, Florian Weimer wrote: > * Filip Hruska: > >> EURID (.eu) WHOIS already works on a basis that no information about the >> registrant is available via standard WHOIS. >> In order to get any useful information you have to go to >> https://whois.eurid.eu and make a request there. >> >> Seems like a reasonable solution. > Why? How does the protocol matter? > > Either you may publish individual personal information for use by the > general public, or you may not. Adding a 4 to the port number doesn't > change that. > The EURID webwhois cannot be scraped, there are anti-bot measures in place (captcha, throttling, all information displayed in images). Scraping WHOIS systems for thousands domains at once using the WHOIS protocol is easy though. There are "WHOIS History" sites which scrape all domains and then publish the data along with the date of retrieval. GDPR contains this in relation to the right to erasure: 1. Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, *the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure* by such controllers of any links to, or*copy or replication of, those personal data*. Controller is the TLD operator in this case, other controllers would be WHOIS scrapers. The problem here is the definition of "reasonable steps". Would doing nothing be reasonable? Or would the TLD operator need to somehow track all those scrapers and contact them? IANAL, but I see a problem here. -- Filip Hruska Linux System Administrator From fhr at fhrnet.eu Sat Apr 14 20:26:00 2018 From: fhr at fhrnet.eu (Filip Hruska) Date: Sat, 14 Apr 2018 20:26:00 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <08EF2654-C175-4C1C-BDE1-2C8A0D4A5D93@gmail.com> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <20180414171410.GA20737@gsp.org> <08EF2654-C175-4C1C-BDE1-2C8A0D4A5D93@gmail.com> Message-ID: <01020162c5d60686-14cea161-d0bf-462a-af6b-1de0634d7fc9-000000@eu-west-1.amazonses.com> On 04/14/2018 07:24 PM, DaKnOb wrote: > As far as IP Addresses go (and domains too), currently GDPR recognizes the rights of individuals, not companies, which means that a company can be in the whois query, since it does not have the right to privacy. > > My understanding is that this will only affect natural persons. > >> On 14 Apr 2018, at 20:19, Matt Harris wrote: >> >>> On Sat, Apr 14, 2018 at 12:14 PM, Rich Kulawiec wrote: >>> >>> The only people served by restriction on WHOIS availability are abusers >>> and attackers, and the entities (e.g., registrars) who profit from them. >>> >> Not that whois data for domain names has been particularly useful for the >> past decade anyhow since most TLDs and registrars either provide for free, >> or sell as an addon, "private" registration via some "proxy corporation" or >> whatever. Domain name whois for most TLDs has not been the sort of >> accountability measure that ICANN seems to think it is for a very long >> time, at least in practice. >> >> I'd be much more concerned about RIPE's whois data for AS and IP address An individual can also own an ASN and IP space. You don't have to be a company. -- Filip Hruska Linux System Administrator From bzs at theworld.com Sat Apr 14 21:46:30 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Sat, 14 Apr 2018 17:46:30 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <20180414171410.GA20737@gsp.org> <08EF2654-C175-4C1C-BDE1-2C8A0D4A5D93@gmail.com> Message-ID: <23250.30390.102695.595497@gargle.gargle.HOWL> GDPR only has jurisdiction over individuals who are citizens of countries which are members of the EU. About 27 countries out of almost 200 in this world. And companies which manage that data and are also within the EU's jurisdiction. But that jurisdiction arises from an individual's EU nation citizenship. So why not just have a checkmark at domain registration which asks whether you believe yourself to be within the EU's jurisdiction and, if so, no WHOIS publication for you, or very limited. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From list at satchell.net Sat Apr 14 21:53:49 2018 From: list at satchell.net (Stephen Satchell) Date: Sat, 14 Apr 2018 14:53:49 -0700 Subject: Is WHOIS going to go away? In-Reply-To: <23250.30390.102695.595497@gargle.gargle.HOWL> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <20180414171410.GA20737@gsp.org> <08EF2654-C175-4C1C-BDE1-2C8A0D4A5D93@gmail.com> <23250.30390.102695.595497@gargle.gargle.HOWL> Message-ID: <1bff36bb-d7a4-e66c-4c8a-348ff77b2239@satchell.net> On 04/14/2018 02:46 PM, bzs at theworld.com wrote: > So why not just have a checkmark at domain registration which asks > whether you believe yourself to be within the EU's jurisdiction and, > if so, no WHOIS publication for you, or very limited. FWIW, I've been reading quite a bit of (unverified) information about this subject. If my impressions mean anything, that field would need to say "I am not in EU's jurisdiction", and the default would be *un*checked. From rubensk at gmail.com Sat Apr 14 22:00:54 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 14 Apr 2018 19:00:54 -0300 Subject: Is WHOIS going to go away? In-Reply-To: <23250.30390.102695.595497@gargle.gargle.HOWL> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <20180414171410.GA20737@gsp.org> <08EF2654-C175-4C1C-BDE1-2C8A0D4A5D93@gmail.com> <23250.30390.102695.595497@gargle.gargle.HOWL> Message-ID: On Sat, Apr 14, 2018 at 6:46 PM, wrote: > > GDPR only has jurisdiction over individuals who are citizens of > countries which are members of the EU. About 27 countries out of > almost 200 in this world. And companies which manage that data and are > also within the EU's jurisdiction. > > Try finding a company in this area that does not have a subsidiary in the EU, acquired an EU company, is based in the EU or has EU resellers. > But that jurisdiction arises from an individual's EU nation > citizenship. > > So why not just have a checkmark at domain registration which asks > whether you believe yourself to be within the EU's jurisdiction and, > if so, no WHOIS publication for you, or very limited. > For the companies that are subject to GDPR, they have to do this for every natural person, not only the EU ones. So this checkmark could in fact be "The registrant is a legal person, not a natural person". Rubens From bzs at theworld.com Sat Apr 14 22:00:48 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Sat, 14 Apr 2018 18:00:48 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <20180414171410.GA20737@gsp.org> Message-ID: <23250.31248.362240.808600@gargle.gargle.HOWL> On April 14, 2018 at 17:29 nanog at nanog.org (Aaron C. de Bruyn via NANOG) wrote: > So why are you proposing that I can't run my *personal* "I strongly > believe in {insert emotionally-charged issue} site" without letting psychos > know exactly where I live? I wasn't the one proposing but GDPR basically prohibits your information from being exposed via WHOIS even if you would like it to be exposed. It's not difficult to hide your info, most registrars provide a free or low cost privacy option so any inquiry just responds with information about the registrar or some proxy service. Or you can contract with your own proxy service. THAT SAID, most countries require you to provide accurate and up to date contact information if you are doing business with the general public. Thus this whole issue is really just a product of the trend towards personal, non-business (vanity, etc) web sites. Which itself is the result of inexpensive and ubiquitous always-on internet connections and the rise of hosting services. And points out something of a contradiction: Prohibiting or severely restricting the publication of contact information (WHOIS) while simultaneously requiring contact information is made available (to the general public.) Does anyone believe privacy etc will be enhanced by forbidding your finding out who owns this domain you were directed towards by a search engine? Granted you may not get a satisfactory answer but then maybe you choose not to do business with them, ok, your choice. But what if the response is "SORRY BLOCKED BY GDPR"? Do you do business with them? Or not? -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Sat Apr 14 22:26:47 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Sat, 14 Apr 2018 18:26:47 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <20180414171410.GA20737@gsp.org> <08EF2654-C175-4C1C-BDE1-2C8A0D4A5D93@gmail.com> <23250.30390.102695.595497@gargle.gargle.HOWL> Message-ID: <23250.32807.191103.878693@gargle.gargle.HOWL> On April 14, 2018 at 19:00 rubensk at gmail.com (Rubens Kuhl) wrote: > > > On Sat, Apr 14, 2018 at 6:46 PM, wrote: > > > GDPR only has jurisdiction over individuals who are citizens of > countries which are members of the EU. About 27 countries out of > almost 200 in this world. And companies which manage that data and are > also within the EU's jurisdiction. > > > > Try finding a company in this area that does not have a subsidiary in the EU, > acquired an EU company, is based in the EU or has EU resellers.  What area? Do you mean geographical or trade? My company doesn't fit that description. Non-ccTLD registrars and registries (and RIRs in this case) have a certain contractual relationship with ICANN. But ccTLDs seem a pretty good counter-example, I doubt CNNIC accepts EU legal authority for .CN, there are probably over 150 examples like that. Do you imagine the EU will try to hold CNNIC to GDPR requirements? > >   > > But that jurisdiction arises from an individual's EU nation > citizenship. > > So why not just have a checkmark at domain registration which asks > whether you believe yourself to be within the EU's jurisdiction and, > if so, no WHOIS publication for you, or very limited. > > > For the companies that are subject to GDPR, they have to do this for every > natural person, not only the EU ones.  > > So this checkmark could in fact be "The registrant is a legal person, not a > natural person".  No, because EU regulation doesn't apply to anything even approaching a majority of persons on this planet. There are about 500M people within the EU, and arguably the regulations can also extend to those doing business with companies doing any business within the EU. Nonetheless there are still about 7 billion people on the planet of which around 3 billion or so regularly use the internet and maybe 300M who own domain names, etc. And the extent to which a company might be beholden to an EU regulation such as this in the case of a non-EU citizen merely due to EU legal jurisdiction over that company (or one of its subsidiaries) is, to be kind, unsettled law. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From kmedcalf at dessus.com Sun Apr 15 02:06:56 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 14 Apr 2018 20:06:56 -0600 Subject: Is WHOIS going to go away? In-Reply-To: <23250.31248.362240.808600@gargle.gargle.HOWL> Message-ID: >Does anyone believe privacy etc will be enhanced by forbidding your >finding out who owns this domain you were directed towards by a >search engine? >Granted you may not get a satisfactory answer but then maybe you >choose not to do business with them, ok, your choice. >But what if the response is "SORRY BLOCKED BY GDPR"? >Do you do business with them? Or not? Not. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From sean at donelan.com Sun Apr 15 16:05:24 2018 From: sean at donelan.com (Sean Donelan) Date: Sun, 15 Apr 2018 12:05:24 -0400 (EDT) Subject: =?ISO-8859-7?Q?FEMA=A2s_plan_underestimated_Puerto_Rican_hurric?= =?ISO-8859-7?Q?ane?= Message-ID: In the U.S. disaster response system, the primary responsbility for disaster response falls on state (territory) and local governments. In theory, the federal government response is supposed to be secondary. https://www.politico.com/story/2018/04/15/puerto-rico-hurricane-fema-disaster-523033 [...] The plan also expected private sector companies to quickly restore telecommunications on the island. “There are minimal expectations that federal assistance would be required to restore the infrastructure during the response and recovery of a storm,” it said. If communication systems were not fixed quickly, the document said, first responders could use satellite phones instead or rely on mobile communication trucks delivered to the island. But during Maria, Puerto Rico’s communication system was wiped out, leaving telecommunications companies scrambling to slowly repair the infrastructure as state and local officials struggled to communicate with FEMA and other first responders. Local officials described limited communications as one of the biggest challenges in the first week after the storm. [...] To many in the disaster community, the problems with FEMA’s plan were representative of broader disaster management challenges across the entire agency. FEMA, individual communities and the country prepare for disasters that fit within their current capabilities, they said, but don’t plan for disasters that could cause even more damage, requiring greater planning or resources in such a dire scenario. “If you go back and look at almost any federal disaster plan, it suffers from planning to your current capabilities versus planning to what actually could happen,” said a former FEMA official, adding “I wouldn’t say this is a special case, but it is a problem endemic to the federal government.” [...] From bgreene at senki.org Sun Apr 15 20:24:07 2018 From: bgreene at senki.org (Barry Raveendran Greene) Date: Mon, 16 Apr 2018 08:24:07 +1200 Subject: =?utf-8?Q?Re:_FEMA=E2=80=99s_plan_underestimated_Puerto_Rican_hu?= =?utf-8?Q?rricane?= In-Reply-To: References: Message-ID: The “private sector will fix” expectation will be normal for today’s governments. The challenge with climate chaos, is that Puerto Rico was another step to the new normal. > On Apr 16, 2018, at 04:05, Sean Donelan wrote: > > > In the U.S. disaster response system, the primary responsbility for disaster response falls on state (territory) and local governments. In theory, the federal government response is supposed to be secondary. > > > https://www.politico.com/story/2018/04/15/puerto-rico-hurricane-fema-disaster-523033 > > [...] > > The plan also expected private sector companies to quickly restore telecommunications on the island. “There are minimal expectations that federal assistance would be required to restore the infrastructure during the response and recovery of a storm,” it said. If communication systems were not fixed quickly, the document said, first responders could use satellite phones instead or rely on mobile communication trucks delivered to the island. > > But during Maria, Puerto Rico’s communication system was wiped out, leaving telecommunications companies scrambling to slowly repair the infrastructure as state and local officials struggled to communicate with FEMA and other first responders. Local officials described limited communications as one of the biggest challenges in the first week after the storm. > > [...] > > To many in the disaster community, the problems with FEMA’s plan were representative of broader disaster management challenges across the entire agency. FEMA, individual communities and the country prepare for disasters that fit within their current capabilities, they said, but don’t plan for disasters that could cause even more damage, requiring greater planning or resources in such a dire scenario. > > “If you go back and look at almost any federal disaster plan, it suffers from planning to your current capabilities versus planning to what actually could happen,” said a former FEMA official, adding “I wouldn’t say this is a special case, but it is a problem endemic to the federal government.” > > [...] From nanog at ics-il.net Sun Apr 15 20:28:38 2018 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 15 Apr 2018 15:28:38 -0500 (CDT) Subject: =?utf-8?Q?Re:_FEMA=E2=80=99s_plan_underestimated_Puerto_Rican_hurricane?= In-Reply-To: References: Message-ID: <609443179.493.1523824114817.JavaMail.mhammett@ThunderFuck> Companies like http://aeronetpr.com/ have been in over-drive taking customers from the wireline companies that can't rebuild at a reasonable pace. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Sean Donelan" To: nanog at nanog.org Sent: Sunday, April 15, 2018 11:05:24 AM Subject: FEMA’s plan underestimated Puerto Rican hurricane In the U.S. disaster response system, the primary responsbility for disaster response falls on state (territory) and local governments. In theory, the federal government response is supposed to be secondary. https://www.politico.com/story/2018/04/15/puerto-rico-hurricane-fema-disaster-523033 [...] The plan also expected private sector companies to quickly restore telecommunications on the island. “There are minimal expectations that federal assistance would be required to restore the infrastructure during the response and recovery of a storm,” it said. If communication systems were not fixed quickly, the document said, first responders could use satellite phones instead or rely on mobile communication trucks delivered to the island. But during Maria, Puerto Rico’s communication system was wiped out, leaving telecommunications companies scrambling to slowly repair the infrastructure as state and local officials struggled to communicate with FEMA and other first responders. Local officials described limited communications as one of the biggest challenges in the first week after the storm. [...] To many in the disaster community, the problems with FEMA’s plan were representative of broader disaster management challenges across the entire agency. FEMA, individual communities and the country prepare for disasters that fit within their current capabilities, they said, but don’t plan for disasters that could cause even more damage, requiring greater planning or resources in such a dire scenario. “If you go back and look at almost any federal disaster plan, it suffers from planning to your current capabilities versus planning to what actually could happen,” said a former FEMA official, adding “I wouldn’t say this is a special case, but it is a problem endemic to the federal government.” [...] From jayfar at jayfar.com Tue Apr 17 15:24:36 2018 From: jayfar at jayfar.com (Jay Farrell) Date: Tue, 17 Apr 2018 11:24:36 -0400 Subject: US-CERT: Alert (TA18-106A) Russian State-Sponsored Cyber Actors Targeting Network Infrastructure Devices Message-ID: https://www.us-cert.gov/ncas/alerts/TA18-106A From Ryan.Hamel at quadranet.com Wed Apr 18 10:37:57 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Wed, 18 Apr 2018 10:37:57 +0000 Subject: Attacks on BGP Routing Ranges Message-ID: <1524047875360.80045@quadranet.com> Hello, I wanted to poll everyones thoughts on how to deal with attacks directly on BGP peering ranges (/30's, /127's). I know that sending an RTBH for our side of the upstream routing range does not resolve the issue, and it would actually make things worse by blackholing all inbound traffic on the carrier I send the null to. What are my options for carriers that are not willing to help investigate the situation or write up a firewall rule to mitigate it on the circuit? I am not a fan of naming and shaming because it has unintended consequences. Thanks in advance for everyone's suggestions. Ryan Hamel From job at instituut.net Wed Apr 18 10:44:47 2018 From: job at instituut.net (Job Snijders) Date: Wed, 18 Apr 2018 10:44:47 +0000 Subject: Attacks on BGP Routing Ranges In-Reply-To: <1524047875360.80045@quadranet.com> References: <1524047875360.80045@quadranet.com> Message-ID: Hi, On Wed, 18 Apr 2018 at 11:39, Ryan Hamel wrote: > I wanted to poll everyones thoughts on how to deal with attacks directly > on BGP peering ranges (/30's, /127's). > > I know that sending an RTBH for our side of the upstream routing range > does not resolve the issue, and it would actually make things worse by > blackholing all inbound traffic on the carrier I send the null to. What are > my options for carriers that are not willing to help investigate the > situation or write up a firewall rule to mitigate it on the circuit? I am > not a fan of naming and shaming because it has unintended consequences. > > Thanks in advance for everyone's suggestions. Some carriers offer “unreachable linknets”, linknets that are carved from netblocks that aren’t announced in the DFZ or are firewalled off. If the carrier doesn’t want to help, your best course of action may be to disconnect the circuit to stop the attack traffic. Kind regards, Job From saku at ytti.fi Wed Apr 18 10:48:01 2018 From: saku at ytti.fi (Saku Ytti) Date: Wed, 18 Apr 2018 13:48:01 +0300 Subject: Attacks on BGP Routing Ranges In-Reply-To: <1524047875360.80045@quadranet.com> References: <1524047875360.80045@quadranet.com> Message-ID: Hey Ryan, I'm assuming edge link in your network facing another administrative domain. You'll have two scenarios 1) attack coming from your side 2) attack coming from far side You can easily stop 1, obviously. But for 2, you really need to have far-side who is cooperative and understanding of best practices and there isn't any magic you alone can do with entirely uncooperative far-end. Things to consider at both ends: a) edge filter, on all edge interfaces ensure that only udp traceroute, icmp are sent (policed) to infrastructure addresses b) do not advertise link networks in iBGP c) do run BGP with GTSM, so you can drop BGP packets with lower TTL than 255 On 18 April 2018 at 13:37, Ryan Hamel wrote: > Hello, > > I wanted to poll everyones thoughts on how to deal with attacks directly on BGP peering ranges (/30's, /127's). > > I know that sending an RTBH for our side of the upstream routing range does not resolve the issue, and it would actually make things worse by blackholing all inbound traffic on the carrier I send the null to. What are my options for carriers that are not willing to help investigate the situation or write up a firewall rule to mitigate it on the circuit? I am not a fan of naming and shaming because it has unintended consequences. > > Thanks in advance for everyone's suggestions. > > Ryan Hamel -- ++ytti From Ryan.Hamel at quadranet.com Wed Apr 18 10:56:32 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Wed, 18 Apr 2018 10:56:32 +0000 Subject: Attacks on BGP Routing Ranges In-Reply-To: References: <1524047875360.80045@quadranet.com>, Message-ID: <1524048990433.65335@quadranet.com> Job, Unfortunately, with my current situation, we have stopped exporting our prefixes with the tier-1 carrier and still use the outbound bandwidth. I highly doubt they will implement such a solution, but is something to keep in mind for the future. Thanks for the tip! Ryan Hamel ________________________________ From: Job Snijders Sent: Wednesday, April 18, 2018 3:44 AM To: Ryan Hamel Cc: nanog at nanog.org Subject: Re: Attacks on BGP Routing Ranges Hi, On Wed, 18 Apr 2018 at 11:39, Ryan Hamel > wrote: I wanted to poll everyones thoughts on how to deal with attacks directly on BGP peering ranges (/30's, /127's). I know that sending an RTBH for our side of the upstream routing range does not resolve the issue, and it would actually make things worse by blackholing all inbound traffic on the carrier I send the null to. What are my options for carriers that are not willing to help investigate the situation or write up a firewall rule to mitigate it on the circuit? I am not a fan of naming and shaming because it has unintended consequences. Thanks in advance for everyone's suggestions. Some carriers offer "unreachable linknets", linknets that are carved from netblocks that aren't announced in the DFZ or are firewalled off. If the carrier doesn't want to help, your best course of action may be to disconnect the circuit to stop the attack traffic. Kind regards, Job From Ryan.Hamel at quadranet.com Wed Apr 18 11:03:57 2018 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Wed, 18 Apr 2018 11:03:57 +0000 Subject: Attacks on BGP Routing Ranges In-Reply-To: References: <1524047875360.80045@quadranet.com>, Message-ID: <1524049435506.59806@quadranet.com> Saku, The attacks are definitely inbound on the border router interface. I have tracked outbound attacks before and wish it was this simple, but its not. > a) edge filter, on all edge interfaces ensure that only udp traceroute, icmp are sent (policed) to infrastructure addresses While I can implement an edge filter to drop such traffic, it's impacting our clients traffic as well. > b) do not advertise link networks in iBGP This has never been an issue. > c) do run BGP with GTSM, so you can drop BGP packets with lower TTL than 255 Could you explain how this can resolve my issue? I am not sure how this would work. Thanks for your input! Ryan Hamel ________________________________________ From: Saku Ytti Sent: Wednesday, April 18, 2018 3:48 AM To: Ryan Hamel Cc: nanog at nanog.org Subject: Re: Attacks on BGP Routing Ranges Hey Ryan, I'm assuming edge link in your network facing another administrative domain. You'll have two scenarios 1) attack coming from your side 2) attack coming from far side You can easily stop 1, obviously. But for 2, you really need to have far-side who is cooperative and understanding of best practices and there isn't any magic you alone can do with entirely uncooperative far-end. Things to consider at both ends: a) edge filter, on all edge interfaces ensure that only udp traceroute, icmp are sent (policed) to infrastructure addresses b) do not advertise link networks in iBGP c) do run BGP with GTSM, so you can drop BGP packets with lower TTL than 255 On 18 April 2018 at 13:37, Ryan Hamel wrote: > Hello, > > I wanted to poll everyones thoughts on how to deal with attacks directly on BGP peering ranges (/30's, /127's). > > I know that sending an RTBH for our side of the upstream routing range does not resolve the issue, and it would actually make things worse by blackholing all inbound traffic on the carrier I send the null to. What are my options for carriers that are not willing to help investigate the situation or write up a firewall rule to mitigate it on the circuit? I am not a fan of naming and shaming because it has unintended consequences. > > Thanks in advance for everyone's suggestions. > > Ryan Hamel -- ++ytti From jlewis at lewis.org Wed Apr 18 11:39:19 2018 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 18 Apr 2018 07:39:19 -0400 (EDT) Subject: Attacks on BGP Routing Ranges In-Reply-To: <1524049435506.59806@quadranet.com> References: <1524047875360.80045@quadranet.com>, <1524049435506.59806@quadranet.com> Message-ID: On Wed, 18 Apr 2018, Ryan Hamel wrote: >> c) do run BGP with GTSM, so you can drop BGP packets with lower TTL than 255 > > Could you explain how this can resolve my issue? I am not sure how this would work. If the issue is flooding to your interface IP, that's not a relevant countermeasure. You're pretty much limited to asking the upstream to filter traffic to your interface IP, or asking them if you can renumber the interface into non-globally-routed IPs. If they're unwilling to do either, "you've chosen the wrong transit provider" and should start shopping for replacements. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From spano at datacast.it Wed Apr 18 12:26:37 2018 From: spano at datacast.it (=?UTF-8?Q?Giuseppe_Span=c3=b2_-_Datacast_Srl?=) Date: Wed, 18 Apr 2018 14:26:37 +0200 Subject: Suggestion for Layer 3, all SFP+ switches Message-ID: Hello, we're looking for some L3 switches to be used as distribution devices. They should have all (at leaast 24) SFP+ ports 10G and at least a couple of upstream ports 40G capable, but what is most important, they should be able to run MPLS, EoMPLS and VPLS. Is there any device you would suggest us? We where thinking about NEXUS but I'm sure there are also others, even if it is not so easy to find them on the Internet. Thank you in advance for your help . Giuseppe Spanò Datacast Srl From jared at puck.nether.net Wed Apr 18 14:45:44 2018 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 18 Apr 2018 10:45:44 -0400 Subject: ANRW 2018 Message-ID: I’m forwarding this on behalf of the ANRW Chairs. Some of this research has been quite interesting, and is on-topic to what NANOG folks are interested in. Here’s some more details about it: https://irtf.org/anrp You can find their slides and presentation videos online as well, with the most recent one here: https://youtu.be/6v1TU4zsp5E?t=54m30s If you’re an operator and going to be at IETF in Montreal this summer, let me know. — snip — In recent years, the focus of many of top academic networking conferences has shifted away from the wide-area Internet. At the same time, the Internet Engineering Task Force (IETF) remains a top place to do practice-facing research on wide-area networking and security protocols. So, we thought its time to bring academics to the IETF, and develop an exciting academic venue that refocuses the community on wide-area networking and security research! To that end, we are rebooting the Applied Networking Research Workshop (ARNW’18) that we be held during IETF’102 on July 16 2018. The goal is to create a top academic venue for wide-area networking and security research and a path to transition research back into IETF standards, while inspiring academics to work on topics and open problems addressed at the IETF. We have several high-quality invited talks lined up (see below!), and are now soliciting submitted talks and papers. Submitted talks can be not-for-publication *re-submissions* of works that have been published elsewhere during the last 12 months; for these, we simply require a 2 page abstract. We are also seeking 6-page short papers for publication. Paper submission deadline is April 20, 2018. If you think your work can have an impact on the design and operation of the Internet, please consider submitting to ANRW'18! Call for papers: https://irtf.org/anrw/2018/cfp.html Invited talks: Why (and How) Networks Should Run Themselves Speaker: Nick Feamster (Princeton University) ARTEMIS: Neutralizing BGP Hijacking within a Minute Speaker: Alberto Dainotti (CAIDA) Run, Walk, Crawl: Towards Dynamic Link Capacities Speaker: Monia Ghobadi (Microsoft Research) TCP Congestion Signatures Speaker: Srikanth Sundaresan (UC Berkeley) or Amogh Dhamdhere (CAIDA) Measuring Adoption of Security Additions to the HTTPS Ecosystem Speaker: Quirin Scheitle (Technical University of Munich) Hope to see you in Montreal! Sharon Goldberg & David Choffnes ANRW'18 Program Committee Chairs From saku at ytti.fi Wed Apr 18 14:54:35 2018 From: saku at ytti.fi (Saku Ytti) Date: Wed, 18 Apr 2018 17:54:35 +0300 Subject: Attacks on BGP Routing Ranges In-Reply-To: <1524049435506.59806@quadranet.com> References: <1524047875360.80045@quadranet.com> <1524049435506.59806@quadranet.com> Message-ID: Hey, On 18 April 2018 at 14:03, Ryan Hamel wrote: >> a) edge filter, on all edge interfaces ensure that only udp traceroute, icmp are sent (policed) to infrastructure addresses > > While I can implement an edge filter to drop such traffic, it's impacting our clients traffic as well. I don't understand why that would be true, your customers shouldn't be using links for anything useful. But again, in your case the attack is coming from far-end, so they need to do this, to benefit you. >> b) do not advertise link networks in iBGP > This has never been an issue. If is now. If the links is far-end assigned, and if far-end does not advertise it, then attack has to come from same far-end router as where you're connected, greatly reducing attack surface. >> c) do run BGP with GTSM, so you can drop BGP packets with lower TTL than 255 > > Could you explain how this can resolve my issue? I am not sure how this would work. If your link isn't protected, then attacking just your BGP session allows to bring down the BGP with very modest Mbps, like <5Mbps. If you do GTSM and drop <255 TTL BGP, then typically attacker can't bring down the BGP session, or at very least they need to congest whole linerate. -- ++ytti From bill at herrin.us Wed Apr 18 15:35:35 2018 From: bill at herrin.us (William Herrin) Date: Wed, 18 Apr 2018 11:35:35 -0400 Subject: Attacks on BGP Routing Ranges In-Reply-To: <1524049435506.59806@quadranet.com> References: <1524047875360.80045@quadranet.com> <1524049435506.59806@quadranet.com> Message-ID: On Wed, Apr 18, 2018 at 7:03 AM, Ryan Hamel wrote: > The attacks are definitely inbound on the border router interface. I have tracked outbound attacks before and wish it was this simple, but its not. > >> a) edge filter, on all edge interfaces ensure that only udp traceroute, icmp are sent (policed) to infrastructure addresses > > While I can implement an edge filter to drop such traffic, it's impacting our clients traffic as well. Access list accept from bgp peer to local bgp address Access list reject all to local bgp subnet Access list accept everything else Attack packets still cross the link, but then they die without any further effect. If the problem is that the attacker is forging the source address of your ISP's BGP peering address then your ISP has a problem with their filters that they must fix on pain of losing you as a customer. If the problem is they're flooding your link with trash packets Job's unreachable linknets will help but ultimately the attacker can just switch to some other IP address you can't afford to change. If your ISP can't help, this is where a DDOS mitigation service comes in to play. >> c) do run BGP with GTSM, so you can drop BGP packets with lower TTL than 255 > > Could you explain how this can resolve my issue? I am not sure how this would work. With GTSM, your router will reject any BGP packet which does not still have an layer-3 TTL of 255. Since 255 is the highest the TTL can be set and the TTL is decremented every hop, only an adjacent router can send a packet that you will receive with a TTL of 255. Personally, I wouldn't do this. Normal BGP operation is that the BGP packet starts with a TTL of 1. If the neighbor is not adjacent, the packet expires before it reaches your router. If it reaches your router with a TTL larger than 1 and you haven't enabled bgp multihop then the packet is discarded. Changing BGP's semantics like this requires cooperation and expertise from your ISP and is likely to be brittle. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From eric at lumaoptics.net Wed Apr 18 19:49:06 2018 From: eric at lumaoptics.net (Eric Litvin) Date: Wed, 18 Apr 2018 12:49:06 -0700 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: References: Message-ID: <0E9D02DC-1120-4161-B259-B046C6542D16@lumaoptics.net> Brocade/arris is eager for business these days. They have a nice switch (10g ports with 40g stacking) that should meet your needs with very aggressive pricing. Eric Sent from my iPhone > On Apr 18, 2018, at 5:26 AM, Giuseppe Spanò - Datacast Srl wrote: > > Hello, > > we're looking for some L3 switches to be used as distribution devices. They should have all (at leaast 24) SFP+ ports 10G and at least a couple of upstream ports 40G capable, but what is most important, they should be able to run MPLS, EoMPLS and VPLS. Is there any device you would suggest us? We where thinking about NEXUS but I'm sure there are also others, even if it is not so easy to find them on the Internet. > > Thank you in advance for your help . > > Giuseppe Spanò > Datacast Srl From lists.nanog at monmotha.net Wed Apr 18 20:01:16 2018 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 18 Apr 2018 16:01:16 -0400 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: <0E9D02DC-1120-4161-B259-B046C6542D16@lumaoptics.net> References: <0E9D02DC-1120-4161-B259-B046C6542D16@lumaoptics.net> Message-ID: On 04/18/2018 03:49 PM, Eric Litvin wrote: > Brocade/arris is eager for business these days. They have a nice switch (10g ports with 40g stacking) that should meet your needs with very aggressive pricing. Does the Brocade/Foundry-lineage stuff that went to Arris actually do MPLS? I didn't think ICX did any MPLS. The SLX (and MLX) line that went to Extreme does but is perhaps overkill (it will also do Internet-scale FIB). The SLX9540 is a 48 port SFP+ pizza box that also has 6 40/100Gb QSFP+/28 ports on it. You'd need the "advanced feature" license for MPLS, and I don't know how mature the MPLS code is. Pricing I've seen is pretty good for what you get, but again it may be overkill. Juniper has some nice boxes in the EX series with at least MPLS L2-endpoint functionality that might also be an option for this sort of thing, but I don't know any models off the top of my head. -- Brandon Martin From hf0002+nanog at uah.edu Wed Apr 18 20:06:25 2018 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Wed, 18 Apr 2018 20:06:25 +0000 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: References: <0E9D02DC-1120-4161-B259-B046C6542D16@lumaoptics.net> Message-ID: Ruckus ICX switches do not do MPLS. They meet all the other requirements listed, but unfortunately MPLS was listed as the most important one. On Wed, Apr 18, 2018 at 3:01 PM Brandon Martin wrote: > On 04/18/2018 03:49 PM, Eric Litvin wrote: > > Brocade/arris is eager for business these days. They have a nice switch > (10g ports with 40g stacking) that should meet your needs with very > aggressive pricing. > > Does the Brocade/Foundry-lineage stuff that went to Arris actually do > MPLS? I didn't think ICX did any MPLS. > > The SLX (and MLX) line that went to Extreme does but is perhaps overkill > (it will also do Internet-scale FIB). The SLX9540 is a 48 port SFP+ > pizza box that also has 6 40/100Gb QSFP+/28 ports on it. You'd need the > "advanced feature" license for MPLS, and I don't know how mature the > MPLS code is. Pricing I've seen is pretty good for what you get, but > again it may be overkill. > > Juniper has some nice boxes in the EX series with at least MPLS > L2-endpoint functionality that might also be an option for this sort of > thing, but I don't know any models off the top of my head. > -- > Brandon Martin > -- -- Hunter Fuller Network Engineer VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Systems and Infrastructure From lguillory at reservetele.com Wed Apr 18 20:09:54 2018 From: lguillory at reservetele.com (Luke Guillory) Date: Wed, 18 Apr 2018 20:09:54 +0000 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: References: <0E9D02DC-1120-4161-B259-B046C6542D16@lumaoptics.net> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5C027F942F00@RTC-EXCH01.RESERVE.LDS> Juniper ACX 5048 is what we use though you need to license 10g ports (ACX5K-L-1X10GE) and VPN (ACX5K-L-IPVPN) QFX does MPLS but I'm pretty sure it doesn't do VPLs. ns -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Brandon Martin Sent: Wednesday, April 18, 2018 3:01 PM To: nanog at nanog.org Subject: Re: Suggestion for Layer 3, all SFP+ switches On 04/18/2018 03:49 PM, Eric Litvin wrote: > Brocade/arris is eager for business these days. They have a nice switch (10g ports with 40g stacking) that should meet your needs with very aggressive pricing. Does the Brocade/Foundry-lineage stuff that went to Arris actually do MPLS? I didn't think ICX did any MPLS. The SLX (and MLX) line that went to Extreme does but is perhaps overkill (it will also do Internet-scale FIB). The SLX9540 is a 48 port SFP+ pizza box that also has 6 40/100Gb QSFP+/28 ports on it. You'd need the "advanced feature" license for MPLS, and I don't know how mature the MPLS code is. Pricing I've seen is pretty good for what you get, but again it may be overkill. Juniper has some nice boxes in the EX series with at least MPLS L2-endpoint functionality that might also be an option for this sort of thing, but I don't know any models off the top of my head. -- Brandon Martin From fw at deneb.enyo.de Wed Apr 18 20:51:49 2018 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 18 Apr 2018 22:51:49 +0200 Subject: Is WHOIS going to go away? In-Reply-To: <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> (Filip Hruska's message of "Sat, 14 Apr 2018 20:20:06 +0000") References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> Message-ID: <87a7u0i6fu.fsf@mid.deneb.enyo.de> * Filip Hruska: > On 04/14/2018 07:29 PM, Florian Weimer wrote: >> * Filip Hruska: >> >>> EURID (.eu) WHOIS already works on a basis that no information about the >>> registrant is available via standard WHOIS. >>> In order to get any useful information you have to go to >>> https://whois.eurid.eu and make a request there. >>> >>> Seems like a reasonable solution. >> Why? How does the protocol matter? >> >> Either you may publish individual personal information for use by the >> general public, or you may not. Adding a 4 to the port number doesn't >> change that. >> > > The EURID webwhois cannot be scraped, there are anti-bot measures in > place (captcha, throttling, all information displayed in images). > Scraping WHOIS systems for thousands domains at once using the WHOIS > protocol is easy though. There are "WHOIS History" sites which scrape > all domains and then publish the data along with the date of retrieval. > > GDPR contains this in relation to the right to erasure: > > 1. Where the controller has made the personal data public and is > obliged pursuant to paragraph 1 to erase the personal data, *the > controller, taking account of available technology and the cost of > implementation, shall take reasonable steps, including technical > measures, to inform controllers which are processing the personal > data that the data subject has requested the erasure* by such > controllers of any links to, or*copy or replication of, those > personal data*. Wouldn't that require a channel to the recipient of WHOIS data, so that the controller can notify those who have accessed it once erasure is requested? A simple webform doesn't achieve that because it's not much different from the way traditional WHOIS works. From rubensk at gmail.com Wed Apr 18 20:56:21 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 18 Apr 2018 17:56:21 -0300 Subject: Is WHOIS going to go away? In-Reply-To: <87a7u0i6fu.fsf@mid.deneb.enyo.de> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <87a7u0i6fu.fsf@mid.deneb.enyo.de> Message-ID: On Wed, Apr 18, 2018 at 5:51 PM, Florian Weimer wrote: > * Filip Hruska: > > > On 04/14/2018 07:29 PM, Florian Weimer wrote: > >> * Filip Hruska: > >> > >>> EURID (.eu) WHOIS already works on a basis that no information about > the > >>> registrant is available via standard WHOIS. > >>> In order to get any useful information you have to go to > >>> https://whois.eurid.eu and make a request there. > >>> > >>> Seems like a reasonable solution. > >> Why? How does the protocol matter? > >> > >> Either you may publish individual personal information for use by the > >> general public, or you may not. Adding a 4 to the port number doesn't > >> change that. > >> > > > > The EURID webwhois cannot be scraped, there are anti-bot measures in > > place (captcha, throttling, all information displayed in images). > > Scraping WHOIS systems for thousands domains at once using the WHOIS > > protocol is easy though. There are "WHOIS History" sites which scrape > > all domains and then publish the data along with the date of retrieval. > > > > GDPR contains this in relation to the right to erasure: > > > > 1. Where the controller has made the personal data public and is > > obliged pursuant to paragraph 1 to erase the personal data, *the > > controller, taking account of available technology and the cost of > > implementation, shall take reasonable steps, including technical > > measures, to inform controllers which are processing the personal > > data that the data subject has requested the erasure* by such > > controllers of any links to, or*copy or replication of, those > > personal data*. > > Wouldn't that require a channel to the recipient of WHOIS data, so > that the controller can notify those who have accessed it once erasure > is requested? > > A simple webform doesn't achieve that because it's not much different > from the way traditional WHOIS works. > A simple webform doesn't provide the personal data, just relay a message. Anyways, I heard registrars mentioning a double form where the e-mail address of the party sending the message to the domain owner is first confirmed before relaying the message. That would provide accountability for who sent what, if the message turns out to be harassment, threatening or alike. Rubens From aaron1 at gvtc.com Wed Apr 18 20:58:31 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 18 Apr 2018 15:58:31 -0500 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: References: Message-ID: <001b01d3d758$02464590$06d2d0b0$@gvtc.com> look at these... * Juniper ACX5048 - I've deployed about ~50 of these over the last couple years and they are great boxes. I'm using them as mpls p/pe running L3VPN (v4 and tested 6vpe), L2VPN (manual martini l2circuits and bgp-ad rfc4762, I'll say that IOS XR asr9k has an occasional problem with vpls pw towards acx5048 rfc4762, overcome with bounce of ldp neighbor only when needed, not sure who to blame) (48) 10 gig sfp+ (6) 40 gig qsfp+ - or these can run as (24) 10 gig ports using a break-out cable * Cisco NCS5K and its variants as I think there are a few....you might find a 10/40 gig option here, however I recall the one I tested with in my lab a few years ago had 10/100 gig. I will say that when I tested it a few year back that I wasn't ready for prime time, but, in cisco defense, they've had a few years to make improvements on it and I should, and you should, look into it. * Juniper ACX5400 (ACX5448) - I'm seeing this advertised on juniper.net now...new box - I want one for my lab - (48) 10 gig - (4) 100 gig, check if you can slide a 40 gig optic into that qsfp slot * Juniper ACX5k+ - unsure if it's advertised yet by Juniper... this is a new box - I want one for my lab - lots of 10 gig and I recall some 25 or 40 or 100, I don't recall https://www.mail-archive.com/nanog at nanog.org/msg93672.html or google - 1/2u 100g Metro-E Aggregation Switch * Juniper EX4550 - I've ran these are virtual chassis paired top-of-rack in my small data centers with rock solid performance - with multiple cdn caches sitting behind them. Now, I have tested L3VPN some years back, and I've heard they also do L2VPN martini manual pw's...i'm about to give them another go in mpls testing... check back with my shortly if you wanna know how it goes. Yesterday I pushed in my first EX4550-EM-2QSFP 40 gig module into my lab EX4550 in preparation for new supercore (100 gig mx960's) and had to upgrade junos from v12 to v13 (wasn't avail so went with 14.1X53-D46.7) and now optic was visible in that 40 gig module in the ex4550 - (32) 10 gig ports - (2) 40 gig - Aaron From colton.conor at gmail.com Thu Apr 19 01:32:17 2018 From: colton.conor at gmail.com (Colton Conor) Date: Wed, 18 Apr 2018 20:32:17 -0500 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: References: Message-ID: What is your budget? I know on the low end many operators are using the Huawei S6720S-26Q-EI-24S-AC. You can get these new for $2500 to $3500, and the support all the features and port counts you requested. The also have a lifetime warranty that includes advanced replacement (10 days), TAC support, and software support all for free if you buy through official channels. It support MPLS, and also VXLAN. Extreme seems to have some good options, but I doubt they are that low cost. For Juniper you need to look at the ACX series which is expensive. Like the ACX5048 which list price is $40k not that anyone pays list, and that's before port licenses. The EX series does not have proper MPLS support. Cisco has mutliple options, but mainly the NCS based on your port count I think. Supposely the C3850 and C9500 now support MPLS? There is a new 16 port 10G version of the C9500. I haven't looked into Nexus switches. Does Nexus support full MPLS? HPE has some low cost options. In their FlexFabric and FlexNetwork lines that support MPLS in Comware V7. Who else are we missing? MPLS support really cuts down this list, but I agree its a critical feature for most service providers. On Wed, Apr 18, 2018 at 7:26 AM, Giuseppe Spanò - Datacast Srl < spano at datacast.it> wrote: > Hello, > > we're looking for some L3 switches to be used as distribution devices. > They should have all (at leaast 24) SFP+ ports 10G and at least a couple of > upstream ports 40G capable, but what is most important, they should be able > to run MPLS, EoMPLS and VPLS. Is there any device you would suggest us? We > where thinking about NEXUS but I'm sure there are also others, even if it > is not so easy to find them on the Internet. > > Thank you in advance for your help . > > Giuseppe Spanò > Datacast Srl > From rdobbins at arbor.net Thu Apr 19 03:01:46 2018 From: rdobbins at arbor.net (Roland Dobbins) Date: Thu, 19 Apr 2018 10:01:46 +0700 Subject: Attacks on BGP Routing Ranges In-Reply-To: <1524049435506.59806@quadranet.com> References: <1524047875360.80045@quadranet.com> <1524049435506.59806@quadranet.com> Message-ID: <0D4CD724-A8F3-4B4F-84CC-ACF7FA74F51F@arbor.net> On 18 Apr 2018, at 18:03, Ryan Hamel wrote: > Could you explain how this can resolve my issue? I am not sure how > this would work. You should have iACLs and GTSM enabled, as noted previously. Ideally, the link should come from an unadvertised range, or a range which is sunk to null0 at the edge, as Job indicated. If the link is numbered from a range assigned to your peer, they should have iACLs in place to prevent that range being packeted. If the link is numbered from your own range, you should ask your peer to add that range to their iACLs, as well. This .pdf preso discusses infrastructure self-protection concepts: ----------------------------------- Roland Dobbins From jean at ddostest.me Thu Apr 19 10:41:35 2018 From: jean at ddostest.me (Jean | ddostest.me) Date: Thu, 19 Apr 2018 06:41:35 -0400 Subject: Attacks on BGP Routing Ranges In-Reply-To: <0D4CD724-A8F3-4B4F-84CC-ACF7FA74F51F@arbor.net> References: <1524047875360.80045@quadranet.com> <1524049435506.59806@quadranet.com> <0D4CD724-A8F3-4B4F-84CC-ACF7FA74F51F@arbor.net> Message-ID: <964c2e56-0170-f9d0-a403-e4db45d9a88d@ddostest.me> Maybe we are missing a key item here. Ryan, is the attack on the BGP peering range killing your router or is it an attack saturating the link? Do you have some netflow samples of one of these attacks or any kind of hints of what happened? Jean St-Laurent On 04/18/2018 11:01 PM, Roland Dobbins wrote: > On 18 Apr 2018, at 18:03, Ryan Hamel wrote: > >>  Could you explain how this can resolve my issue? I am not sure how >> this would work. > > You should have iACLs and GTSM enabled, as noted previously. From uwcableguy at gmail.com Thu Apr 19 13:28:21 2018 From: uwcableguy at gmail.com (Ben Bartsch) Date: Thu, 19 Apr 2018 08:28:21 -0500 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: References: Message-ID: I've been testing IPInfusion OcNOS running on Dell Z9100 and S4048. I've run a couple of test cases using MPLS LDP signaled port based and VLAN based VPWS (pseudowire / e-line / xconnect / Juniper CCC) and VPLS (e-lan) over an OSPFv2 IGP. It's working well between Dell/IPI to Dell/IPI boxes. We have had issues with the VPLS between Dell/IPI to Juniper/JunOS where the circuit will show up on the Juniper and down on the Dell. If we clear LDP session on the Dell, it comes back up right away. This seems to be similar to what Aaron is seeing in his multi-vendor environment. The price on the Dell hardware is really good. The features included with OcNOS are much better than FTOS9. If you aren't partial to Dell, you can run OcNOS on a variety of other whitebox switches, like EdgeCore. I haven't tested MP-BGP and L3VPN or BFD yet, but that is supposedly supported in OcNOS as well. -ben On Wed, Apr 18, 2018 at 8:32 PM, Colton Conor wrote: > What is your budget? > > I know on the low end many operators are using the > Huawei S6720S-26Q-EI-24S-AC. You can get these new for $2500 to $3500, and > the support all the features and port counts you requested. The also have a > lifetime warranty that includes advanced replacement (10 days), TAC > support, and software support all for free if you buy through official > channels. It support MPLS, and also VXLAN. > > Extreme seems to have some good options, but I doubt they are that low > cost. > > For Juniper you need to look at the ACX series which is expensive. Like the > ACX5048 which list price is $40k not that anyone pays list, and that's > before port licenses. The EX series does not have proper MPLS support. > > Cisco has mutliple options, but mainly the NCS based on your port count I > think. Supposely the C3850 and C9500 now support MPLS? There is a new 16 > port 10G version of the C9500. I haven't looked into Nexus switches. Does > Nexus support full MPLS? > > HPE has some low cost options. In their FlexFabric and FlexNetwork lines > that support MPLS in Comware V7. > > Who else are we missing? MPLS support really cuts down this list, but I > agree its a critical feature for most service providers. > > > > > On Wed, Apr 18, 2018 at 7:26 AM, Giuseppe Spanò - Datacast Srl < > spano at datacast.it> wrote: > > > Hello, > > > > we're looking for some L3 switches to be used as distribution devices. > > They should have all (at leaast 24) SFP+ ports 10G and at least a couple > of > > upstream ports 40G capable, but what is most important, they should be > able > > to run MPLS, EoMPLS and VPLS. Is there any device you would suggest us? > We > > where thinking about NEXUS but I'm sure there are also others, even if it > > is not so easy to find them on the Internet. > > > > Thank you in advance for your help . > > > > Giuseppe Spanò > > Datacast Srl > > > From rsk at gsp.org Thu Apr 19 14:24:15 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 19 Apr 2018 10:24:15 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <20180414171410.GA20737@gsp.org> Message-ID: <20180419142414.GA3500@gsp.org> On Sat, Apr 14, 2018 at 05:29:35PM +0000, Aaron C. de Bruyn via NANOG wrote: > So why are you proposing that I can't run my *personal* "I strongly > believe in {insert emotionally-charged issue} site" without letting psychos > know exactly where I live? A PO box might suffice. There are also mail forwarding (and phone forwarding) services that serve the purpose. Having encountered exactly these sorts of psychos, this might be a good idea if you think it's a threat you may have to face. (Although let me note that your address is likely available anyway through some deliberate-public database or through one that's been hacked and subsequently leaked. Or via someone you know who "checked in" with a geolocation app while visiting. Or via someone who handed it over to a third party because they were shipping you something. Or...) Let me suggest that a better choice for these situations is not to register a domain *at all*. Consider: doing so creates a record at your registrar that has information-of-interest about you. All that stands between a psycho and that information is a security breach, a dataloss incident, or -- maybe -- a hundred bucks in an envelope (old style) or a cryptocurrency transfer (new style). Maaaaybe it would be better not to create that record at all. That's why I've always recommended (for example) that dissident political movements in repressive countries avoid registering domains: any dictator worthy of the title will easily acquire the real registration details, whether they're held in-country or not. ---rsk From rsk at gsp.org Thu Apr 19 14:27:24 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 19 Apr 2018 10:27:24 -0400 Subject: Is WHOIS going to go away? In-Reply-To: <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> Message-ID: <20180419142724.GB3500@gsp.org> On Sat, Apr 14, 2018 at 08:20:06PM +0000, Filip Hruska wrote: > Scraping WHOIS systems for thousands domains at once using the WHOIS > protocol is easy though. There are "WHOIS History" sites which scrape all > domains and then publish the data along with the date of retrieval. Which would not be necessary if all WHOIS information was fully published in text/XML/whatever form, available for immediate download/rsync to everyone, and refreshed at intervals (say, once a day). This would neatly undercut the business model for these sites and would ensure that anyone who wants the information can get it efficiently. ---rsk From aaron1 at gvtc.com Thu Apr 19 16:07:47 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 19 Apr 2018 11:07:47 -0500 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: References: Message-ID: <003601d3d7f8$8f3cbce0$adb636a0$@gvtc.com> Aren't there issues/concerns with Huawei ? I think we pay about $10k with discounts and about (4) 10 gig port license to slow start our deployment of ACX5048's.... 10 gig east , 10 gig west , dual 10's facing FTTH OLT (Calix E7) -Aaron From spano at datacast.it Thu Apr 19 16:16:34 2018 From: spano at datacast.it (=?UTF-8?Q?Giuseppe_Span=c3=b2_-_Datacast_Srl?=) Date: Thu, 19 Apr 2018 18:16:34 +0200 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: References: Message-ID: Thank you very much to everyone. The budget is around 3000-5000 $ each, possibly. There are many devices that could match our needs but as usual the dark side of this market is the platforms compatibility. We deployed many Mikrotik and Ericsson devices, hope they will "match" with a Cisco or Juniper or Huawey device with regards to MPLS, EoMPLS, VPLS etc... Anyway your kind help is really very appreciated, we'll decide for one and will test it, no way out I think. Giuseppe Il 19/04/18 03:32, Colton Conor ha scritto: > What is your budget? > > I know on the low end many operators are using the > Huawei S6720S-26Q-EI-24S-AC. You can get these new for $2500 to $3500, > and the support all the features and port counts you requested. The also > have a lifetime warranty that includes advanced replacement (10 days), > TAC support, and software support all for free if you buy through > official channels. It support MPLS, and also VXLAN. > > Extreme seems to have some good options, but I doubt they are that low cost. > > For Juniper you need to look at the ACX series which is expensive. Like > the ACX5048 which list price is $40k not that anyone pays list, and > that's before port licenses. The EX series does not have proper MPLS > support. > > Cisco has mutliple options, but mainly the NCS based on your port count > I think. Supposely the C3850 and C9500 now support MPLS? There is a new > 16 port 10G version of the C9500. I haven't looked into Nexus switches. > Does Nexus support full MPLS? > > HPE has some low cost options. In their FlexFabric and FlexNetwork lines > that support MPLS in Comware V7. > > Who else are we missing? MPLS support really cuts down this list, but I > agree its a critical feature for most service providers. > > > > > On Wed, Apr 18, 2018 at 7:26 AM, Giuseppe Spanò - Datacast Srl > > wrote: > > Hello, > > we're looking for some L3 switches to be used as distribution > devices. They should have all (at leaast 24) SFP+ ports 10G and at > least a couple of upstream ports 40G capable, but what is most > important, they should be able to run MPLS, EoMPLS and VPLS. Is > there any device you would suggest us? We where thinking about NEXUS > but I'm sure there are also others, even if it is not so easy to > find them on the Internet. > > Thank you in advance for your help . > > Giuseppe Spanò > Datacast Srl > > From lukasz at bromirski.net Thu Apr 19 16:50:44 2018 From: lukasz at bromirski.net (=?utf-8?Q?=C5=81ukasz_Bromirski?=) Date: Thu, 19 Apr 2018 18:50:44 +0200 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: References: Message-ID: Colton, > On 19 Apr 2018, at 03:32, Colton Conor wrote: > > Cisco has mutliple options, but mainly the NCS based on your port count I > think. Supposely the C3850 and C9500 now support MPLS? There is a new 16 > port 10G version of the C9500. I haven't looked into Nexus switches. Does > Nexus support full MPLS? UADP based platforms, both older (C3650/3850) and newer (C9xxx) do support MPLS encap and VXLAN encap and can be extended in future to support others. There are new 9xxx based off UADP 3.0 with 40G and 100G ports: https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9500-series-switches/datasheet-c78-738978.html Nexus 7k supports MPLS with LDP while Nexus 9k supports MPLS but with SR (IGP) or BGP-LU (no LDP support). -- Łukasz Bromirski CCIE R&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A From sandy at tislabs.com Thu Apr 19 17:36:03 2018 From: sandy at tislabs.com (Sandra Murphy) Date: Thu, 19 Apr 2018 13:36:03 -0400 Subject: Fwd: [cooperation-wg] Massive IP blockings in Russia References: Message-ID: Of possible interest to this group. Forwarding at Alexander’s suggestion, who says he has already shared info in the NANOG facebook group "(with updated prefixlist)". —Sandy > Begin forwarded message: > > From: Alexander Isavnin > Subject: [cooperation-wg] Massive IP blockings in Russia > Date: April 17, 2018 at 1:36:33 PM EDT > To: cooperation-wg at ripe.net > > Dear colleagues! > > I’m not pleased to inform you that RosComNadzor, a Russian Communication supervisory body, has started blocking huge ranges of IPs belonging to different cloud infrastructures, mostly Amazon and Google Cloud. > Those ranges include: 13.52.0.0/14, 13.56.0.0/14, 18.184.0.0/15, 18.194.0.0/15, 18.196.0.0/15, 34.192.0.0/10, 34.240.0.0/13, 34.248.0.0/13, 35.156.0.0/14, 35.160.0.0/13, 35.176.0.0/15, 52.0.0.0/11, 52.192.0.0/11, 52.208.0.0/13, 52.28.0.0/15, 52.58.0.0/15, 54.144.0.0/12, 54.160.0.0/12, 54.228.0.0/15, 54.72.0.0/15, 54.88.0.0/16. > > Russian ISPs MUST fully block all traffic to such networks. The list is frequently updated and gets automatically propagated to ISP every once in a while, failure to block any address may result in 1500eur fine. > The infrastructure listed above is being added to the blocklist under “counter-terrorist and counter-extremist” order of the General Prosecutor Office, #27-31-2015/Id4082-15, issued in 2015 and often used for blocking an arbitrary unwanted content. > The real reason for such blocking is an attempt to cut access to Telegram messenger, which refused to provide end-to-end encryption keys to the Federal Security Service (previously known as KGB). This is a case similar to San-Bernardino shooter’s, where the FBI was denied access to the shooter’s iPhone, but courts in Russia have made completely opposite decision. > Telegram’s infrastructure is being blocked by a different decision by RosKomNadzor, #2-1779/2018. > Cloud infrastructures are being blocked for massive proxy and VPN hosting used to dodge messenger blocking. > > It is said, that more Apple and Google networks may be blocked soon for apps updates and push notifications delivery for Telegram. > > We hope to still have the global IP connectivity to keep you informed about how the situation develops. > Do not be surprised if some of your services placed in cloud infrastructures will miss Russian customers. > > You can monitor the number of IP addresses, domains and URLs to be blocked in Russia at the https://2018.schors.spb.ru/ page (run by the famous ENOG community member Phil Kulin). > Detailed information (also via API) is available at the https://reestr.rublacklist.net run by RosKomSvoboda civil society group. > > Kind regards, > Alexander Isavnin > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From jared at puck.nether.net Thu Apr 19 18:22:00 2018 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 19 Apr 2018 14:22:00 -0400 Subject: [cooperation-wg] Massive IP blockings in Russia In-Reply-To: References: Message-ID: I know I saw a significant number of suspicious routes from 31133 in the past day or two as well. There appears to be some pretty widespread bogus routing. - jared > On Apr 19, 2018, at 1:36 PM, Sandra Murphy wrote: > > Of possible interest to this group. > > Forwarding at Alexander’s suggestion, who says he has already shared info in the NANOG facebook group "(with updated prefixlist)". > > —Sandy > >> Begin forwarded message: >> >> From: Alexander Isavnin >> Subject: [cooperation-wg] Massive IP blockings in Russia >> Date: April 17, 2018 at 1:36:33 PM EDT >> To: cooperation-wg at ripe.net >> >> Dear colleagues! >> >> I’m not pleased to inform you that RosComNadzor, a Russian Communication supervisory body, has started blocking huge ranges of IPs belonging to different cloud infrastructures, mostly Amazon and Google Cloud. >> Those ranges include: 13.52.0.0/14, 13.56.0.0/14, 18.184.0.0/15, 18.194.0.0/15, 18.196.0.0/15, 34.192.0.0/10, 34.240.0.0/13, 34.248.0.0/13, 35.156.0.0/14, 35.160.0.0/13, 35.176.0.0/15, 52.0.0.0/11, 52.192.0.0/11, 52.208.0.0/13, 52.28.0.0/15, 52.58.0.0/15, 54.144.0.0/12, 54.160.0.0/12, 54.228.0.0/15, 54.72.0.0/15, 54.88.0.0/16. >> >> Russian ISPs MUST fully block all traffic to such networks. The list is frequently updated and gets automatically propagated to ISP every once in a while, failure to block any address may result in 1500eur fine. >> The infrastructure listed above is being added to the blocklist under “counter-terrorist and counter-extremist” order of the General Prosecutor Office, #27-31-2015/Id4082-15, issued in 2015 and often used for blocking an arbitrary unwanted content. >> The real reason for such blocking is an attempt to cut access to Telegram messenger, which refused to provide end-to-end encryption keys to the Federal Security Service (previously known as KGB). This is a case similar to San-Bernardino shooter’s, where the FBI was denied access to the shooter’s iPhone, but courts in Russia have made completely opposite decision. >> Telegram’s infrastructure is being blocked by a different decision by RosKomNadzor, #2-1779/2018. >> Cloud infrastructures are being blocked for massive proxy and VPN hosting used to dodge messenger blocking. >> >> It is said, that more Apple and Google networks may be blocked soon for apps updates and push notifications delivery for Telegram. >> >> We hope to still have the global IP connectivity to keep you informed about how the situation develops. >> Do not be surprised if some of your services placed in cloud infrastructures will miss Russian customers. >> >> You can monitor the number of IP addresses, domains and URLs to be blocked in Russia at the https://2018.schors.spb.ru/ page (run by the famous ENOG community member Phil Kulin). >> Detailed information (also via API) is available at the https://reestr.rublacklist.net run by RosKomSvoboda civil society group. >> >> Kind regards, >> Alexander Isavnin >> >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From colton.conor at gmail.com Thu Apr 19 18:28:06 2018 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 19 Apr 2018 13:28:06 -0500 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: References: Message-ID: Łukasz, Out of all those Cisco models, which meets the OP requirements of " (at least 24) SFP+ ports 10G and at least a couple of upstream ports 40G capable" and a " The budget is around 3000-5000 $ each, possibly. "? The Nexus 7000's look very large with the smallest being 3U in size, so I doubt they would meet the budget requirement. The Nexus 9000 series seems to have 1U versions. Assuming he is fine with using Segmented Routing instead of LDP, any models that fit the bill price wise? Are there any Nexus products that are lower cost that the Catalyst (C3650/3850) and newer (C9xxx)? The Catalyst UADP based platforms seem nice, but most are requiring DNA licensing driving up initial cost. On Thu, Apr 19, 2018 at 11:50 AM, Łukasz Bromirski wrote: > Colton, > > On 19 Apr 2018, at 03:32, Colton Conor wrote: > > Cisco has mutliple options, but mainly the NCS based on your port count I > think. Supposely the C3850 and C9500 now support MPLS? There is a new 16 > port 10G version of the C9500. I haven't looked into Nexus switches. Does > Nexus support full MPLS? > > > UADP based platforms, both older (C3650/3850) and newer (C9xxx) do > support MPLS encap and VXLAN encap and can be extended in future to > support others. There are new 9xxx based off UADP 3.0 with 40G and 100G > ports: > https://www.cisco.com/c/en/us/products/collateral/switches/c > atalyst-9500-series-switches/datasheet-c78-738978.html > > Nexus 7k supports MPLS with LDP while Nexus 9k supports MPLS but > with SR (IGP) or BGP-LU (no LDP support). > > -- > Łukasz Bromirski > CCIE R&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A > > From alejandroacostaalamo at gmail.com Thu Apr 19 18:29:58 2018 From: alejandroacostaalamo at gmail.com (Alejandro Acosta) Date: Thu, 19 Apr 2018 14:29:58 -0400 Subject: Fwd: [cooperation-wg] Massive IP blockings in Russia In-Reply-To: References: Message-ID: I guess this is already a big issue + this is going to be a problem for people attending the FIFA World Cup using information from the cloud (few people, no?) Ale, El 19/4/18 a las 1:36 p. m., Sandra Murphy escribió: > Of possible interest to this group. > > Forwarding at Alexander’s suggestion, who says he has already shared info in the NANOG facebook group "(with updated prefixlist)". > > —Sandy > >> Begin forwarded message: >> >> From: Alexander Isavnin >> Subject: [cooperation-wg] Massive IP blockings in Russia >> Date: April 17, 2018 at 1:36:33 PM EDT >> To: cooperation-wg at ripe.net >> >> Dear colleagues! >> >> I’m not pleased to inform you that RosComNadzor, a Russian Communication supervisory body, has started blocking huge ranges of IPs belonging to different cloud infrastructures, mostly Amazon and Google Cloud. >> Those ranges include: 13.52.0.0/14, 13.56.0.0/14, 18.184.0.0/15, 18.194.0.0/15, 18.196.0.0/15, 34.192.0.0/10, 34.240.0.0/13, 34.248.0.0/13, 35.156.0.0/14, 35.160.0.0/13, 35.176.0.0/15, 52.0.0.0/11, 52.192.0.0/11, 52.208.0.0/13, 52.28.0.0/15, 52.58.0.0/15, 54.144.0.0/12, 54.160.0.0/12, 54.228.0.0/15, 54.72.0.0/15, 54.88.0.0/16. >> >> Russian ISPs MUST fully block all traffic to such networks. The list is frequently updated and gets automatically propagated to ISP every once in a while, failure to block any address may result in 1500eur fine. >> The infrastructure listed above is being added to the blocklist under “counter-terrorist and counter-extremist” order of the General Prosecutor Office, #27-31-2015/Id4082-15, issued in 2015 and often used for blocking an arbitrary unwanted content. >> The real reason for such blocking is an attempt to cut access to Telegram messenger, which refused to provide end-to-end encryption keys to the Federal Security Service (previously known as KGB). This is a case similar to San-Bernardino shooter’s, where the FBI was denied access to the shooter’s iPhone, but courts in Russia have made completely opposite decision. >> Telegram’s infrastructure is being blocked by a different decision by RosKomNadzor, #2-1779/2018. >> Cloud infrastructures are being blocked for massive proxy and VPN hosting used to dodge messenger blocking. >> >> It is said, that more Apple and Google networks may be blocked soon for apps updates and push notifications delivery for Telegram. >> >> We hope to still have the global IP connectivity to keep you informed about how the situation develops. >> Do not be surprised if some of your services placed in cloud infrastructures will miss Russian customers. >> >> You can monitor the number of IP addresses, domains and URLs to be blocked in Russia at the https://2018.schors.spb.ru/ page (run by the famous ENOG community member Phil Kulin). >> Detailed information (also via API) is available at the https://reestr.rublacklist.net run by RosKomSvoboda civil society group. >> >> Kind regards, >> Alexander Isavnin >> >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From bryan at shout.net Thu Apr 19 18:38:22 2018 From: bryan at shout.net (Bryan Holloway) Date: Thu, 19 Apr 2018 13:38:22 -0500 Subject: RCN and IPv6 Message-ID: Curious if any RCN network guys or gals are on the list and can provide any idea as to when RCN plans on deploying IPv6? I make inquiries every six months or so, but I get the usual canned response that it's in the works, but no ETA. From Bryan at bryanfields.net Thu Apr 19 18:39:13 2018 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 19 Apr 2018 14:39:13 -0400 Subject: Fwd: [cooperation-wg] Massive IP blockings in Russia In-Reply-To: References: Message-ID: On 4/19/18 1:36 PM, Sandra Murphy wrote: > Russian ISPs MUST fully block all traffic to such networks. The list is > frequently updated and gets automatically propagated to ISP every once in a > while, failure to block any address may result in 1500eur fine. Per day? That's a cost of doing business. Can we donate to pay it somewhere? > The > infrastructure listed above is being added to the blocklist under > “counter-terrorist and counter-extremist” order of the General Prosecutor > Office, #27-31-2015/Id4082-15, issued in 2015 and often used for blocking > an arbitrary unwanted content. The real reason for such blocking is an > attempt to cut access to Telegram messenger, which refused to provide > end-to-end encryption keys to the Federal Security Service (previously > known as KGB). Necessity is the plea for every infringement of human liberty. It is the argument of tyrants; it is the creed of slaves. -- William Pitt -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From colton.conor at gmail.com Thu Apr 19 18:46:46 2018 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 19 Apr 2018 13:46:46 -0500 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: <003601d3d7f8$8f3cbce0$adb636a0$@gvtc.com> References: <003601d3d7f8$8f3cbce0$adb636a0$@gvtc.com> Message-ID: Yes, there are issues/concerns with using Huawei in the USA, but in the rest of the world they are the number 2 vendor. Also, $3500 for that box with lifetime support and warranty (their TAC is in Plano, Texas) vs $10,000 for an ACX5048 onetime plus at least $1500 a year for JTAC seems like a big difference! ACX has 48 ports vs 24 in the Huawei, but you have to licenses each one of the ports on the ACX making the total cost even higher. Sounds like your ACX cost more than you E7 that its feeding! On Thu, Apr 19, 2018 at 11:07 AM, Aaron Gould wrote: > Aren't there issues/concerns with Huawei ? > > I think we pay about $10k with discounts and about (4) 10 gig port license > to slow start our deployment of ACX5048's.... 10 gig east , 10 gig west , > dual 10's facing FTTH OLT (Calix E7) > > -Aaron > > > From aaron at heyaaron.com Thu Apr 19 18:54:50 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Thu, 19 Apr 2018 18:54:50 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <20180419142724.GB3500@gsp.org> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> Message-ID: You still have the same end result. Bad data. I could use a mail forwarding service or fake the record entirely. My VoIP provider probably won't cough up who owns the phone number without a warrant. Probably the same for HelloFax. And the only name verification that goes on at my domain registrar is validating my credit card. They don't seem to care if I put "John Smith" in for the whois name. But once again, they'll require a warrant before they cough up the data. The USPS doesn't seem to mind if mail comes in under "my child's" name who is under 16 and doesn't have any form of government ID yet...and might not even exist. So you still have the same end-result. Those determined to remain somewhat private will do so and that means some of your whois data is garbage. ...but I don't see it as a big problem. Some random site or IP is causing problems, so you try to nicely get in touch with them. Their whois is garbage. So block them. They'll figure it out quickly enough. Or contact their upstream. Their upstream probably knows who they are. Digital Ocean (for example) knows which IPs belong to my servers and they'll either reach out to me or knock me offline until I get things corrected. "dissident political movements in repressive countries" ...and there's my new band name. -A On Thu, Apr 19, 2018 at 7:29 AM Rich Kulawiec wrote: > On Sat, Apr 14, 2018 at 08:20:06PM +0000, Filip Hruska wrote: > > Scraping WHOIS systems for thousands domains at once using the WHOIS > > protocol is easy though. There are "WHOIS History" sites which scrape all > > domains and then publish the data along with the date of retrieval. > > Which would not be necessary if all WHOIS information was fully published > in text/XML/whatever form, available for immediate download/rsync to > everyone, and refreshed at intervals (say, once a day). This would > neatly undercut the business model for these sites and would ensure > that anyone who wants the information can get it efficiently. > > ---rsk > From bryan at shout.net Thu Apr 19 19:05:59 2018 From: bryan at shout.net (Bryan Holloway) Date: Thu, 19 Apr 2018 14:05:59 -0500 Subject: RCN and IPv6 In-Reply-To: References: Message-ID: <5def24ea-85b9-925e-8362-8a698e0eb3c5@shout.net> On 4/19/18 1:38 PM, Bryan Holloway wrote: > Curious if any RCN network guys or gals are on the list and can provide > any idea as to when RCN plans on deploying IPv6? > > I make inquiries every six months or so, but I get the usual canned > response that it's in the works, but no ETA. Clarification: An astute off-list responder made the distinction between peering and end-user ... I'm referring to the latter, in case it wasn't clear. Thanks! From colton.conor at gmail.com Thu Apr 19 19:14:48 2018 From: colton.conor at gmail.com (Colton Conor) Date: Thu, 19 Apr 2018 14:14:48 -0500 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: References: Message-ID: Ben, The Dell options intrigue me. First question is who do you talk to at Dell about their solutions as most sales guys just seem to know their laptop and server lines? How does Dell's pricing compare with Edge-Core. Considering most of the hardware is the same Broadcom chipset, what are the reasons you went with Dell over someone like Edge-Core or the other OEM's? I have looked into IPInfusion OcNOS and feature wise it looks nice, but by the time you pay IPInfusion OcNOS for the software and an OEM for the hardware the costs adds up to a Cisco/Juniper equalivent model. Dell seems interesting as I think they include an OS for free, but then you can load IPInfusion OcNOS or Cumulus or others onto it if that doesn't meet your need. You mentioned FTOS9. Doesn't Dell now have OS10 version? On Thu, Apr 19, 2018 at 8:28 AM, Ben Bartsch wrote: > I've been testing IPInfusion OcNOS running on Dell Z9100 and S4048. I've > run a couple of test cases using MPLS LDP signaled port based and VLAN > based VPWS (pseudowire / e-line / xconnect / Juniper CCC) and VPLS (e-lan) > over an OSPFv2 IGP. It's working well between Dell/IPI to Dell/IPI boxes. > We have had issues with the VPLS between Dell/IPI to Juniper/JunOS where > the circuit will show up on the Juniper and down on the Dell. If we clear > LDP session on the Dell, it comes back up right away. This seems to be > similar to what Aaron is seeing in his multi-vendor environment. The price > on the Dell hardware is really good. The features included with OcNOS are > much better than FTOS9. If you aren't partial to Dell, you can run OcNOS > on a variety of other whitebox switches, like EdgeCore. > > I haven't tested MP-BGP and L3VPN or BFD yet, but that is supposedly > supported in OcNOS as well. > > -ben > > On Wed, Apr 18, 2018 at 8:32 PM, Colton Conor > wrote: > >> What is your budget? >> >> I know on the low end many operators are using the >> Huawei S6720S-26Q-EI-24S-AC. You can get these new for $2500 to $3500, and >> the support all the features and port counts you requested. The also have >> a >> lifetime warranty that includes advanced replacement (10 days), TAC >> support, and software support all for free if you buy through official >> channels. It support MPLS, and also VXLAN. >> >> Extreme seems to have some good options, but I doubt they are that low >> cost. >> >> For Juniper you need to look at the ACX series which is expensive. Like >> the >> ACX5048 which list price is $40k not that anyone pays list, and that's >> before port licenses. The EX series does not have proper MPLS support. >> >> Cisco has mutliple options, but mainly the NCS based on your port count I >> think. Supposely the C3850 and C9500 now support MPLS? There is a new 16 >> port 10G version of the C9500. I haven't looked into Nexus switches. Does >> Nexus support full MPLS? >> >> HPE has some low cost options. In their FlexFabric and FlexNetwork lines >> that support MPLS in Comware V7. >> >> Who else are we missing? MPLS support really cuts down this list, but I >> agree its a critical feature for most service providers. >> >> >> >> >> On Wed, Apr 18, 2018 at 7:26 AM, Giuseppe Spanò - Datacast Srl < >> spano at datacast.it> wrote: >> >> > Hello, >> > >> > we're looking for some L3 switches to be used as distribution devices. >> > They should have all (at leaast 24) SFP+ ports 10G and at least a >> couple of >> > upstream ports 40G capable, but what is most important, they should be >> able >> > to run MPLS, EoMPLS and VPLS. Is there any device you would suggest us? >> We >> > where thinking about NEXUS but I'm sure there are also others, even if >> it >> > is not so easy to find them on the Internet. >> > >> > Thank you in advance for your help . >> > >> > Giuseppe Spanò >> > Datacast Srl >> > >> > > From yuri at yurisk.info Thu Apr 19 19:33:03 2018 From: yuri at yurisk.info (Yuri Slobodyanyuk) Date: Thu, 19 Apr 2018 22:33:03 +0300 Subject: Fwd: [cooperation-wg] Massive IP blockings in Russia In-Reply-To: References: Message-ID: Thanks for sharing, Note of caution - there is a mess going on with this blocking so if some IP range/domain is not in any list it doesn't necessary mean it is not blocked. Lists are created/updated pretty sporadically (e.g. the list does not say so but there are reports of blocked DigitalOCean nets 167.99.0.0/16 & 206.189.0.0/16 https://www.securitylab.ru/news/492749.php) . My 2 cents - once Russian Internet authorities get tired of chasing their own tail (any sysadmin knows you can't block ain't nothing by IP addresses today) they will stop this fruitless effort (but of course they cannot do it right now and lose the face) and things will be back to normal. On Thu, Apr 19, 2018 at 9:39 PM, Bryan Fields wrote: > On 4/19/18 1:36 PM, Sandra Murphy wrote: > > > Russian ISPs MUST fully block all traffic to such networks. The list is > > frequently updated and gets automatically propagated to ISP every once > in a > > while, failure to block any address may result in 1500eur fine. > > Per day? That's a cost of doing business. Can we donate to pay it > somewhere? > > > The > > infrastructure listed above is being added to the blocklist under > > “counter-terrorist and counter-extremist” order of the General Prosecutor > > Office, #27-31-2015/Id4082-15, issued in 2015 and often used for blocking > > an arbitrary unwanted content. The real reason for such blocking is an > > attempt to cut access to Telegram messenger, which refused to provide > > end-to-end encryption keys to the Federal Security Service (previously > > known as KGB). > > Necessity is the plea for every infringement of human liberty. > It is the argument of tyrants; it is the creed of slaves. > -- William Pitt > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net > -- Taking challenges one by one. http://yurisk.info From Nikos.Leontsinis at eu.equinix.com Wed Apr 18 13:12:29 2018 From: Nikos.Leontsinis at eu.equinix.com (Nikos Leontsinis) Date: Wed, 18 Apr 2018 13:12:29 +0000 Subject: Attacks on BGP Routing Ranges In-Reply-To: <1524047875360.80045@quadranet.com> References: <1524047875360.80045@quadranet.com> Message-ID: You are not supposed to announce that range anyway as you shouldn't be announcing your infrastructure range for your protection. Ask your upstream providers not to expose that range too. There are many ways around that selective redistribution or they can just protect that range. How they do it is none of your concern and there are many ways of achieving this. In my view this should be added on a best practice rfc. I am assuming that you are using that block just for your bgp session. /nikos -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ryan Hamel Sent: Wednesday, April 18, 2018 11:38 AM To: nanog at nanog.org Subject: Attacks on BGP Routing Ranges Hello, I wanted to poll everyones thoughts on how to deal with attacks directly on BGP peering ranges (/30's, /127's). I know that sending an RTBH for our side of the upstream routing range does not resolve the issue, and it would actually make things worse by blackholing all inbound traffic on the carrier I send the null to. What are my options for carriers that are not willing to help investigate the situation or write up a firewall rule to mitigate it on the circuit? I am not a fan of naming and shaming because it has unintended consequences. Thanks in advance for everyone's suggestions. Ryan Hamel This email is from Equinix (EMEA) B.V. or one of its associated companies in the territory from where this email has been sent. This email, and any files transmitted with it, contains information which is confidential, is solely for the use of the intended recipient and may be legally privileged. If you have received this email in error, please notify the sender and delete this email immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, 1096 HA Amsterdam, The Netherlands. Registered in The Netherlands No. 57577889. From d.nostra at gmail.com Wed Apr 18 17:41:39 2018 From: d.nostra at gmail.com (Michel de Nostredame) Date: Wed, 18 Apr 2018 10:41:39 -0700 Subject: Juniper Config Commit causes Cisco Etherchannels to go into err-disable state In-Reply-To: References: <9578293AE169674F9A048B2BC9A081B402A8742B4B@MUNPRDMBXA1.medline.com> Message-ID: Not sure exactly what your environment looks like, but we encountered something similar when trunking Cisco-DELL and Cisco-Juniper switches. We run RSTP on DELL and Juniper switches, but RPVST+ on Cisco. In the beginning we just allow those VLANS we need between Cisco-DELL/Juniper switches, then encountered unexpected err-disable / link drop things. Later we figured Cisco always carry default VLAN (VLAN-1) untagged through trunk ports. Hence we manually "explicitly" add/allow Native-VLAN-1 (untagged) on all trunk ports in all switches. Problem solved. On Fri, Apr 6, 2018 at 11:59 AM, Mark Milhollan wrote: > Sounds like the Juniper is leaking a "default" BPDU as it resets the > various internal chip configurations, which the Cisco receives thus > triggering the err-disable. > > > /mark -- -- Michel~ From baldur.norddahl at gmail.com Thu Apr 19 19:45:16 2018 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 19 Apr 2018 19:45:16 +0000 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: References: Message-ID: The ZTE 5960 with 48x SFP+ and 4x QSFP28 (40G and 100G capable) will do it within the budget listed. We use it for MPLS and VPLS. Regards Baldur Den tor. 19. apr. 2018 18.17 skrev Giuseppe Spanò - Datacast Srl < spano at datacast.it>: > Thank you very much to everyone. > > The budget is around 3000-5000 $ each, possibly. > There are many devices that could match our needs but as usual the dark > side of this market is the platforms compatibility. We deployed many > Mikrotik and Ericsson devices, hope they will "match" with a Cisco or > Juniper or Huawey device with regards to MPLS, EoMPLS, VPLS etc... > > Anyway your kind help is really very appreciated, we'll decide for one > and will test it, no way out I think. > > Giuseppe > > Il 19/04/18 03:32, Colton Conor ha scritto: > > What is your budget? > > > > I know on the low end many operators are using the > > Huawei S6720S-26Q-EI-24S-AC. You can get these new for $2500 to $3500, > > and the support all the features and port counts you requested. The also > > have a lifetime warranty that includes advanced replacement (10 days), > > TAC support, and software support all for free if you buy through > > official channels. It support MPLS, and also VXLAN. > > > > Extreme seems to have some good options, but I doubt they are that low > cost. > > > > For Juniper you need to look at the ACX series which is expensive. Like > > the ACX5048 which list price is $40k not that anyone pays list, and > > that's before port licenses. The EX series does not have proper MPLS > > support. > > > > Cisco has mutliple options, but mainly the NCS based on your port count > > I think. Supposely the C3850 and C9500 now support MPLS? There is a new > > 16 port 10G version of the C9500. I haven't looked into Nexus switches. > > Does Nexus support full MPLS? > > > > HPE has some low cost options. In their FlexFabric and FlexNetwork lines > > that support MPLS in Comware V7. > > > > Who else are we missing? MPLS support really cuts down this list, but I > > agree its a critical feature for most service providers. > > > > > > > > > > On Wed, Apr 18, 2018 at 7:26 AM, Giuseppe Spanò - Datacast Srl > > > wrote: > > > > Hello, > > > > we're looking for some L3 switches to be used as distribution > > devices. They should have all (at leaast 24) SFP+ ports 10G and at > > least a couple of upstream ports 40G capable, but what is most > > important, they should be able to run MPLS, EoMPLS and VPLS. Is > > there any device you would suggest us? We where thinking about NEXUS > > but I'm sure there are also others, even if it is not so easy to > > find them on the Internet. > > > > Thank you in advance for your help . > > > > Giuseppe Spanò > > Datacast Srl > > > > > From bzs at theworld.com Thu Apr 19 21:31:58 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 19 Apr 2018 17:31:58 -0400 Subject: Is WHOIS going to go away? In-Reply-To: <20180419142414.GA3500@gsp.org> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <20180414171410.GA20737@gsp.org> <20180419142414.GA3500@gsp.org> Message-ID: <23257.2766.532302.191614@gargle.gargle.HOWL> I just want to add my voice to basically the same sentiment (way below...) With all the data breaches it's almost become easier to list companies who haven't had a massive data breach lately. And once someone walks off with that db it's out there forever tho admittedly still a little more difficult to access than a mere whois query. But most registrars offer a privacy option so whois only returns the registrar's contact info. That of course won't help with mass data breaches. And there are third-party options. All GDPR and similar is likely to do is change exactly who has access to this information and how, and how much it will cost. That might be an improvement for some, and it might offer a false sense of security for many. How many will thereafter willingly pay the $5/month or whatever it is for "privacy" if they believe their data is somehow protected by law? Far fewer I would guess (yes many registrars provide this free but will they after May 25th?) I'll reiterate my suggestion I've been pushing for a while now: Put the WHOIS accessible information into the DNS, possibly as a new RR but that's optional. That would put it completely under the domain owner's control. It doesn't solve the problem of data breaches, and I'd include lawful mass access (i.e., selling your info), but at least it's realistic and easy enough to implement -- just convert any WHOIS query into an appropriate DNS query. But it does separate the WHOIS function from normal customer data management. ICANN and its registries and registrars can then proceed to practice standard customer information management policies without also having to try to layer a WHOIS policy on the same data. On April 19, 2018 at 10:24 rsk at gsp.org (Rich Kulawiec) wrote: > On Sat, Apr 14, 2018 at 05:29:35PM +0000, Aaron C. de Bruyn via NANOG wrote: > > So why are you proposing that I can't run my *personal* "I strongly > > believe in {insert emotionally-charged issue} site" without letting psychos > > know exactly where I live? > > A PO box might suffice. There are also mail forwarding (and phone > forwarding) services that serve the purpose. Having encountered exactly > these sorts of psychos, this might be a good idea if you think it's a > threat you may have to face. > > (Although let me note that your address is likely available anyway through > some deliberate-public database or through one that's been hacked and > subsequently leaked. Or via someone you know who "checked in" with > a geolocation app while visiting. Or via someone who handed it over to > a third party because they were shipping you something. Or...) > > Let me suggest that a better choice for these situations is not to > register a domain *at all*. Consider: doing so creates a record at your > registrar that has information-of-interest about you. All that stands > between a psycho and that information is a security breach, a dataloss > incident, or -- maybe -- a hundred bucks in an envelope (old style) > or a cryptocurrency transfer (new style). Maaaaybe it would be better > not to create that record at all. > > That's why I've always recommended (for example) that dissident political > movements in repressive countries avoid registering domains: any dictator > worthy of the title will easily acquire the real registration details, > whether they're held in-country or not. > > ---rsk -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Thu Apr 19 21:57:48 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 19 Apr 2018 17:57:48 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> Message-ID: <23257.4316.455617.983247@gargle.gargle.HOWL> One of the memes driving this WHOIS change is the old idea of "starving the beast". People involved in policy discussions complain that "spammers" -- many only marginally fit that term other than by the strictest interpretation -- use the public WHOIS data to contact domain owners. I've countered that 20+ years experience trying to "starve the beast" by trying to deny them access to email and other casual contact info has proven the approach to be useless. Choosing the privacy options on your domain registration is probably just as, if not more, effective. Another argument against this whole idea is that in most countries one is required by law to provide valid contact information if they are doing business with the general public. That would include soliciting donations etc. And that's essentially why domains exist, organizational contact. This trend towards "vanity" domains is relatively recent and really the only reason one can even claim there is a problem. Granted there's that gray area of dissident political movements etc. but their full time job is protecting their identity. I doubt Microsoft or General Motors are excited to see that their domain registration contact information will soon be protected by law. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Fri Apr 20 00:19:36 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 19 Apr 2018 20:19:36 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> Message-ID: <23257.12824.250276.763926@gargle.gargle.HOWL> Inline... On April 19, 2018 at 22:24 farzi at gatech.edu (Badiei, Farzaneh) wrote: > “Granted there's > that gray area of dissident political movements etc. but their full > time job is protecting their identity.” > > > > You think? The median number of domain name registration that used privacy > proxy service in the Middle East is 24%. See the DNS Market study: https:// > www.icann.org/en/system/files/files/meac-dns-study-26feb16-en.pdf > > > > Now lets look at the distribution of that number: “Rates of privacy proxy > registrations varied across countries in the region, with the lowest rates seen > in Iran (7%) and Turkey (12%), and the highest rates in Syria (32%), Algeria > and Egypt (31% each).” I guess some people who share your band name in those > countries with the lowest percentage of privacy proxy service might not really > know how they can use privacy proxy services ! Lets just keep their personal > information public until they find out how and why their house has been raided. So you think restricting WHOIS access will protect dissidents from abusive governments? Of all the rationalizations that one seems particularly weak. Can we possibly find a lower common denominator on which to base global internet policy? And is anyone going to assure them that new WHOIS policies will protect them? Even allow them (or their surviving kin) to sue etc if it fails? Where is the warranty here? I think dissidents who might, if identified as domain owners, become targets of government reprisal need a better plan than some new WHOIS policies. > > Also I don’t really understand why people keep saying “whois is going away” and > “whois is going dark” > > > > It is not. Personal information in the database should be made private. WHOIS > contains more than personal information. You are the technical people, you > know better than me. It should contain exactly whatever contact information the registrant provides for public disclosure, including a privacy option. That's commonly available right now. This is why I suggested putting the WHOIS information into the DNS under each domain owner's control. > Thanks for bringing up the grey area anyway. Not many consider that in the > discussions. But it’s not only dissidents. It’s also journalists and especially > female journalists that work on issues that some might not like. Also sometimes > you don’t even know you have to hide your identity because you don’t think you > are doing anything against the law, the problem is that we don’t have the rule > of law everywhere in the world. And I'll say no one is going to fix that by making WHOIS info less public. They need to use proxies or privatization options (or overthrow their governments but easier said than done.) Even that doesn't protect them from, for example, govt authorities just demanding the information from registrars within their jurisdiction (e.g., ccTLDs), or a sympathetic jurisdiction. Or hosting or cloud companies etc. Any link in the chain. As I said, if one is fearful of reprisal they need to design their own privacy or hire someone who can provide it. I know there are hosting companies who specialize in political dissidents and similar and have worked through issues such as jurisdiction. I can understand the feelgood appeal of all this but I think the problem is way beyond crippling WHOIS for some people. (end of my reply) > > > > > > Best > > > > Dr. Farzaneh Badiei > Research Associate, School of Public Policy > Executive Director, Internet Governance Project > > > > From: bzs at theworld.com > Sent: Thursday, April 19, 2018 5:58 PM > To: Aaron C. de Bruyn > Cc: nanog at nanog.org; Rich Kulawiec > Subject: Re: Is WHOIS going to go away? > > > > > One of the memes driving this WHOIS change is the old idea of > "starving the beast". > > People involved in policy discussions complain that "spammers" -- many > only marginally fit that term other than by the strictest > interpretation -- use the public WHOIS data to contact domain owners. > > I've countered that 20+ years experience trying to "starve the beast" > by trying to deny them access to email and other casual contact info > has proven the approach to be useless. > > Choosing the privacy options on your domain registration is probably > just as, if not more, effective. > > Another argument against this whole idea is that in most countries one > is required by law to provide valid contact information if they are > doing business with the general public. That would include soliciting > donations etc. > > And that's essentially why domains exist, organizational contact. > > This trend towards "vanity" domains is relatively recent and really > the only reason one can even claim there is a problem. > I doubt Microsoft or General Motors are excited to see that their > domain registration contact information will soon be protected by law. > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo* > > > -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From johnl at iecc.com Fri Apr 20 02:43:09 2018 From: johnl at iecc.com (John Levine) Date: 19 Apr 2018 22:43:09 -0400 Subject: Is WHOIS going to go away? In-Reply-To: <23257.12824.250276.763926@gargle.gargle.HOWL> Message-ID: <20180420024309.DC0F7254665A@ary.qy> In article <23257.12824.250276.763926 at gargle.gargle.HOWL> you write: >So you think restricting WHOIS access will protect dissidents from >abusive governments? > >Of all the rationalizations that one seems particularly weak. Oh, you're missing the point. This is a meme that's been floating around in academia for a decade: the brave dissident who somehow has managed to find web hosting, e-mail, broadband, and mobile phone service but for whom nothing stands between her and certain death but the proxy whois on her vanity domain. If someone makes this argument you can be 100% sure he's parroting something he heard somewhere and has no idea how the Internet actually works. R's, John From aaron at heyaaron.com Fri Apr 20 02:58:13 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 20 Apr 2018 02:58:13 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <23257.12824.250276.763926@gargle.gargle.HOWL> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> Message-ID: On Thu, Apr 19, 2018 at 5:20 PM wrote: > So you think restricting WHOIS access will protect dissidents from > abusive governments? > Every government has subpoena power. Some of them even have the power to beat people with a rubber hose in the back room until they get the information they want. Being able to put bogus data into whois won't prevent the government from finding you, but it may prevent crazies from showing up at my house, or even knowing that I run a particular site. -A From bzs at theworld.com Fri Apr 20 03:31:58 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 19 Apr 2018 23:31:58 -0400 Subject: Is WHOIS going to go away? In-Reply-To: <20180420024309.DC0F7254665A@ary.qy> References: <23257.12824.250276.763926@gargle.gargle.HOWL> <20180420024309.DC0F7254665A@ary.qy> Message-ID: <23257.24366.813317.921104@gargle.gargle.HOWL> On April 19, 2018 at 22:43 johnl at iecc.com (John Levine) wrote: > In article <23257.12824.250276.763926 at gargle.gargle.HOWL> you write: > >So you think restricting WHOIS access will protect dissidents from > >abusive governments? > > > >Of all the rationalizations that one seems particularly weak. > > Oh, you're missing the point. This is a meme that's been floating > around in academia for a decade: the brave dissident who somehow has > managed to find web hosting, e-mail, broadband, and mobile phone > service but for whom nothing stands between her and certain death but > the proxy whois on her vanity domain. > > If someone makes this argument you can be 100% sure he's parroting > something he heard somewhere and has no idea how the Internet actually > works. +1 I'm more sympathetic to for example abused women who I can see have little wherewithal to figure out every way to hide their (new) contact information. Unlike political dissidents they didn't volunteer for their situation. Nonetheless I don't think crippling the entire WHOIS system for everyone for cases such as this is a reasonable approach. As they say hard cases make bad law. Educate people, maybe in particular domestic abuse lawyers and counselors, about better alternatives such as clicking the little privacy option box on their registrar's domain registration form. There, that wasn't very hard, but it's only a tiny part of their problem anyhow, unfortunately. Maybe we need to get back to the GDPR which is actually driving this WHOIS discussion. For example: Facebook to exclude 1.5 billion users from GDPR privacy protections https://www.engadget.com/2018/04/19/facebook-exclude-1-5-billion-users-gdpr-privacy-protection/ or http://tinyurl.com/y9abrw37 > R's, > John -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Fri Apr 20 03:44:10 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 19 Apr 2018 23:44:10 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> Message-ID: <23257.25098.986869.224276@gargle.gargle.HOWL> On April 20, 2018 at 02:58 aaron at heyaaron.com (Aaron C. de Bruyn) wrote: > On Thu, Apr 19, 2018 at 5:20 PM wrote: > > So you think restricting WHOIS access will protect dissidents from > abusive governments? > > > Every government has subpoena power.  Some of them even have the power to beat > people with a rubber hose in the back room until they get the information they > want. > > Being able to put bogus data into whois won't prevent the government from > finding you, but it may prevent crazies from showing up at my house, or even > knowing that I run a particular site. That's part of the contradiction in all this vis a vis ICANN. ICANN has had a push for years to improve the accuracy (and I assume precision) of domain registration information and therefore WHOIS. I know because I've sat in on any number of ICANN meetings with slides and talks about how frequently domains are registered to "Donald Duck" or similar. The numbers vary from report to report but I remember numbers like over 25% of registrations seemed to be prima facie bogus like that. So they developed that letter you get if you have a domain registered which says check your domain reg information and fix it because if it's not accurate (and precise) you risk losing your domain. And required registrars to send you that letter periodically typically around 30-60 days before renewal. Which means by pushing on the problem of domain name registration information accuracy they also made it much more difficult for people who may've had a good reason to not enter accurate (and/or precise) information. But we also got privacy options from registrars and third-parties. So the net result maybe isn't all that terrible unless you have a good reason to hide your information even from your registrar (and ICANN), checking a privacy option won't accomplish that, they still have your info they're just not revealing it via WHOIS. ANYHOW this is too long and boring already, I'm not sure I can even stand to proofread it, but it's all a rather tangled story which probably amounts to: The road to hell is paved with good intentions. And some pretty bad intentions also. > > -A -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From oscar.vives at gmail.com Fri Apr 20 10:03:37 2018 From: oscar.vives at gmail.com (Tei) Date: Fri, 20 Apr 2018 12:03:37 +0200 Subject: Is WHOIS going to go away? In-Reply-To: <23257.25098.986869.224276@gargle.gargle.HOWL> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> Message-ID: Maybe a good balance for whois is to include organization information so I know where a website is hosted, but not personal information, so I can't show in their house and steal their dog. I feel uneasy about having my phone available to literally everyone on the internet. -- -- ℱin del ℳensaje. From cdel at firsthand.net Fri Apr 20 10:50:11 2018 From: cdel at firsthand.net (Christian de Larrinaga) Date: Fri, 20 Apr 2018 11:50:11 +0100 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> Message-ID: <5AD9C5E3.8060005@firsthand.net> Tei wrote: > > Maybe a good balance for whois is to include organization information > so I know where a website is hosted, but not personal information, so > I can't show in their house and steal their dog. > > I feel uneasy about having my phone available to literally everyone on > the internet. > > Technical contact information is supposed to be available for technical purposes. Not that that purpose has been reliable as time has gone by. Has that (required) purpose just flown past the policy makers? Christian From colton.conor at gmail.com Fri Apr 20 12:26:20 2018 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 20 Apr 2018 07:26:20 -0500 Subject: China Showdown Huawei vs ZTE Message-ID: Of the two large Chinese Vendors, which has the better network operating system? Huawei is much larger that ZTE is my understanding, but larger does not always mean better. Both of these manufactures have switches and routers. I doubt we will use their routing products anytime soon, but the switching products with MPLS are what we are exploring. Price wise both of these vendors seem to have 10G MPLS capable switches that are a 1/4 of the price of a Cisco or Juniper wants to charge. On the Huawei side looks like the S6720 is a fit. On the ZTE side, it looks like the ZXR10 5960 Series is a fit. Has anyone had experience with either of these two switches? How do they compare? Also, for each independent brand, is their switching network operating system the same as their routing network operating system that their routers run? From josh at kyneticwifi.com Fri Apr 20 12:34:15 2018 From: josh at kyneticwifi.com (Josh Reynolds) Date: Fri, 20 Apr 2018 12:34:15 +0000 Subject: China Showdown Huawei vs ZTE In-Reply-To: References: Message-ID: Why not just go the whitebox route and pick your NOS of choice? Far cheaper, and far more flexible. On Fri, Apr 20, 2018, 7:28 AM Colton Conor wrote: > Of the two large Chinese Vendors, which has the better network operating > system? Huawei is much larger that ZTE is my understanding, but larger does > not always mean better. > > Both of these manufactures have switches and routers. I doubt we will use > their routing products anytime soon, but the switching products with MPLS > are what we are exploring. Price wise both of these vendors seem to have > 10G MPLS capable switches that are a 1/4 of the price of a Cisco or Juniper > wants to charge. > > On the Huawei side looks like the S6720 is a fit. > On the ZTE side, it looks like the ZXR10 5960 Series is a fit. > > Has anyone had experience with either of these two switches? How do they > compare? > > Also, for each independent brand, is their switching network operating > system the same as their routing network operating system that their > routers run? > From ops.lists at gmail.com Fri Apr 20 12:34:53 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 20 Apr 2018 18:04:53 +0530 Subject: China Showdown Huawei vs ZTE In-Reply-To: References: Message-ID: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> Ah. ZTE is in a spot of trouble right about now. http://www.scmp.com/tech/article/2142557/zte-calls-us-government-ban-extremely-unfair-vows-fight-its-rights On 20/04/18, 5:58 PM, "NANOG on behalf of Colton Conor" wrote: Of the two large Chinese Vendors, which has the better network operating system? Huawei is much larger that ZTE is my understanding, but larger does not always mean better. Both of these manufactures have switches and routers. I doubt we will use their routing products anytime soon, but the switching products with MPLS are what we are exploring. Price wise both of these vendors seem to have 10G MPLS capable switches that are a 1/4 of the price of a Cisco or Juniper wants to charge. On the Huawei side looks like the S6720 is a fit. On the ZTE side, it looks like the ZXR10 5960 Series is a fit. Has anyone had experience with either of these two switches? How do they compare? Also, for each independent brand, is their switching network operating system the same as their routing network operating system that their routers run? From colton.conor at gmail.com Fri Apr 20 12:46:10 2018 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 20 Apr 2018 07:46:10 -0500 Subject: China Showdown Huawei vs ZTE In-Reply-To: References: Message-ID: Josh, I like the whitebox route, but I can't find anything that will come close price wise. Example, Huawei S6720 with 24 10G ports, 2 40G ports, and full MPLS operating system from Huawei is $3500 out the door with a lifetime warranty. I can't even find a whitebox hardware, not even accounting for the OS, that is close to that price. Most 48 Port 10G with 6 40G uplinks (so double this huawei unit) are in the $5k range, and then you have to buy an operating system costing a couple more grand. Choices are limited on whitebox operating systems that support MPLS. There might be some FibeStore models that come close to this price, but FS.com is a Chinese company too, so that's no better than ZTE or Huawei. On Fri, Apr 20, 2018 at 7:34 AM, Josh Reynolds wrote: > Why not just go the whitebox route and pick your NOS of choice? > > Far cheaper, and far more flexible. > > On Fri, Apr 20, 2018, 7:28 AM Colton Conor wrote: > >> Of the two large Chinese Vendors, which has the better network operating >> system? Huawei is much larger that ZTE is my understanding, but larger >> does >> not always mean better. >> >> Both of these manufactures have switches and routers. I doubt we will use >> their routing products anytime soon, but the switching products with MPLS >> are what we are exploring. Price wise both of these vendors seem to have >> 10G MPLS capable switches that are a 1/4 of the price of a Cisco or >> Juniper >> wants to charge. >> >> On the Huawei side looks like the S6720 is a fit. >> On the ZTE side, it looks like the ZXR10 5960 Series is a fit. >> >> Has anyone had experience with either of these two switches? How do they >> compare? >> >> Also, for each independent brand, is their switching network operating >> system the same as their routing network operating system that their >> routers run? >> > From Curtis.Starnes at granburyisd.org Fri Apr 20 12:56:39 2018 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Fri, 20 Apr 2018 12:56:39 +0000 Subject: China Showdown Huawei vs ZTE In-Reply-To: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> References: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> Message-ID: Same for Huawei. https://www.theverge.com/2018/3/26/17164226/fcc-proposal-huawei-zte-us-networks-national-security https://www.forbes.com/sites/jeanbaptiste/2018/04/19/analyst-chinas-huawei-to-quit-u-s-market/#194f570211cb https://www.nytimes.com/2018/04/17/technology/huawei-trade-war.html I don't think I would recommend either in todays political climate..... -----Original Message----- From: NANOG On Behalf Of Suresh Ramasubramanian Sent: Friday, April 20, 2018 7:35 AM To: Colton Conor ; NANOG Subject: Re: China Showdown Huawei vs ZTE Ah. ZTE is in a spot of trouble right about now. http://www.scmp.com/tech/article/2142557/zte-calls-us-government-ban-extremely-unfair-vows-fight-its-rights On 20/04/18, 5:58 PM, "NANOG on behalf of Colton Conor" wrote: Of the two large Chinese Vendors, which has the better network operating system? Huawei is much larger that ZTE is my understanding, but larger does not always mean better. Both of these manufactures have switches and routers. I doubt we will use their routing products anytime soon, but the switching products with MPLS are what we are exploring. Price wise both of these vendors seem to have 10G MPLS capable switches that are a 1/4 of the price of a Cisco or Juniper wants to charge. On the Huawei side looks like the S6720 is a fit. On the ZTE side, it looks like the ZXR10 5960 Series is a fit. Has anyone had experience with either of these two switches? How do they compare? Also, for each independent brand, is their switching network operating system the same as their routing network operating system that their routers run? From colton.conor at gmail.com Fri Apr 20 13:44:32 2018 From: colton.conor at gmail.com (Colton Conor) Date: Fri, 20 Apr 2018 08:44:32 -0500 Subject: China Showdown Huawei vs ZTE In-Reply-To: References: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> Message-ID: Yes looks like they are both under pressure. I feel bad for the USA based employees. I know Huawei has quite a few in Plano, Texas. With both ZTE and Huawei out of the picture for USA operators, who is the low cost leader in this space then? On Fri, Apr 20, 2018 at 7:56 AM, STARNES, CURTIS < Curtis.Starnes at granburyisd.org> wrote: > Same for Huawei. > https://www.theverge.com/2018/3/26/17164226/fcc-proposal- > huawei-zte-us-networks-national-security > https://www.forbes.com/sites/jeanbaptiste/2018/04/19/ > analyst-chinas-huawei-to-quit-u-s-market/#194f570211cb > https://www.nytimes.com/2018/04/17/technology/huawei-trade-war.html > > I don't think I would recommend either in todays political climate..... > > -----Original Message----- > From: NANOG On Behalf Of Suresh Ramasubramanian > Sent: Friday, April 20, 2018 7:35 AM > To: Colton Conor ; NANOG > Subject: Re: China Showdown Huawei vs ZTE > > Ah. ZTE is in a spot of trouble right about now. > > http://www.scmp.com/tech/article/2142557/zte-calls-us- > government-ban-extremely-unfair-vows-fight-its-rights > > On 20/04/18, 5:58 PM, "NANOG on behalf of Colton Conor" < > nanog-bounces at nanog.org on behalf of colton.conor at gmail.com> wrote: > > Of the two large Chinese Vendors, which has the better network > operating > system? Huawei is much larger that ZTE is my understanding, but larger > does > not always mean better. > > Both of these manufactures have switches and routers. I doubt we will > use > their routing products anytime soon, but the switching products with > MPLS > are what we are exploring. Price wise both of these vendors seem to > have > 10G MPLS capable switches that are a 1/4 of the price of a Cisco or > Juniper > wants to charge. > > On the Huawei side looks like the S6720 is a fit. > On the ZTE side, it looks like the ZXR10 5960 Series is a fit. > > Has anyone had experience with either of these two switches? How do > they > compare? > > Also, for each independent brand, is their switching network operating > system the same as their routing network operating system that their > routers run? > > > > From aaron1 at gvtc.com Fri Apr 20 14:59:03 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Fri, 20 Apr 2018 09:59:03 -0500 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: References: <003601d3d7f8$8f3cbce0$adb636a0$@gvtc.com> Message-ID: <000601d3d8b8$1f881370$5e983a50$@gvtc.com> Thanks Colton, Since I live in the US, and work for a boss that’s nervous (concerned) about those things, then I comply. I remember mentioning Huawei as an option recently in a meeting and the boss and a few other fellow engineers were nervous and resistant to it. I tend to feel the same. I see you started a thread on comparing those 2 (zte and Huawei) … and was immediately met with cautionary/warning statements about these some things... from Suresh and Curtis. So I wonder if because of all this, are ZTE and Huawei sales being adversely affected in the US? …it would seem so, but thought I’d ask y’all. Google - China Showdown Huawei vs ZTE http://seclists.org/nanog/2018/Apr/293 - Aaron From michael at wi-fiber.io Fri Apr 20 16:08:39 2018 From: michael at wi-fiber.io (Michael Crapse) Date: Fri, 20 Apr 2018 10:08:39 -0600 Subject: Suggestion for Layer 3, all SFP+ switches In-Reply-To: <000601d3d8b8$1f881370$5e983a50$@gvtc.com> References: <003601d3d7f8$8f3cbce0$adb636a0$@gvtc.com> <000601d3d8b8$1f881370$5e983a50$@gvtc.com> Message-ID: Well, if the US government spies on everyone using exported cisco hardware, why wouldn't the PRC do the same? On 20 April 2018 at 08:59, Aaron Gould wrote: > Thanks Colton, Since I live in the US, and work for a boss that’s nervous > (concerned) about those things, then I comply. I remember mentioning > Huawei as an option recently in a meeting and the boss and a few other > fellow engineers were nervous and resistant to it. I tend to feel the same. > > > > I see you started a thread on comparing those 2 (zte and Huawei) … and was > immediately met with cautionary/warning statements about these some > things... from Suresh and Curtis. > > So I wonder if because of all this, are ZTE and Huawei sales being > adversely affected in the US? …it would seem so, but thought I’d ask y’all. > > Google - China Showdown Huawei vs ZTE > > http://seclists.org/nanog/2018/Apr/293 > > - Aaron > > > > From cscora at apnic.net Fri Apr 20 18:03:07 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Apr 2018 04:03:07 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180420180307.54FDA102FF@thyme.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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. 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 21 Apr, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 696141 Prefixes after maximum aggregation (per Origin AS): 268430 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 335330 Total ASes present in the Internet Routing Table: 60451 Prefixes per ASN: 11.52 Origin-only ASes present in the Internet Routing Table: 52213 Origin ASes announcing only one prefix: 22858 Transit ASes present in the Internet Routing Table: 8238 Transit-only ASes present in the Internet Routing Table: 268 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 34 Max AS path prepend of ASN ( 30873) 32 Prefixes from unregistered ASNs in the Routing Table: 49 Number of instances of unregistered ASNs: 49 Number of 32-bit ASNs allocated by the RIRs: 22275 Number of 32-bit ASNs visible in the Routing Table: 17911 Prefixes from 32-bit ASNs in the Routing Table: 74601 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 340 Number of addresses announced to Internet: 2863051010 Equivalent to 170 /8s, 166 /16s and 177 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 231650 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 190615 Total APNIC prefixes after maximum aggregation: 54054 APNIC Deaggregation factor: 3.53 Prefixes being announced from the APNIC address blocks: 189511 Unique aggregates announced from the APNIC address blocks: 77395 APNIC Region origin ASes present in the Internet Routing Table: 8729 APNIC Prefixes per ASN: 21.71 APNIC Region origin ASes announcing only one prefix: 2431 APNIC Region transit ASes present in the Internet Routing Table: 1311 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3687 Number of APNIC addresses announced to Internet: 767197698 Equivalent to 45 /8s, 186 /16s and 130 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 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: 207023 Total ARIN prefixes after maximum aggregation: 98996 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 207967 Unique aggregates announced from the ARIN address blocks: 98338 ARIN Region origin ASes present in the Internet Routing Table: 18149 ARIN Prefixes per ASN: 11.46 ARIN Region origin ASes announcing only one prefix: 6715 ARIN Region transit ASes present in the Internet Routing Table: 1792 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 24 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2336 Number of ARIN addresses announced to Internet: 1109260960 Equivalent to 66 /8s, 29 /16s and 250 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 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: 189988 Total RIPE prefixes after maximum aggregation: 91532 RIPE Deaggregation factor: 2.08 Prefixes being announced from the RIPE address blocks: 185878 Unique aggregates announced from the RIPE address blocks: 110829 RIPE Region origin ASes present in the Internet Routing Table: 25117 RIPE Prefixes per ASN: 7.40 RIPE Region origin ASes announcing only one prefix: 11405 RIPE Region transit ASes present in the Internet Routing Table: 3505 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 34 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6911 Number of RIPE addresses announced to Internet: 715628160 Equivalent to 42 /8s, 167 /16s and 158 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 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: 89797 Total LACNIC prefixes after maximum aggregation: 19767 LACNIC Deaggregation factor: 4.54 Prefixes being announced from the LACNIC address blocks: 91186 Unique aggregates announced from the LACNIC address blocks: 40836 LACNIC Region origin ASes present in the Internet Routing Table: 7029 LACNIC Prefixes per ASN: 12.97 LACNIC Region origin ASes announcing only one prefix: 1934 LACNIC Region transit ASes present in the Internet Routing Table: 1304 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4569 Number of LACNIC addresses announced to Internet: 172626400 Equivalent to 10 /8s, 74 /16s and 17 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 18667 Total AfriNIC prefixes after maximum aggregation: 4036 AfriNIC Deaggregation factor: 4.63 Prefixes being announced from the AfriNIC address blocks: 21259 Unique aggregates announced from the AfriNIC address blocks: 7635 AfriNIC Region origin ASes present in the Internet Routing Table: 1132 AfriNIC Prefixes per ASN: 18.78 AfriNIC Region origin ASes announcing only one prefix: 372 AfriNIC Region transit ASes present in the Internet Routing Table: 229 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 408 Number of AfriNIC addresses announced to Internet: 97927680 Equivalent to 5 /8s, 214 /16s and 66 /24s 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 4538 5404 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4380 415 430 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2897 11134 789 KIXS-AS-KR Korea Telecom, KR 9829 2810 1499 545 BSNL-NIB National Internet Backbone, IN 7552 2735 1155 69 VIETEL-AS-AP Viettel Group, VN 9394 2641 4922 26 CTTNET China TieTong Telecommunications 45899 2574 1572 158 VNPT-AS-VN VNPT Corp, VN 17974 2336 928 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2189 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2093 417 214 TATACOMM-AS TATA Communications formerl 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 6327 3386 1323 85 SHAW - Shaw Communications Inc., CA 22773 3288 2988 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2168 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2092 2489 452 CHARTER-NET-HKY-NC - Charter Communicat 16509 2057 4445 640 AMAZON-02 - Amazon.com, Inc., US 209 1965 5070 607 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1961 339 182 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1809 228 548 CABLEONE - CABLE ONE, INC., US 16625 1762 862 1257 AKAMAI-AS - Akamai Technologies, Inc., 7018 1697 20212 1254 ATT-INTERNET4 - AT&T Services, Inc., US 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 12479 4073 1514 507 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 20940 2672 731 1962 AKAMAI-ASN1, US 8551 2134 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2032 1860 705 ROSTELECOM-AS, RU 34984 2016 334 485 TELLCOM-AS, TR 9121 1974 1692 19 TTNET, TR 13188 1610 100 43 TRIOLAN, UA 6849 1241 355 21 UKRTELNET, UA 8402 1233 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 8151 4443 3387 586 Uninet S.A. de C.V., MX 10620 3585 541 254 Telmex Colombia S.A., CO 11830 2642 369 86 Instituto Costarricense de Electricidad 6503 1626 437 53 Axtel, S.A.B. de C.V., MX 7303 1518 1024 191 Telecom Argentina S.A., AR 28573 1038 2255 176 CLARO S.A., BR 3816 1008 505 122 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 6147 1005 377 31 Telefonica del Peru S.A.A., PE 11172 928 126 85 Alestra, S. de R.L. de C.V., MX 18881 908 1074 29 TELEF�NICA BRASIL S.A, BR 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 1176 396 45 LINKdotNET-AS, EG 37611 829 107 9 Afrihost, ZA 36903 741 372 137 MT-MPLS, MA 36992 672 1412 41 ETISALAT-MISR, EG 8452 641 1730 18 TE-AS TE-AS, EG 24835 597 850 15 RAYA-AS, EG 29571 474 68 12 ORANGE-COTE-IVOIRE, CI 37492 451 376 81 ORANGE-, TN 15399 361 35 7 WANANCHI-, KE 37342 361 32 1 MOVITEL, MZ 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 4538 5404 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4443 3387 586 Uninet S.A. de C.V., MX 7545 4380 415 430 TPG-INTERNET-AP TPG Telecom Limited, AU 12479 4073 1514 507 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3585 541 254 Telmex Colombia S.A., CO 6327 3386 1323 85 SHAW - Shaw Communications Inc., CA 22773 3288 2988 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2897 11134 789 KIXS-AS-KR Korea Telecom, KR 9829 2810 1499 545 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4380 3950 TPG-INTERNET-AP TPG Telecom Limited, AU 8151 4443 3857 Uninet S.A. de C.V., MX 39891 3778 3758 ALJAWWALSTC-AS, SA 12479 4073 3566 UNI2-AS, ES 10620 3585 3331 Telmex Colombia S.A., CO 6327 3386 3301 SHAW - Shaw Communications Inc., CA 22773 3288 3139 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2735 2666 VIETEL-AS-AP Viettel Group, VN 9394 2641 2615 CTTNET China TieTong Telecommunications Corpora 11830 2642 2556 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.78.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.80.0/22 39407 CHITATELECOM-AS, RU 64111 UNALLOCATED 98.159.5.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.7.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 100.127.16.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM 100.127.18.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.48.0/24 327815 XNET, NA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 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:15 /9:12 /10:37 /11:100 /12:288 /13:565 /14:1096 /15:1900 /16:13401 /17:7827 /18:13644 /19:25153 /20:39337 /21:45283 /22:86502 /23:70144 /24:388600 /25:848 /26:604 /27:655 /28:36 /29:20 /30:17 /31:4 /32:53 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3174 3386 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 12479 2811 4073 UNI2-AS, ES 22773 2542 3288 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2061 2168 MEGAPATH5-US - MegaPath Corporation, US 11830 1990 2642 Instituto Costarricense de Electricidad y Telec 30036 1712 1961 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1601 3585 Telmex Colombia S.A., CO 8551 1597 2134 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 1560 1809 CABLEONE - CABLE ONE, INC., US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1592 2:830 4:19 5:2794 6:65 7:1 8:1117 12:1864 13:184 14:1738 15:30 16:3 17:203 18:68 20:47 21:4 23:2607 24:2161 25:2 27:2269 31:1974 32:88 35:27 36:510 37:2768 38:1448 39:256 40:119 41:3064 42:574 43:1951 44:105 45:4214 46:3061 47:204 49:1323 50:1051 51:304 52:991 54:372 55:5 56:12 57:42 58:1537 59:993 60:430 61:2151 62:1816 63:1795 64:4894 65:2220 66:4591 67:2361 68:1146 69:3192 70:1147 71:561 72:2095 74:2715 75:411 76:435 77:1553 78:1703 79:1925 80:1482 81:1404 82:1077 83:775 84:1042 85:2060 86:580 87:1313 88:935 89:2320 90:207 91:6321 92:1177 93:2378 94:2395 95:2777 96:662 97:357 98:946 99:133 100:81 101:1277 102:40 103:17543 104:3593 105:231 106:660 107:1812 108:709 109:2707 110:1598 111:1775 112:1277 113:1338 114:1123 115:1637 116:1645 117:1718 118:2156 119:1668 120:970 121:1056 122:2450 123:1808 124:1450 125:1893 128:994 129:648 130:453 131:1587 132:672 133:196 134:1016 135:228 136:458 137:495 138:1933 139:595 140:423 141:697 142:808 143:965 144:812 145:457 146:1178 147:781 148:1584 149:707 150:737 151:1056 152:763 153:311 154:1020 155:760 156:926 157:785 158:638 159:1670 160:937 161:750 162:2581 163:527 164:1054 165:1571 166:432 167:1403 168:3067 169:806 170:3685 171:429 172:1080 173:1964 174:885 175:754 176:1865 177:3999 178:2431 179:1219 180:2254 181:2208 182:2390 183:1141 184:918 185:13330 186:3617 187:2381 188:2741 189:2027 190:8090 191:1448 192:9842 193:5881 194:4774 195:3959 196:2524 197:1427 198:5539 199:5883 200:7391 201:5020 202:10406 203:10181 204:4534 205:2875 206:3088 207:3200 208:3978 209:3947 210:4039 211:2115 212:3023 213:2724 214:950 215:62 216:5912 217:2140 218:908 219:619 220:1756 221:995 222:1037 223:1246 End of report From nanog-announce at nanog.org Fri Apr 20 18:43:27 2018 From: nanog-announce at nanog.org (Ryan Woolley via NANOG-announce) Date: Fri, 20 Apr 2018 18:43:27 +0000 (UTC) Subject: [NANOG-announce] Reminder: NANOG 73 CFP is open! Message-ID: This message has been wrapped due to the DMARC policy setting to prevent NANOG subscribers from being unsubscribed due to bounces. -------------- next part -------------- An embedded message was scrubbed... From: Ryan Woolley Subject: Reminder: NANOG 73 CFP is open! Date: Fri, 20 Apr 2018 14:43:24 -0400 Size: 5714 URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From rwoolleynanog at gmail.com Fri Apr 20 18:49:05 2018 From: rwoolleynanog at gmail.com (Ryan Woolley) Date: Fri, 20 Apr 2018 14:49:05 -0400 Subject: Reminder: NANOG 73 CFP is open! Message-ID: NANOG Community, As a reminder, we are still accepting proposals for all sessions at NANOG 73 in Denver, CO, June 25-27, 2018. The full Call For Presentations can be found at: http://www.cvent.com/d/ttqv1z/6K Remaining Key Dates for NANOG 73: Tuesday, 05/08/18 CFP Deadline: Presentation Slides Due Tuesday, 05/08/18 CFP Topic List and NANOG Highlights Page Monday, 06/18/18 Speaker FINAL presentation Slides to PC Tool Sunday, 06/24/18 Lightning Talk Submissions Open (Abstracts Only) Sunday, 06/24/18 On-site Registration Finals slides must be submitted by Monday, June 18, 2018, and no changes will be accepted between that date and the conference. Materials received after that date will be updated on the web site after the completion of the conference. We look forward to seeing you in June in Denver! Sincerely, Ryan Woolley NANOG PC From bzs at theworld.com Fri Apr 20 19:09:12 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Fri, 20 Apr 2018 15:09:12 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <23257.12824.250276.763926@gargle.gargle.HOWL> <20180420024309.DC0F7254665A@ary.qy> Message-ID: <23258.15064.100809.338020@gargle.gargle.HOWL> Inline... On April 20, 2018 at 03:47 farzi at gatech.edu (Badiei, Farzaneh) wrote: > Dear John, > > > The days when some in the technical community could just discard others > arguments by saying that "[you] have no idea how the Internet works" have long > passed. I will not get intimidated nor will I step back. Old tricks, won't > work, it's as old as the dysfunctional WHOIS and will disappear. No one responded most likely because you are speaking to a vast "room" of engineers etc and just said WHOIS is "old and dysfunctional" without a single word as to why you believe this to be the case. The DNS system is almost exactly the same age, is that also a problem? At least that's what pops into a technical person's mind. And "dysfunctional" seems like it's based on assumptions others here may not share. So we are left to guess whether you have any idea how any of this works, it's an article of faith? Challenging someone's understanding of a system they are criticizing is not "intimidation", it's just an assumption lacking any evidence to the contrary. And TBH "it will disappear" sounds like a purely political threat. We shall see in the fullness of time...in about 20 years ICANN has failed to do much anything regarding WHOIS other than talk about it a lot. > > > Also your last paragraph obliges me to clarify: it's not always a "he" that > might be arguing! it's sometimes, though might it be rarely, a "she". > > > No one asked to protect people from their governments (I have heard this before > as well). But also people should not be endangered or even minimally disturbed > by making their personal information public. There are many many scenarios when > personal information can be abused, and governments might not be involved. So why aren't current privacy options sufficient? Why not, as I have suggested in many forums now, just move the publicly visable information into the DNS and thus completely under the domain owner's control? Why does ICANN simultaneously press for the accuracy (and precision) of this information while bemoaning its public availability? Well, there are reasons, I could answer that I suppose. But disconnecting the public function of WHOIS from the business need for customer information seems like a reasonable approach. As is even stated in the relevant RFCs WHOIS is a public directory of domain owners and contact information. Not very different from a phone directory, and with similar provisions for privacy. It's not like the IETF et al created WHOIS out of thin air, it was intended to be a lot like a phone (or similar) directory. > > > I might not know as much as you do about how the Internet works. But I know one > thing: There will be a change. The convenience of security researchers and > trademark owners is not going to be set above domain name registrants right to > data protection. But I am sure the cybersecurity community can come up with a > more creative way of preserving cybersecurity without relying on using personal > information of domain name registrants and violating their rights! But the current ICANN proposals as I understand them make all this information available to anyone who can pay the price or meet certain criteria which don't seem terribly exclusive other than "those we respect vs those we don't". They've proposed a "tiered access". Which sounds to me more like an intent to monetize WHOIS not protect its content in general. Or is only allowing for example folks like Cambridge Analytica or other vast and well-funded opinion and marketing organizations access somehow a protection of "rights"? One problem with that sort of access is that once it's out there, it's out there! One can write rules about "legitimate" use and redistribution but as we see every day breaches and just disregard for such rules are rampant. Why pretend that making WHOIS non-public will protect anyone? The current system has its appeal, it's public information, if you do not want your information public there are various ways to protect your own information (e.g., check that privacy box, pay a third party proxy, etc.) And for that matter one of those "access tiers" is "law enforcement", what government won't meet that criteria? Is there some intent by ICANN to vet "good" governments vs "bad" governments when granting law enforcement general access? Note: This is not search warrant type access, it's general access to the entire WHOIS database without prior restraint. And there's still that annoying question about warrantability of this supposed protection of privacy. You really haven't spent a word answering any of the issues raised here, you mostly complained about the pronouns used. They might be valid complaints, but they're not sufficient to provide a response to the issues. P.S For the record we know each other from ICANN meetings and Farzaneh can do a lot better than this. > > > Farzaneh > > > > > In article <23257.12824.250276.763926 at gargle.gargle.HOWL> you write: > >So you think restricting WHOIS access will protect dissidents from > >abusive governments? > > > >Of all the rationalizations that one seems particularly weak. > > Oh, you're missing the point. This is a meme that's been floating > around in academia for a decade: the brave dissident who somehow has > managed to find web hosting, e-mail, broadband, and mobile phone > service but for whom nothing stands between her and certain death but > the proxy whois on her vanity domain. > > If someone makes this argument you can be 100% sure he's parroting > something he heard somewhere and has no idea how the Internet actually > works. > > > > ------------------------------------------------------------------------------- > From: NANOG on behalf of John Levine > Sent: Thursday, April 19, 2018 10:43 PM > To: nanog at nanog.org > Cc: bzs at theworld.com > Subject: Re: Is WHOIS going to go away? > > In article <23257.12824.250276.763926 at gargle.gargle.HOWL> you write: > >So you think restricting WHOIS access will protect dissidents from > >abusive governments? > > > >Of all the rationalizations that one seems particularly weak. > > Oh, you're missing the point. This is a meme that's been floating > around in academia for a decade: the brave dissident who somehow has > managed to find web hosting, e-mail, broadband, and mobile phone > service but for whom nothing stands between her and certain death but > the proxy whois on her vanity domain. > > If someone makes this argument you can be 100% sure he's parroting > something he heard somewhere and has no idea how the Internet actually > works. > > R's, > John -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Fri Apr 20 19:10:53 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Fri, 20 Apr 2018 15:10:53 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> Message-ID: <23258.15165.925961.963661@gargle.gargle.HOWL> On April 20, 2018 at 12:03 oscar.vives at gmail.com (Tei) wrote: > Maybe a good balance for whois is to include organization information > so I know where a website is hosted, but not personal information, so > I can't show in their house and steal their dog. > > I feel uneasy about having my phone available to literally everyone on > the internet. There are various privacy options available when one registers a domain, generally a matter of checking a box and usually free. > > > -- > -- > ℱin del ℳensaje. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From rubensk at gmail.com Fri Apr 20 19:20:17 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 20 Apr 2018 16:20:17 -0300 Subject: Is WHOIS going to go away? In-Reply-To: <23258.15165.925961.963661@gargle.gargle.HOWL> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> Message-ID: On Fri, Apr 20, 2018 at 4:10 PM, wrote: > > On April 20, 2018 at 12:03 oscar.vives at gmail.com (Tei) wrote: > > Maybe a good balance for whois is to include organization information > > so I know where a website is hosted, but not personal information, so > > I can't show in their house and steal their dog. > > > > I feel uneasy about having my phone available to literally everyone on > > the internet. > > There are various privacy options available when one registers a > domain, generally a matter of checking a box and usually free. > Those privacy options work until one wants to transfer a domain to a different registrar. Almost always that will imply in a brief removal of privacy, during which an adversary (either a nation-state or some Sideshow Bob-type wacko) will learn the true identity of the domain holder. Rubens From SNaslund at medline.com Fri Apr 20 19:31:20 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 20 Apr 2018 19:31:20 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <23258.15165.925961.963661@gargle.gargle.HOWL> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> Message-ID: <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> I don't see why there should not be a way to know who is publishing data on the Internet. In almost all other forms of communication, there is some accountability for the origination of information. Newspaper publishers are known, radio stations are usually licensed and publicly known, television is licensed as well. Your phone and Internet traffic is available to the government and law enforcement. People need to be held legally accountable for the information they present to the public otherwise you would have absolutely no recourse in the event that you were slandered, scammed, or otherwise harmed by this information. People being scared of their government is a real thing, however it is not up to the Internet to protect people from their own governments, that is a political problem not a technical one. Always think of the negative side of the argument. If a website was distributing unauthorized compromising photos of your children would you want them to be completely anonymous? Think of how aggravated we all are with the spam we receive every day and how much you like spoofed caller ID data when you talk about anonymity. Publishing information for access by the entire public should have some sort of accountability with it. When you get into the business of "protecting" people from their own "oppressive" governments, you are also protecting "enemies and criminals" from another perspective. Most all nation states would have the ability to track the communications to their source in any case so all you are really doing is protecting the data from the public. It would appear to me that the ICANN proposal is nothing more than a means to monetize what used to be public data. Why should Google have all the fun? Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of bzs at theworld.com Sent: Friday, April 20, 2018 2:11 PM To: Tei Cc: nanog at nanog.org Subject: Re: Is WHOIS going to go away? On April 20, 2018 at 12:03 oscar.vives at gmail.com (Tei) wrote: > Maybe a good balance for whois is to include organization information > so I know where a website is hosted, but not personal information, so > I can't show in their house and steal their dog. > > I feel uneasy about having my phone available to literally everyone on > the internet. There are various privacy options available when one registers a domain, generally a matter of checking a box and usually free. > > > -- > -- > ℱin del ℳensaje. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Fri Apr 20 19:36:57 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Fri, 20 Apr 2018 15:36:57 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> Message-ID: <23258.16729.462481.587122@gargle.gargle.HOWL> That just sounds like a minor change to fix this, a bug. No need to burn down the house to kill a mosquito. And my suggestion to move the publicly visible WHOIS information into the DNS and thus completely under the domain owner's control would fix this with minimal effort from the registrant. I tend to doubt tho that this is a significant reason for the proposed changes. On April 20, 2018 at 16:20 rubensk at gmail.com (Rubens Kuhl) wrote: > > > On Fri, Apr 20, 2018 at 4:10 PM, wrote: > > > On April 20, 2018 at 12:03 oscar.vives at gmail.com (Tei) wrote: >  > Maybe a good balance for whois is to include organization information >  > so I know where a website is hosted, but not personal information, so >  > I can't show in their house and steal their dog. >  > >  > I feel uneasy about having my phone available to literally everyone on >  > the internet. > > There are various privacy options available when one registers a > domain, generally a matter of checking a box and usually free. > > > Those privacy options work until one wants to transfer a domain to a different > registrar. Almost always that will imply in a brief removal of privacy, during > which an adversary (either a nation-state or some Sideshow Bob-type wacko) will > learn the true identity of the domain holder.  > > > Rubens > > >   -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From aaron at heyaaron.com Fri Apr 20 19:40:31 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 20 Apr 2018 19:40:31 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> Message-ID: > "I don't see why there should not be a way to know who is publishing data on the Internet. In almost all other forms of communication, there is some accountability for the origination of information." ...in every other form of communication, the phrase "get a warrant" comes to mind. Except on the internet where we require the information to be public so that anyone and their dog can view it without a warrant. > "When you get into the business of "protecting" people from their own "oppressive" governments, you are also protecting "enemies and criminals" from another perspective." "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -A On Fri, Apr 20, 2018 at 12:33 PM Naslund, Steve wrote: > I don't see why there should not be a way to know who is publishing data > on the Internet. In almost all other forms of communication, there is some > accountability for the origination of information. Newspaper publishers > are known, radio stations are usually licensed and publicly known, > television is licensed as well. Your phone and Internet traffic is > available to the government and law enforcement. People need to be held > legally accountable for the information they present to the public > otherwise you would have absolutely no recourse in the event that you were > slandered, scammed, or otherwise harmed by this information. People being > scared of their government is a real thing, however it is not up to the > Internet to protect people from their own governments, that is a political > problem not a technical one. Always think of the negative side of the > argument. If a website was distributing unauthorized compromising photos > of your children would you want them to be completely anonymous? > > Think of how aggravated we all are with the spam we receive every day and > how much you like spoofed caller ID data when you talk about anonymity. > > > Publishing information for access by the entire public should have some > sort of accountability with it. > > When you get into the business of "protecting" people from their own > "oppressive" governments, you are also protecting "enemies and criminals" > from another perspective. Most all nation states would have the ability to > track the communications to their source in any case so all you are really > doing is protecting the data from the public. > > It would appear to me that the ICANN proposal is nothing more than a means > to monetize what used to be public data. Why should Google have all the > fun? > > Steven Naslund > Chicago IL > > > > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of bzs at theworld.com > Sent: Friday, April 20, 2018 2:11 PM > To: Tei > Cc: nanog at nanog.org > Subject: Re: Is WHOIS going to go away? > > > On April 20, 2018 at 12:03 oscar.vives at gmail.com (Tei) wrote: > > Maybe a good balance for whois is to include organization information > > so I know where a website is hosted, but not personal information, so > > I can't show in their house and steal their dog. > > > > I feel uneasy about having my phone available to literally everyone on > > the internet. > > There are various privacy options available when one registers a > domain, generally a matter of checking a box and usually free. > > > > > > > -- > > -- > > ℱin del ℳensaje. > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | > http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo* > From kmedcalf at dessus.com Fri Apr 20 19:53:55 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Fri, 20 Apr 2018 13:53:55 -0600 Subject: Is WHOIS going to go away? In-Reply-To: Message-ID: <0ceb7c9d6c0c444d8de20d2e34f89c40@mail.dessus.com> >> "I don't see why there should not be a way to know who is >> publishing data on the Internet. In almost all other forms >> of communication, there is some accountability for the >> origination of information." >...in every other form of communication, the phrase "get a warrant" >comes to mind. >Except on the internet where we require the information to be public >so that anyone and their dog can view it without a warrant. This last statement is entirely untrue. WHOIS provides information as to the PUBLISHER (such as one would find on the masthead of a newspaper). This is, ought to be, and should remain, public information. You still need to "get a warrant" (or a rubber hose) as you so quaintly put it to ascertain the origination of the information published. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From aaron at heyaaron.com Fri Apr 20 20:36:37 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 20 Apr 2018 20:36:37 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <0ceb7c9d6c0c444d8de20d2e34f89c40@mail.dessus.com> References: <0ceb7c9d6c0c444d8de20d2e34f89c40@mail.dessus.com> Message-ID: On Fri, Apr 20, 2018 at 12:53 PM Keith Medcalf wrote: > This last statement is entirely untrue. WHOIS provides information as to > the PUBLISHER (such as one would find on the masthead of a newspaper). > This is, ought to be, and should remain, public information. > Oh, so I'm a newspaper now? Or are you telling me there's some magical setting in media publishing that prevents someone from hitting 'print' without attaching an identifying masthead? I as an individual should be able to register whatever site I want without filing to become a corporation to protect my identity from nutjobs on the internet if I so desire. Anyone with legal concerns about the content I might publish can hire a lawyer, get a warrant, and reveal who owns xyz.tld. Not that registering as a corporation protects your private identity either. But in all other forms of media I *can* protect my identity. I can publish a podcast, get interviewed by the news media with my face blurred, type up a crazy manifesto and distribute leaflets through town, take out an Ad in a newspaper, etc... You still need to "get a warrant" (or a rubber hose) as you so quaintly put > it to ascertain the origination of the information published. Am I misunderstanding the incessant yearly emails I get from my registrar warning me that I better be using valid information? What part of whois requires a warrant to view that information? -A From SNaslund at medline.com Fri Apr 20 20:53:06 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 20 Apr 2018 20:53:06 +0000 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> >...in every other form of communication, the phrase "get a warrant" comes to mind. >Except on the internet where we require the information to be public so that anyone and their dog can view it without a warrant. Wrong on several counts. You can publicly access the records of who owns every radio station, television station, and newspaper in the US and a lot of other countries. All of those organizations are REQUIRED by law to file ownership statements. Every periodical published in the United States has a block in it identifying the publisher. Every book sold has a publisher listed even if the author chooses to remain anonymous. It is a violation of the law for a telemarketer to call you without identifying themselves (which is what we complain about with phone scammers). Get a warrant only applies to communications (like your phone calls and your personal Internet traffic) that have a reasonable expectation of privacy. If you are in the public square shouting to the world you have no expectation of anonymity and you can actually be held responsible for false statements about another individual. A publicly accessible website’s published pages would not have any expectation of privacy whatsoever. Besides we are talking about identification of ownership of a communications site not the communications going through it. Just because I have your WHOIS data does not mean I have root access to your server. The government needs a warrant to listen to your phone calls but not to know you have a phone and where it is. We are not letting people monitor your traffic through WHOIS, we are only identifying who is responsible for all communications coming from that site. Another point is that “get a warrant” does not apply in totalitarian countries in any case. Try saying get a warrant in North Korean or China. Pretty moot point there. "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." No one ever had the liberty of publishing information to the public without accountability. There are tons of laws protecting you from false statements and communications intended to harm your reputation or damage your business. You are giving up an essential liberty here which is knowing who is saying what about you. Do you not want the right to know the sources of information presented to the public? Do you think I should be able to post anything I want about you in the public square without accountability? Can I put up a billboard criticizing you personally and keep my identity a complete secret? Might it be nice to know that the source of political news might have an axe to grind or an ideological bent, would you like to know that the news story you just read was actually from an opposition candidate? Are we not making a huge deal about Russia messing around with elections and trolling? How would you ever know that was going on with no accountability of the source of information? The whole protecting you from the government point is nothing but a straw man. There is no nation state that does not have enough resources to recover that information from you or your communications carrier. Even if your traffic is encrypted, it is trivial to figure out who is posting to social media or underground websites via other intelligence or simple traffic analysis. They can deny their entire populations access to just about any communications media they like. Most of them don’t because it is actually a more lucrative source of intelligence than a threat. If you are a dissident I might be better off leaving you on the Internet and trying to map your network of people even though it would be easy to just interrupt your comms. From a technical perspective, the domain naming system and Internet addressing system are assets you do not own. They are assigned to you and are considered a type of resource under quasi governmental control. If you keep WHOIS data secret all you are really doing is keeping the public out and the government in. Do you really believe that ICANN will stand up to the world governments if they ask for the data? If so, you probably also believe that the UN is effective at keeping the world at peace. Steven Naslund Chicago IL From aaron at heyaaron.com Fri Apr 20 21:04:04 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 20 Apr 2018 21:04:04 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> Message-ID: > "Wrong on several counts. You can publicly access the records of who owns every radio station, television station, and newspaper in the US and a lot of other countries. " You can't access their *sources* without a warrant. You seem to be conflating private individuals with corporations. > "No one ever had the liberty of publishing information to the public without accountability." That's provably false. I can type whatever I want, hit print, and scatter it around town unobserved at 3 AM. > "The whole protecting you from the government point is nothing but a straw man." That's not what I'm advocating. If whois disappeared entirely tomorrow, it wouldn't protect me from government. But it *would* protect me from crazy nutjobs. > "Do you really believe that ICANN will stand up to the world governments if they ask for the data?" Obviously not. But there's nothing I can do about it except tell them to come back with a warrant. There *is* something I can do to help limit the ability of crazy nutjobs to find out my information so they can visit my home and harass my family. Anyways, I think this has rambled on long enough. -A On Fri, Apr 20, 2018 at 1:55 PM Naslund, Steve wrote: > > >...in every other form of communication, the phrase "get a warrant" comes > to mind. > >Except on the internet where we require the information to be public so > that anyone and their dog can view it without a warrant. > > Wrong on several counts. You can publicly access the records of who owns > every radio station, television station, and newspaper in the US and a lot > of other countries. All of those organizations are REQUIRED by law to file > ownership statements. Every periodical published in the United States has a > block in it identifying the publisher. Every book sold has a publisher > listed even if the author chooses to remain anonymous. It is a violation > of the law for a telemarketer to call you without identifying themselves > (which is what we complain about with phone scammers). > > Get a warrant only applies to communications (like your phone calls and > your personal Internet traffic) that have a reasonable expectation of > privacy. If you are in the public square shouting to the world you have no > expectation of anonymity and you can actually be held responsible for false > statements about another individual. A publicly accessible website’s > published pages would not have any expectation of privacy whatsoever. > Besides we are talking about identification of ownership of a > communications site not the communications going through it. Just because > I have your WHOIS data does not mean I have root access to your server. > The government needs a warrant to listen to your phone calls but not to > know you have a phone and where it is. We are not letting people monitor > your traffic through WHOIS, we are only identifying who is responsible for > all communications coming from that site. > > Another point is that “get a warrant” does not apply in totalitarian > countries in any case. Try saying get a warrant in North Korean or China. > Pretty moot point there. > > > "Those who would give up essential Liberty, to purchase a little temporary > Safety, deserve neither Liberty nor Safety." > > No one ever had the liberty of publishing information to the public > without accountability. There are tons of laws protecting you from false > statements and communications intended to harm your reputation or damage > your business. > > You are giving up an essential liberty here which is knowing who is saying > what about you. Do you not want the right to know the sources of > information presented to the public? Do you think I should be able to post > anything I want about you in the public square without accountability? Can > I put up a billboard criticizing you personally and keep my identity a > complete secret? Might it be nice to know that the source of political > news might have an axe to grind or an ideological bent, would you like to > know that the news story you just read was actually from an opposition > candidate? Are we not making a huge deal about Russia messing around with > elections and trolling? How would you ever know that was going on with no > accountability of the source of information? > > The whole protecting you from the government point is nothing but a straw > man. There is no nation state that does not have enough resources to > recover that information from you or your communications carrier. Even if > your traffic is encrypted, it is trivial to figure out who is posting to > social media or underground websites via other intelligence or simple > traffic analysis. They can deny their entire populations access to just > about any communications media they like. Most of them don’t because it is > actually a more lucrative source of intelligence than a threat. If you are > a dissident I might be better off leaving you on the Internet and trying to > map your network of people even though it would be easy to just interrupt > your comms. > > From a technical perspective, the domain naming system and Internet > addressing system are assets you do not own. They are assigned to you and > are considered a type of resource under quasi governmental control. If you > keep WHOIS data secret all you are really doing is keeping the public out > and the government in. Do you really believe that ICANN will stand up to > the world governments if they ask for the data? If so, you probably also > believe that the UN is effective at keeping the world at peace. > > Steven Naslund > Chicago IL > > From Brian at ampr.org Fri Apr 20 21:10:12 2018 From: Brian at ampr.org (Brian Kantor) Date: Fri, 20 Apr 2018 14:10:12 -0700 Subject: Is WHOIS going to go away? In-Reply-To: <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> References: <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> Message-ID: <20180420211012.GB27921@meow.BKantor.net> Steve, I think you should re-examine the early history of the USA. Anonymous pamphleteering was the origin of our rebellion against England, with Benjamin Franklin and many of the other founding fathers publishing without their identities being registered anywhere. The Federalist Papers which form the basis for our system of government were published anonymously. It's a fundamental part of our liberties. No COMMERCIAL publisher will do that himself, but any individual who wants to may do so. "Freedom of the Press is guaranteed only to those who own one", and with the Internet, for the first time in many years, it is again practical to publish anonymously. It is the entrenched powers who want to require strict identification of all sources. I refer you to the Electronic Frontier Foundation website, and to the Internet law blog, and the Reporters Committee for freedom of the press, and any good American History book for further information. - Brian On Fri, Apr 20, 2018 at 08:53:06PM +0000, Naslund, Steve wrote: > No one ever had the liberty of publishing information to the public without accountability. There are tons of laws protecting you from false statements and communications intended to harm your reputation or damage your business. From SNaslund at medline.com Fri Apr 20 21:25:09 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 20 Apr 2018 21:25:09 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <20180420211012.GB27921@meow.BKantor.net> References: <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> Message-ID: <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> >Steve, > >I think you should re-examine the early history of the USA. Anonymous >pamphleteering was the origin of our rebellion against England, >with Benjamin Franklin and many of the other founding fathers >publishing without their identities being registered anywhere. The >Federalist Papers which form the basis for our system of government >were published anonymously. It's a fundamental part of our liberties. They did not in fact have the "right" to publish those pamphlets. They were in fact considered sedition by England. Just because something was done or seems correct does not make it a legal right. Freedom of speech is a right, anonymity is not a right, and privacy is not a right you have when you do things in public. That is simple well established law. >No COMMERCIAL publisher will do that himself, but any individual >who wants to may do so. "Freedom of the Press is guaranteed only >to those who own one", and with the Internet, for the first time >in many years, it is again practical to publish anonymously. And you would be violating the law if it was ruled that your publication was in fact a publication under the law. Freedom of the Press is not absolute because you do not have the right to violate MY rights by publishing slanderous materials, you do not have the right to communicate a threat. Publications are responsible for what they say. That is also well established law. Freedom of the Press does not equal right to anonymity. >It is the entrenched powers who want to require strict identification >of all sources. ICANN already has all of the data and they report to the world governments ultimately. ICANN is a non-profit corporation under California law so ultimately whatever they do is subject to US law and they could be compelled to comply with California or US court orders. I would say the powers that be already have the data. >I refer you to the Electronic Frontier Foundation website, and to >the Internet law blog, and the Reporters Committee for freedom of >the press, and any good American History book for further information. > - Brian I refer you to the LAW of whatever country you are in. They don't care what the EFF thinks and that blog won't keep you out of jail. Steven Naslund From dylan at ambauen.com Fri Apr 20 21:30:01 2018 From: dylan at ambauen.com (Dylan Ambauen) Date: Fri, 20 Apr 2018 14:30:01 -0700 Subject: Quanta LB4M In-Reply-To: <1457DAD1-A34C-41F5-B02C-6D992819FA2B@puck.nether.net> References: <1729959674.7770.1435517445740.JavaMail.mhammett@ThunderFuck> <1457DAD1-A34C-41F5-B02C-6D992819FA2B@puck.nether.net> Message-ID: On Sun, Jun 28, 2015 at 12:56 PM, Jared Mauch wrote: > I tossed a few different firmware versions I extracted here, as well as > the flash0/flash1 images and the doc i found for it. > http://puck.nether.net/~jared/lb4m/ Thank you Jared. Still helpful almost 3 years later. From aaron at heyaaron.com Fri Apr 20 21:35:53 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Fri, 20 Apr 2018 21:35:53 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> References: <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> Message-ID: On Fri, Apr 20, 2018 at 2:27 PM Naslund, Steve wrote: > They did not in fact have the "right" to publish those pamphlets. Now we're way off-topic, but our constitution acknowledges that is a pre-existing right. The constitution didn't grant it to you. (Rights are inherent, privileges are granted) People have the right to speak, write, and publish whatever they want. -A From rubensk at gmail.com Fri Apr 20 21:41:36 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 20 Apr 2018 18:41:36 -0300 Subject: Is WHOIS going to go away? In-Reply-To: References: <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> Message-ID: On Fri, Apr 20, 2018 at 6:35 PM, Aaron C. de Bruyn via NANOG < nanog at nanog.org> wrote: > On Fri, Apr 20, 2018 at 2:27 PM Naslund, Steve > wrote: > > > They did not in fact have the "right" to publish those pamphlets. > > > Now we're way off-topic, but our constitution acknowledges that is a > pre-existing right. The constitution didn't grant it to you. (Rights are > inherent, privileges are granted) > > People have the right to speak, write, and publish whatever they want. > > -A > Free speech is not the same as anonymity in all jurisdictions. In mine, anonymity is forbidden by the constitution... in some, anonymity is considered part of free speech. Matching local laws to a global policy is a challenge. Rubens From SNaslund at medline.com Fri Apr 20 21:47:19 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Fri, 20 Apr 2018 21:47:19 +0000 Subject: Is WHOIS going to go away? In-Reply-To: References: <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402ACDD1752@MUNPRDMBXA1.medline.com> >Now we're way off-topic, but our constitution acknowledges that is a pre-existing right. The constitution didn't grant it to you. (Rights are inherent, privileges are granted) > >People have the right to speak, write, and publish whatever they want. > >-A Our Constitution does not equal worldwide law and that is what we are really talking about here They were under British law before the Declaration of Independence (and it was vague until the war concluded). So they did not have that right under the current law in their jurisdiction. They were in fact criminals at the time. I don’t think that was right but it was the fact. You are way off base in your argument here because I am not disputing that you have the right to publish whatever you want on the Internet. Go ahead and put up any web site you like. I am just saying that you do NOT have the right to privacy when broadcasting information in a public forum. No broadcast media is private by definition. Steven Naslund Chicago IL >Now we're way off-topic, but our constitution acknowledges that is a pre-existing right. The constitution didn't grant it to you. (Rights are inherent, privileges are granted) > >People have the right to speak, write, and publish whatever they want. > >-A From jared at puck.nether.net Fri Apr 20 22:11:11 2018 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 20 Apr 2018 18:11:11 -0400 Subject: Quanta LB4M In-Reply-To: References: <1729959674.7770.1435517445740.JavaMail.mhammett@ThunderFuck> <1457DAD1-A34C-41F5-B02C-6D992819FA2B@puck.nether.net> Message-ID: <4CE973D2-9E01-4D27-9E85-68505F8F40DC@puck.nether.net> Happy it’s helping! - Jared > On Apr 20, 2018, at 5:30 PM, Dylan Ambauen wrote: > > On Sun, Jun 28, 2015 at 12:56 PM, Jared Mauch wrote: > I tossed a few different firmware versions I extracted here, as well as the flash0/flash1 images and the doc i found for it. > http://puck.nether.net/~jared/lb4m/ > > > Thank you Jared. Still helpful almost 3 years later. > From Brian at ampr.org Fri Apr 20 22:17:32 2018 From: Brian at ampr.org (Brian Kantor) Date: Fri, 20 Apr 2018 15:17:32 -0700 Subject: Is WHOIS going to go away? In-Reply-To: <9578293AE169674F9A048B2BC9A081B402ACDD1752@MUNPRDMBXA1.medline.com> References: <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1752@MUNPRDMBXA1.medline.com> Message-ID: <20180420221732.GA28208@meow.BKantor.net> Steve, I believe you are mistaken as to current law in the USA: The Supreme Court has ruled repeatedly that the right to anonymous free speech is protected by the First Amendment. A frequently cited 1995 Supreme Court ruling in McIntyre v. Ohio Elections Commission reads: Anonymity is a shield from the tyranny of the majority... Google for that phrase "anonymity is a shield from the tyranny of the majority" to see more references. I'll drop the discussion here, as it's likely to only continue down the rathole and I've said my piece. - Brian From surfer at mauigateway.com Fri Apr 20 22:36:02 2018 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 20 Apr 2018 15:36:02 -0700 Subject: Is WHOIS going to go away? Message-ID: <20180420153602.DA00F79E@m0117459.ppops.net> ------------------------- "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." ------------------------- One last OT point. It's Friday after all... :) https://www.npr.org/2015/03/02/390245038/ben-franklins-famous-liberty-safety-quote-lost-its-context-in-21st-century scott ps. whatever happened to the "Friday Fun" thing? From marka at isc.org Fri Apr 20 22:38:22 2018 From: marka at isc.org (Mark Andrews) Date: Sat, 21 Apr 2018 08:38:22 +1000 Subject: Is WHOIS going to go away? In-Reply-To: <20180420221732.GA28208@meow.BKantor.net> References: <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1752@MUNPRDMBXA1.medline.com> <20180420221732.GA28208@meow.BKantor.net> Message-ID: <3E065ADD-3E85-45A9-B887-0ED19F49D2EA@isc.org> Whois contact details need to work so you can contact the zone owner when the DNS is broken for the zone. Publishing Whois data in the zone does not work for this purpose. This is not to discount other reasons for having a independent communications channel. -- Mark Andrews > On 21 Apr 2018, at 08:17, Brian Kantor wrote: > > Steve, > > I believe you are mistaken as to current law in the USA: > > The Supreme Court has ruled repeatedly that the right to anonymous > free speech is protected by the First Amendment. A frequently cited > 1995 Supreme Court ruling in McIntyre v. Ohio Elections Commission > reads: Anonymity is a shield from the tyranny of the majority... > > Google for that phrase "anonymity is a shield from the tyranny of > the majority" to see more references. > > I'll drop the discussion here, as it's likely to only continue down > the rathole and I've said my piece. > - Brian From valdis.kletnieks at vt.edu Sat Apr 21 00:47:08 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 20 Apr 2018 20:47:08 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> Message-ID: <257633.1524271628@turing-police.cc.vt.edu> On Fri, 20 Apr 2018 12:03:37 +0200, Tei said: > Maybe a good balance for whois is to include organization information > so I know where a website is hosted, but not personal information, so > I can't show in their house and steal their dog. In many cases, the *OWNER* of a website doesn't have any real idea where their website is hosted -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Sat Apr 21 00:47:40 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 20 Apr 2018 20:47:40 -0400 Subject: Is WHOIS going to go away? In-Reply-To: <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> Message-ID: <257691.1524271660@turing-police.cc.vt.edu> On Fri, 20 Apr 2018 20:53:06 -0000, "Naslund, Steve" said: > "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." > > No one ever had the liberty of publishing information to the public without accountability. > You are giving up an essential liberty here which is knowing who is saying what > about you. Do you not want the right to know the sources of information > presented to the public? https://en.wikipedia.org/wiki/The_Federalist_Papers It's a good thing that those were stamped out and not made widely available because they were written anonymously, isn't it? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Sat Apr 21 00:50:27 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Fri, 20 Apr 2018 20:50:27 -0400 Subject: Is WHOIS going to go away? In-Reply-To: <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> References: <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> Message-ID: <257945.1524271827@turing-police.cc.vt.edu> On Fri, 20 Apr 2018 21:25:09 -0000, "Naslund, Steve" said: > And you would be violating the law if it was ruled that your publication was > in fact a publication under the law. Citation please, where anonymous publication is, in and of itself, illegal under US law.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From rubensk at gmail.com Sat Apr 21 00:56:59 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 20 Apr 2018 21:56:59 -0300 Subject: Is WHOIS going to go away? In-Reply-To: <3E065ADD-3E85-45A9-B887-0ED19F49D2EA@isc.org> References: <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1752@MUNPRDMBXA1.medline.com> <20180420221732.GA28208@meow.BKantor.net> <3E065ADD-3E85-45A9-B887-0ED19F49D2EA@isc.org> Message-ID: On Fri, Apr 20, 2018 at 7:38 PM, Mark Andrews wrote: > Whois contact details need to work so you can contact the zone owner when > the DNS is broken for the zone. > > Publishing Whois data in the zone does not work for this purpose. > > This is not to discount other reasons for having a independent > communications channel. > Note that the current draft gTLD WHOIS mechanism to abide by GDPR includes a communications channel that one can use to contact a domain owner, a web form. So this is ability is not being taken away for specific domains. But if someone finds out a vulnerability and needs a mass-scale delivery system to notify affected parties, then this wouldn't work. Also of notice is that if DNS resolution is working, a website or mail services points to an IP address somewhere. And that still provides reachability. So except for the broken DNS zone use case, a good number of cases have other means to achieve the same goals. Rubens From bzs at theworld.com Sat Apr 21 20:35:29 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Sat, 21 Apr 2018 16:35:29 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <0ceb7c9d6c0c444d8de20d2e34f89c40@mail.dessus.com> Message-ID: <23259.41105.994130.238579@gargle.gargle.HOWL> On April 20, 2018 at 20:36 nanog at nanog.org (Aaron C. de Bruyn via NANOG) wrote: > On Fri, Apr 20, 2018 at 12:53 PM Keith Medcalf wrote: > > > This last statement is entirely untrue. WHOIS provides information as to > > the PUBLISHER (such as one would find on the masthead of a newspaper). > > This is, ought to be, and should remain, public information. > > > > Oh, so I'm a newspaper now? Or are you telling me there's some magical > setting in media publishing that prevents someone from hitting 'print' > without attaching an identifying masthead? To a great extent the current situation has evolved due to the evolution of inexpensive always-on internet links and the rise of hosting companies. Prior to this one might pick up a vanity domain but for most individuals having an actual, functioning web site was prohibitively expensive. This situation was why we first had the rise of services like wordpress and myspace, and for that matter flickr and pinterest etc, where one could host their relatively non-commercial activity (or very tiny commercial activity, their garage band etc) for almost no cost. Facebook still caters to that -- non-domain siting (pages, groups) , but at this point for other reasons namely their own large ecosystem. But by and large it also arose from the same basic business model. It wasn't the domain per se so much as the always available hosting. Similar can be said for a lot of "the cloud". But domains pointing at personal web sites or even just email still have their appeal, clearly, around 300M have been sold. This wasn't a problem previously because commercial interests were required by law (in most countries) to provide clear contact info anyhow, and why wouldn't they unless they were dishonest or very unusual. But now that they have managed to sell many millions of cheap domains to non-commercial interests the issue of "privacy" arises almost entirely from that trend. But crippling WHOIS won't achieve privacy. If anyone believes that isn't true show me the warranty. At best it will just raise the barrier of entry to your "privacy" a little. And one breach and it's gone anyhow. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Sat Apr 21 20:49:00 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Sat, 21 Apr 2018 16:49:00 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> Message-ID: <23259.41916.170256.876183@gargle.gargle.HOWL> On April 20, 2018 at 18:41 rubensk at gmail.com (Rubens Kuhl) wrote: > Free speech is not the same as anonymity in all jurisdictions. In mine, > anonymity is forbidden by the constitution... in some, anonymity is > considered part of free speech. Matching local laws to a global policy is a > challenge. That's a good point, but not creating policy which honors the lowest common denominator is also a big part of that challenge. I recall during the nTLD comments periods some strongly worded objections from members of the GAC* to several new TLD applications based only on reasoning such as homosexuality was illegal in their country so any nTLD which implied service to homosexuals (e.g., .GAY) was unacceptable. Homosexuality is explicitly illegal in over 70 countries or so The Goog tells me. Compare and contrast to GDPR which is the legal framework of a mere 27 countries (perhaps 28.) * GAC: ICANN's Governmental Advisory Committee. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Sat Apr 21 20:58:43 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Sat, 21 Apr 2018 16:58:43 -0400 Subject: Is WHOIS going to go away? In-Reply-To: <3E065ADD-3E85-45A9-B887-0ED19F49D2EA@isc.org> References: <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1752@MUNPRDMBXA1.medline.com> <20180420221732.GA28208@meow.BKantor.net> <3E065ADD-3E85-45A9-B887-0ED19F49D2EA@isc.org> Message-ID: <23259.42499.182133.783023@gargle.gargle.HOWL> On April 21, 2018 at 08:38 marka at isc.org (Mark Andrews) wrote: > Whois contact details need to work so you can contact the zone owner when the DNS is broken for the zone. > > Publishing Whois data in the zone does not work for this purpose. > > This is not to discount other reasons for having a independent communications channel. That's actually an excellent point and counterpoint to my suggestion to move the WHOIS information into DNS RRs. But backup and failover are reasonably well understood technologies where one cares. Registrars could for example cache copies of those zone records and act as failover whois servers. In practice the vast majority, by number though not criticality, would be served by registrars anyhow as that's where most domain owners' zone info etc is anyhow. And many more valuable applications use various DNS backup services now. Nonetheless the point you raise would need to be on any requirements list for the change I suggest (move WHOIS into the DNS) and would need to be addressed. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From lyndon at orthanc.ca Sat Apr 21 21:27:44 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 21 Apr 2018 14:27:44 -0700 Subject: Is WHOIS going to go away? In-Reply-To: <23259.42499.182133.783023@gargle.gargle.HOWL> References: <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1752@MUNPRDMBXA1.medline.com> <20180420221732.GA28208@meow.BKantor.net> <3E065ADD-3E85-45A9-B887-0ED19F49D2EA@isc.org> <23259.42499.182133.783023@gargle.gargle.HOWL> Message-ID: > On Apr 21, 2018, at 1:58 PM, bzs at theworld.com wrote: > > That's actually an excellent point and counterpoint to my suggestion > to move the WHOIS information into DNS RRs. > > But backup and failover are reasonably well understood technologies > where one cares. Registrars could for example cache copies of those > zone records and act as failover whois servers. Instead of putting the contact info directly into the DNS, put pointers to the locations of the data instead. I.e. whois moves off dedicated ports and hardwired servers and into zone-controlled SRV records: _whois._tcp.orthanc.ca SRV 0 0 43 orthanc.ca. SRV 5 0 43 backup.otherdomain.example.com. This gives each zone control of the information they want to export (by directing whois(1) to what they consider to be authoritative servers). The domain owners themselves could control the information they chose to expose to the public, through the SRV records, and the information they chose to publish in the whois servers those records point at. If the domain owner is happy with their (say) registrar providing that information, they would just point the appropriate SRV record at the registrar. This is no different from how people handle email outsourcing via MX records. The idea that whois is in any way authoritative is long gone. Those who want to hide have been able to do that for ages. (I think I pay $15/year to mask some of the domains I control.) But for law enforcement, a warrant will always turn up the payment information used to register a domain, should the constabulary want to find that information out. And for court proceedings, whois data is useless. (I speak from $WORK experience.) --lyndon From lyndon at orthanc.ca Sat Apr 21 21:30:03 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 21 Apr 2018 14:30:03 -0700 Subject: Is WHOIS going to go away? In-Reply-To: References: <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1752@MUNPRDMBXA1.medline.com> <20180420221732.GA28208@meow.BKantor.net> <3E065ADD-3E85-45A9-B887-0ED19F49D2EA@isc.org> <23259.42499.182133.783023@gargle.gargle.HOWL> Message-ID: <5A4E9908-2940-479B-A150-06E9289E9C75@orthanc.ca> > On Apr 21, 2018, at 2:27 PM, Lyndon Nerenberg wrote: > >> But backup and failover are reasonably well understood technologies >> where one cares. Registrars could for example cache copies of those >> zone records and act as failover whois servers. Sorry! I left out the last line that was the point of my diatribe. Using SRV to point to multiple domain-specific whois servers eliminates the caching problem Barry raised. From kmedcalf at dessus.com Sat Apr 21 21:47:06 2018 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 21 Apr 2018 15:47:06 -0600 Subject: Is WHOIS going to go away? In-Reply-To: <23259.41105.994130.238579@gargle.gargle.HOWL> Message-ID: <2b1d539c393c914fbff1b816577d821a@mail.dessus.com> Actually, a I doubt that there are any "real" people with vanity domains behind this move. I suspect that it is the scammers and spammers who want to hide their information for very good reason. And of course, the "powers of the EU" seem to be in cahoots with those scammers and spammers (if they are not the scammers and spammers who themselves are wanting to hide). --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: bzs at TheWorld.com [mailto:bzs at TheWorld.com] >Sent: Saturday, 21 April, 2018 14:35 >To: Aaron C. de Bruyn >Cc: Keith Medcalf; nanog at nanog.org >Subject: Re: Is WHOIS going to go away? > > >On April 20, 2018 at 20:36 nanog at nanog.org (Aaron C. de Bruyn via >NANOG) wrote: > > On Fri, Apr 20, 2018 at 12:53 PM Keith Medcalf > wrote: > > > > > This last statement is entirely untrue. WHOIS provides >information as to > > > the PUBLISHER (such as one would find on the masthead of a >newspaper). > > > This is, ought to be, and should remain, public information. > > > > > > > Oh, so I'm a newspaper now? Or are you telling me there's some >magical > > setting in media publishing that prevents someone from hitting >'print' > > without attaching an identifying masthead? > >To a great extent the current situation has evolved due to the >evolution of inexpensive always-on internet links and the rise of >hosting companies. > >Prior to this one might pick up a vanity domain but for most >individuals having an actual, functioning web site was prohibitively >expensive. > >This situation was why we first had the rise of services like >wordpress and myspace, and for that matter flickr and pinterest etc, >where one could host their relatively non-commercial activity (or >very >tiny commercial activity, their garage band etc) for almost no cost. > >Facebook still caters to that -- non-domain siting (pages, groups) , >but at this point for other reasons namely their own large >ecosystem. But by and large it also arose from the same basic >business >model. > >It wasn't the domain per se so much as the always available >hosting. Similar can be said for a lot of "the cloud". > >But domains pointing at personal web sites or even just email still >have their appeal, clearly, around 300M have been sold. > >This wasn't a problem previously because commercial interests were >required by law (in most countries) to provide clear contact info >anyhow, and why wouldn't they unless they were dishonest or very >unusual. > >But now that they have managed to sell many millions of cheap domains >to non-commercial interests the issue of "privacy" arises almost >entirely from that trend. > >But crippling WHOIS won't achieve privacy. If anyone believes that >isn't true show me the warranty. > >At best it will just raise the barrier of entry to your "privacy" a >little. > >And one breach and it's gone anyhow. > >-- > -Barry Shein > >Software Tool & Die | bzs at TheWorld.com | >http://www.TheWorld.com >Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD >The World: Since 1989 | A Public Information Utility | *oo* From lyndon at orthanc.ca Sat Apr 21 21:54:51 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 21 Apr 2018 14:54:51 -0700 Subject: Is WHOIS going to go away? In-Reply-To: <2b1d539c393c914fbff1b816577d821a@mail.dessus.com> References: <2b1d539c393c914fbff1b816577d821a@mail.dessus.com> Message-ID: <312C1393-0B96-444C-B9C3-B556A97FB4AD@orthanc.ca> > On Apr 21, 2018, at 2:47 PM, Keith Medcalf wrote: > > Actually, a I doubt that there are any "real" people with vanity domains behind this move. I suspect that it is the scammers and spammers who want to hide their information for very good reason. > > And of course, the "powers of the EU" seem to be in cahoots with those scammers and spammers (if they are not the scammers and spammers who themselves are wanting to hide). I also think more fine-grained control of the data would satisfy many needs. E.g., for my own domains, for the purposes of contacting me to deal with abuse (or insanely large but unlikely buyout offers), all you need is an email contact address. I can put my personal or company name out there, along with a working email address, and still not hand over my home address, phone numbers, etc. For domains backing consumer-facing companies, they would likely want to expose more information. There is no one-size-fits-all here. And that's where the EU is losing credibility. --lyndon From marka at isc.org Sat Apr 21 22:48:01 2018 From: marka at isc.org (Mark Andrews) Date: Sun, 22 Apr 2018 08:48:01 +1000 Subject: Is WHOIS going to go away? In-Reply-To: References: <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1752@MUNPRDMBXA1.medline.com> <20180420221732.GA28208@meow.BKantor.net> <3E065ADD-3E85-45A9-B887-0ED19F49D2EA@isc.org> <23259.42499.182133.783023@gargle.gargle.HOWL> Message-ID: <57D76BC1-D96F-42E4-93B1-44176C76689A@isc.org> You have a logic fail. This fails because it STILL depends on the DNS for the zone working. -- Mark Andrews > On 22 Apr 2018, at 07:27, Lyndon Nerenberg wrote: > > >> On Apr 21, 2018, at 1:58 PM, bzs at theworld.com wrote: >> >> That's actually an excellent point and counterpoint to my suggestion >> to move the WHOIS information into DNS RRs. >> >> But backup and failover are reasonably well understood technologies >> where one cares. Registrars could for example cache copies of those >> zone records and act as failover whois servers. > > Instead of putting the contact info directly into the DNS, put pointers to the locations of the data instead. I.e. whois moves off dedicated ports and hardwired servers and into zone-controlled SRV records: > > _whois._tcp.orthanc.ca SRV 0 0 43 orthanc.ca. > SRV 5 0 43 backup.otherdomain.example.com. > > This gives each zone control of the information they want to export (by directing whois(1) to what they consider to be authoritative servers). > > The domain owners themselves could control the information they chose to expose to the public, through the SRV records, and the information they chose to publish in the whois servers those records point at. If the domain owner is happy with their (say) registrar providing that information, they would just point the appropriate SRV record at the registrar. This is no different from how people handle email outsourcing via MX records. > > The idea that whois is in any way authoritative is long gone. Those who want to hide have been able to do that for ages. (I think I pay $15/year to mask some of the domains I control.) But for law enforcement, a warrant will always turn up the payment information used to register a domain, should the constabulary want to find that information out. And for court proceedings, whois data is useless. (I speak from $WORK experience.) > > --lyndon > From lyndon at orthanc.ca Sat Apr 21 22:52:29 2018 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 21 Apr 2018 15:52:29 -0700 Subject: Is WHOIS going to go away? In-Reply-To: <57D76BC1-D96F-42E4-93B1-44176C76689A@isc.org> References: <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1676@MUNPRDMBXA1.medline.com> <20180420211012.GB27921@meow.BKantor.net> <9578293AE169674F9A048B2BC9A081B402ACDD16D1@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD1752@MUNPRDMBXA1.medline.com> <20180420221732.GA28208@meow.BKantor.net> <3E065ADD-3E85-45A9-B887-0ED19F49D2EA@isc.org> <23259.42499.182133.783023@gargle.gargle.HOWL> <57D76BC1-D96F-42E4-93B1-44176C76689A@isc.org> Message-ID: > On Apr 21, 2018, at 3:48 PM, Mark Andrews wrote: > > You have a logic fail. This fails because it STILL depends on the DNS for the zone working. If the DNS fails to that extent, everything fails. I was addressing the single application endpoint point-of-failure. But from a practical standpoint, you're probably right :-( --lyndon From rjs at rob.sh Sun Apr 22 06:05:19 2018 From: rjs at rob.sh (Rob Shakir) Date: Sun, 22 Apr 2018 06:05:19 +0000 Subject: How are you configuring BFD timers? In-Reply-To: References: <80279633-5309-4C5C-8781-25BBE8B04406@lixfeld.ca> <515632340c5f4819b633b718e1d32555@USEXCAPP13.Teva.Corp> <20180322204121.GA26806@besserwisser.org> <4BEBF65216E3C15374380D61@treize.besserwisser.org> Message-ID: I'm not sure it's used by a large proportion of operators, but it is deployed in some volume in a number of networks that I'm aware of. During the development of implementations, we hosted inter-op testing/fixing at a previous employer. Rolling it out had started when I moved on, but I expect it is now across their global deployments at this point. I haven't heard anything to say that it's causing any issues. [I still am somewhat unable to reconcile myself with the use of BFD in this deployment, some Ethernet OAM - seemed a reasonable per-member solution to me, but folks have a preference for a single protocol here.] r. On Wed, 28 Mar 2018 at 10:15 Arie Vayner wrote: > Not directly related, but I wonder: how common is micro-BFD for detecting > bundle member failures? > > > > On Thu, Mar 22, 2018 at 10:12 PM Måns Nilsson > wrote: > > > > > > > --On 22 mars 2018 23:45:16 +0200 Saku Ytti wrote: > > > > > On 22 March 2018 at 22:41, Måns Nilsson > > > wrote: > > > > > >> Subject: Re: How are you configuring BFD timers? Date: Wed, Mar 21, > 2018 > > >> at 04:24:47PM +0000 Quoting Job Snijders (job at instituut.net): > > >>> Silly question perhaps, but why would you do BFD on dark fiber? > > >> > > >> Because Ethernet lacks the PRDI that real WAN protocols have. > > > > > > Indeed, RFI on ethernet is rather modern addition, turning 20 this > year. > > > > (You just reminded me I've been doing some sort of WAN network ops for > > about 20 years.) > > > > That does indeed solve the problem for dark fibre, and those lucky WDM > > systems that actually reflect input status to output. Not always true, > I'm > > afraid (just look at the Ethernet switch mid-span that Thomas Bellman > wrote > > about; a fitting metaphor for all "ethernet-over-other.." models..). > > Ethernet still regards "no frames seen on the yellow coax" as an > > opportunity to send traffic rather than an error, if we're talking old > > things ;-). BFD solves that, and it is worthwhile to have one setup > > regardless of technology, if possible. > > > > -- > > Måns Nilsson primary/secondary/besserwisser/machina > > MN-1334-RIPE SA0XLR +46 705 989668 > > CHUBBY CHECKER just had a CHICKEN SANDWICH in downtown DULUTH! > > > From mpeterman at apple.com Mon Apr 23 15:59:09 2018 From: mpeterman at apple.com (Matt Peterman) Date: Mon, 23 Apr 2018 08:59:09 -0700 Subject: Anyone at Microsoft able to get in touch? Message-ID: TLDR: Moved v4 prefix from Europe to US and now unable to activate MS products because “This key is not supported in your region”. Trying to figure out how to get this updated (space is correctly mapped to the US in Akamai Edgecape, MaxMind etc) Any advice is appreciated! Matt From craigwashington01 at hotmail.com Mon Apr 23 18:14:41 2018 From: craigwashington01 at hotmail.com (craig washington) Date: Mon, 23 Apr 2018 18:14:41 +0000 Subject: Hulu Peering Message-ID: Hey all, Just wondering if anyone peers with Hulu at any public exchange. I don't see anything on them in the peeringdb or anything that stands out from a google search besides it looks like they may be doing something with Equinix. Thanks From joelja at bogus.com Mon Apr 23 18:26:59 2018 From: joelja at bogus.com (joel jaeggli) Date: Mon, 23 Apr 2018 11:26:59 -0700 Subject: Hulu Peering In-Reply-To: References: Message-ID: On 4/23/18 11:14 AM, craig washington wrote: > Hey all, > > > Just wondering if anyone peers with Hulu at any public exchange. > > I don't see anything on them in the peeringdb or anything that stands out from a google search besides it looks like they may be doing something with Equinix. Hulu's streaming media bits come from a few CDNs. My current cartoon network bits are coming from verizon digital media services. > > Thanks > > > From rod.beck at unitedcablecompany.com Mon Apr 23 20:49:09 2018 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Mon, 23 Apr 2018 20:49:09 +0000 Subject: Lumos Salesman Message-ID: Hi, Please contact me off list. I have a 100 gig wave to discuss. It is on-net for this carrier. Thanks. Regards, Roderick. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com New York City & Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From job at instituut.net Mon Apr 23 20:53:49 2018 From: job at instituut.net (Job Snijders) Date: Mon, 23 Apr 2018 20:53:49 +0000 Subject: Lumos Salesman In-Reply-To: References: Message-ID: Rod, Please take the "Pre-Posting Guide" (https://nanog.org/list) into consideration before diluting this mailing list with classifieds like the one below. Regards, Job On Mon, Apr 23, 2018 at 8:49 PM, Rod Beck wrote: > Hi, > > > Please contact me off list. I have a 100 gig wave to discuss. It is on-net for this carrier. > > > Thanks. > > > Regards, > > > Roderick. > > > Roderick Beck > > Director of Global Sales From mark.tinka at seacom.mu Tue Apr 24 07:28:06 2018 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 24 Apr 2018 09:28:06 +0200 Subject: Solera Peering Contact Message-ID: Hi all. Looking for a warm body that deals with peering over at Solera (www.solera.com). Trying to get someone to setup peering with their network at NAPAfrica in Johannesburg, but we can't seem to find anyone with "enable". If anyone from Solera is on-list, or if there is anyone that can point me in their direction, beer(s) on me in Vancouver :-). Thanks. Mark. From Colin-lists at highspeedcrow.ca Fri Apr 20 13:52:29 2018 From: Colin-lists at highspeedcrow.ca (Colin Stanners (lists)) Date: Fri, 20 Apr 2018 08:52:29 -0500 Subject: China Showdown Huawei vs ZTE In-Reply-To: References: Message-ID: <44b501d3d8ae$d2e57ac0$78b07040$@highspeedcrow.ca> Colton, can you post some examples of the Whitebox/OS examples that you were looking at in that performance tier? -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Colton Conor Sent: Friday, April 20, 2018 7:46 AM To: Josh Reynolds Cc: NANOG Subject: Re: China Showdown Huawei vs ZTE Josh, I like the whitebox route, but I can't find anything that will come close price wise. Example, Huawei S6720 with 24 10G ports, 2 40G ports, and full MPLS operating system from Huawei is $3500 out the door with a lifetime warranty. I can't even find a whitebox hardware, not even accounting for the OS, that is close to that price. Most 48 Port 10G with 6 40G uplinks (so double this huawei unit) are in the $5k range, and then you have to buy an operating system costing a couple more grand. Choices are limited on whitebox operating systems that support MPLS. There might be some FibeStore models that come close to this price, but FS.com is a Chinese company too, so that's no better than ZTE or Huawei. On Fri, Apr 20, 2018 at 7:34 AM, Josh Reynolds wrote: > Why not just go the whitebox route and pick your NOS of choice? > > Far cheaper, and far more flexible. > > On Fri, Apr 20, 2018, 7:28 AM Colton Conor wrote: > >> Of the two large Chinese Vendors, which has the better network >> operating system? Huawei is much larger that ZTE is my understanding, >> but larger does not always mean better. >> >> Both of these manufactures have switches and routers. I doubt we will >> use their routing products anytime soon, but the switching products >> with MPLS are what we are exploring. Price wise both of these vendors >> seem to have 10G MPLS capable switches that are a 1/4 of the price of >> a Cisco or Juniper wants to charge. >> >> On the Huawei side looks like the S6720 is a fit. >> On the ZTE side, it looks like the ZXR10 5960 Series is a fit. >> >> Has anyone had experience with either of these two switches? How do >> they compare? >> >> Also, for each independent brand, is their switching network >> operating system the same as their routing network operating system >> that their routers run? >> > From farzi at gatech.edu Thu Apr 19 22:24:14 2018 From: farzi at gatech.edu (Badiei, Farzaneh) Date: Thu, 19 Apr 2018 22:24:14 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <23257.4316.455617.983247@gargle.gargle.HOWL> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> , <23257.4316.455617.983247@gargle.gargle.HOWL> Message-ID: “Granted there's that gray area of dissident political movements etc. but their full time job is protecting their identity.” You think? The median number of domain name registration that used privacy proxy service in the Middle East is 24%. See the DNS Market study: https://www.icann.org/en/system/files/files/meac-dns-study-26feb16-en.pdf Now lets look at the distribution of that number: “Rates of privacy proxy registrations varied across countries in the region, with the lowest rates seen in Iran (7%) and Turkey (12%), and the highest rates in Syria (32%), Algeria and Egypt (31% each).” I guess some people who share your band name in those countries with the lowest percentage of privacy proxy service might not really know how they can use privacy proxy services ! Lets just keep their personal information public until they find out how and why their house has been raided. Also I don’t really understand why people keep saying “whois is going away” and “whois is going dark” It is not. Personal information in the database should be made private. WHOIS contains more than personal information. You are the technical people, you know better than me. Thanks for bringing up the grey area anyway. Not many consider that in the discussions. But it’s not only dissidents. It’s also journalists and especially female journalists that work on issues that some might not like. Also sometimes you don’t even know you have to hide your identity because you don’t think you are doing anything against the law, the problem is that we don’t have the rule of law everywhere in the world. Best Dr. Farzaneh Badiei Research Associate, School of Public Policy Executive Director, Internet Governance Project From: bzs at theworld.com Sent: Thursday, April 19, 2018 5:58 PM To: Aaron C. de Bruyn Cc: nanog at nanog.org; Rich Kulawiec Subject: Re: Is WHOIS going to go away? One of the memes driving this WHOIS change is the old idea of "starving the beast". People involved in policy discussions complain that "spammers" -- many only marginally fit that term other than by the strictest interpretation -- use the public WHOIS data to contact domain owners. I've countered that 20+ years experience trying to "starve the beast" by trying to deny them access to email and other casual contact info has proven the approach to be useless. Choosing the privacy options on your domain registration is probably just as, if not more, effective. Another argument against this whole idea is that in most countries one is required by law to provide valid contact information if they are doing business with the general public. That would include soliciting donations etc. And that's essentially why domains exist, organizational contact. This trend towards "vanity" domains is relatively recent and really the only reason one can even claim there is a problem. I doubt Microsoft or General Motors are excited to see that their domain registration contact information will soon be protected by law. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From farzi at gatech.edu Fri Apr 20 03:47:21 2018 From: farzi at gatech.edu (Badiei, Farzaneh) Date: Fri, 20 Apr 2018 03:47:21 +0000 Subject: Is WHOIS going to go away? In-Reply-To: <20180420024309.DC0F7254665A@ary.qy> References: <23257.12824.250276.763926@gargle.gargle.HOWL>, <20180420024309.DC0F7254665A@ary.qy> Message-ID: Dear John, The days when some in the technical community could just discard others arguments by saying that "[you] have no idea how the Internet works" have long passed. I will not get intimidated nor will I step back. Old tricks, won't work, it's as old as the dysfunctional WHOIS and will disappear. Also your last paragraph obliges me to clarify: it's not always a "he" that might be arguing! it's sometimes, though might it be rarely, a "she". No one asked to protect people from their governments (I have heard this before as well). But also people should not be endangered or even minimally disturbed by making their personal information public. There are many many scenarios when personal information can be abused, and governments might not be involved. I might not know as much as you do about how the Internet works. But I know one thing: There will be a change. The convenience of security researchers and trademark owners is not going to be set above domain name registrants right to data protection. But I am sure the cybersecurity community can come up with a more creative way of preserving cybersecurity without relying on using personal information of domain name registrants and violating their rights! Farzaneh In article <23257.12824.250276.763926 at gargle.gargle.HOWL> you write: >So you think restricting WHOIS access will protect dissidents from >abusive governments? > >Of all the rationalizations that one seems particularly weak. Oh, you're missing the point. This is a meme that's been floating around in academia for a decade: the brave dissident who somehow has managed to find web hosting, e-mail, broadband, and mobile phone service but for whom nothing stands between her and certain death but the proxy whois on her vanity domain. If someone makes this argument you can be 100% sure he's parroting something he heard somewhere and has no idea how the Internet actually works. ________________________________ From: NANOG on behalf of John Levine Sent: Thursday, April 19, 2018 10:43 PM To: nanog at nanog.org Cc: bzs at theworld.com Subject: Re: Is WHOIS going to go away? In article <23257.12824.250276.763926 at gargle.gargle.HOWL> you write: >So you think restricting WHOIS access will protect dissidents from >abusive governments? > >Of all the rationalizations that one seems particularly weak. Oh, you're missing the point. This is a meme that's been floating around in academia for a decade: the brave dissident who somehow has managed to find web hosting, e-mail, broadband, and mobile phone service but for whom nothing stands between her and certain death but the proxy whois on her vanity domain. If someone makes this argument you can be 100% sure he's parroting something he heard somewhere and has no idea how the Internet actually works. R's, John From werzacabak at gmail.com Fri Apr 20 22:37:06 2018 From: werzacabak at gmail.com (howard stearn) Date: Fri, 20 Apr 2018 16:37:06 -0600 Subject: Experience with CER 2000/MLXe/SLX/VDX Message-ID: Contact me off-list. (Unless you want to share publicly.) I'm interested in knowing if anyone has information about their transition from Brocade to Avgo/Broadcom to Extreme and if the transition was seamless and ended up well. Please tell me a little about your self. How you were a customer / partner, and what your experience has been transitioning to Extreme. I'm also curious if anyone has insider stories about Avgo purchasing Broadcom, and if has any wider implications than Wikipedia is rendering. -HS From i.grok at comcast.net Fri Apr 20 09:06:22 2018 From: i.grok at comcast.net (Scott Schmit) Date: Fri, 20 Apr 2018 05:06:22 -0400 Subject: Is WHOIS going to go away? In-Reply-To: <23257.25098.986869.224276@gargle.gargle.HOWL> References: <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> Message-ID: <20180420090622.GA50704@odin.ulthar.us> On Thu, Apr 19, 2018 at 11:44:10PM -0400, bzs at theworld.com wrote: > So the net result maybe isn't all that terrible unless you have a good > reason to hide your information even from your registrar (and ICANN), > checking a privacy option won't accomplish that, they still have your > info they're just not revealing it via WHOIS. Bear in mind that not all TLDs allow enabling privacy (e.g., .us). From saku at ytti.fi Tue Apr 24 15:31:39 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 24 Apr 2018 18:31:39 +0300 Subject: China Showdown Huawei vs ZTE In-Reply-To: References: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> Message-ID: On 20 April 2018 at 16:44, Colton Conor wrote: > Yes looks like they are both under pressure. I feel bad for the USA based > employees. I know Huawei has quite a few in Plano, Texas. Feel sorry for US based consumers. Historically protectionism always hurts the local economy most. By creating artificial demand on local products, over time local products become uncompetitive for export. I wonder, in what fundamental way Cisco and Juniper are US products, Huawei and ZTE Chinese products? To me it looks like Cisco has no development on IOS-XR outside India, components and assembly is in China. Shareholders are people holding Vanguard/Blackrock. What makes US company a US company? -- ++ytti From colton.conor at gmail.com Tue Apr 24 16:41:50 2018 From: colton.conor at gmail.com (Colton Conor) Date: Tue, 24 Apr 2018 11:41:50 -0500 Subject: China Showdown Huawei vs ZTE In-Reply-To: References: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> Message-ID: Saku, I do feel bad for US Based consumers as I am one of them! Overall, I find Huawei's solutions to be 1/3 the price of the equivalent Juniper/Cisco. The only the stopping me from buying them is the fear of it being hacked due to the media. Like the S6720-EI is MEF certified, runs MPLS, and is $3500 with a lifetime warranty. Please let me know if anyone else comes close to this number. On Tue, Apr 24, 2018 at 10:31 AM, Saku Ytti wrote: > On 20 April 2018 at 16:44, Colton Conor wrote: > > > Yes looks like they are both under pressure. I feel bad for the USA based > > employees. I know Huawei has quite a few in Plano, Texas. > > Feel sorry for US based consumers. Historically protectionism always > hurts the local economy most. By creating artificial demand on local > products, over time local products become uncompetitive for export. > > I wonder, in what fundamental way Cisco and Juniper are US products, > Huawei and ZTE Chinese products? To me it looks like Cisco has no > development on IOS-XR outside India, components and assembly is in > China. Shareholders are people holding Vanguard/Blackrock. What makes > US company a US company? > > -- > ++ytti > From bzs at theworld.com Tue Apr 24 16:50:23 2018 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 24 Apr 2018 12:50:23 -0400 Subject: Is WHOIS going to go away? In-Reply-To: <20180420090622.GA50704@odin.ulthar.us> References: <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <20180420090622.GA50704@odin.ulthar.us> Message-ID: <23263.24655.940023.761550@gargle.gargle.HOWL> On April 20, 2018 at 05:06 i.grok at comcast.net (Scott Schmit) wrote: > On Thu, Apr 19, 2018 at 11:44:10PM -0400, bzs at theworld.com wrote: > > So the net result maybe isn't all that terrible unless you have a good > > reason to hide your information even from your registrar (and ICANN), > > checking a privacy option won't accomplish that, they still have your > > info they're just not revealing it via WHOIS. > > Bear in mind that not all TLDs allow enabling privacy (e.g., .us). I'm aware of this with .US, is there another example? That's the only one I've ever seen mentioned but there are an Avogadro number of TLDs. Hold on, I found a list...da goog turned up da goog... https://support.google.com/domains/answer/3251242?hl=en .CO.IN, .CO.NZ, .CO.UK, .FR, .IN, .JP, and .US So all are cctlds (country code TLDs), and the first three are for companies (or commercial) which may be what's driving that policy. In many countries if one acts as a commercial entity they must provide public contact information. ICANN (in the metonymous sense) no doubt is aware of this, I wonder if it conflicts with any proposals for this new WHOIS? That page also has a pretty good FAQ on private registration in general. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From SNaslund at medline.com Tue Apr 24 16:50:48 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 24 Apr 2018 16:50:48 +0000 Subject: China Showdown Huawei vs ZTE In-Reply-To: References: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402ACDD71D6@MUNPRDMBXA1.medline.com> > > > Yes looks like they are both under pressure. I feel bad for the USA based > > employees. I know Huawei has quite a few in Plano, Texas. > > Feel sorry for US based consumers. Historically protectionism always > hurts the local economy most. By creating artificial demand on local > products, over time local products become uncompetitive for export. > > I wonder, in what fundamental way Cisco and Juniper are US products, > Huawei and ZTE Chinese products? To me it looks like Cisco has no > development on IOS-XR outside India, components and assembly is in > China. Shareholders are people holding Vanguard/Blackrock. What makes > US company a US company? > Easy one, what law is the company incorporated under? Nothing against the Chinese companies (some of their stuff is really great), but it is admittedly hard to separate China's military industrial complex from their communications suppliers. I can understand other countries not wanting critical infrastructure under their software control given that the Chinese government has been very active in industrial espionage. It is not that a US company cannot be compromised but I think they might at least be held accountable (by their markets) when they get caught. Steven Naslund Chicago IL From saku at ytti.fi Tue Apr 24 16:59:18 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 24 Apr 2018 19:59:18 +0300 Subject: China Showdown Huawei vs ZTE In-Reply-To: <9578293AE169674F9A048B2BC9A081B402ACDD71D6@MUNPRDMBXA1.medline.com> References: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> <9578293AE169674F9A048B2BC9A081B402ACDD71D6@MUNPRDMBXA1.medline.com> Message-ID: On 24 April 2018 at 19:50, Naslund, Steve wrote: > Easy one, what law is the company incorporated under? Nothing against the Chinese companies (some of their stuff is really great), but it is admittedly hard to separate China's military industrial complex from their communications suppliers. I can understand other countries not wanting critical infrastructure under their software control given that the Chinese government has been very active in industrial espionage. It is not that a US company cannot be compromised but I think they might at least be held accountable (by their markets) when they get caught. I'm sure all these companies have legal entities in all countries the operate in. So Huawei in US is US company and Huawei products bought in US from US Huawei are good,. but bad when bought from Huawei China? -- ++ytti From ops.lists at gmail.com Tue Apr 24 17:25:19 2018 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 24 Apr 2018 17:25:19 +0000 Subject: Is WHOIS going to go away? In-Reply-To: References: <23257.12824.250276.763926@gargle.gargle.HOWL>, <20180420024309.DC0F7254665A@ary.qy>, Message-ID: The fun problem here is that anonymity, encryption etc - everything that's good and recommended for privacy and security conscious people - gets heavily used, and early adopted, by criminals, the good ones among whom are paranoid about both these at least so they stay out of prison. If only all registrars and registries would actually act proactively about keeping abuse off their networks. Some do a great job, others do just enough to keep ICANN and the security community off their backs, while still others couldn't care less about either. If we had this level of proactiveness, the problem of whois going away would be far less of an issue. ________________________________ From: NANOG on behalf of Badiei, Farzaneh Sent: Friday, April 20, 2018 9:17:21 AM To: John Levine; nanog at nanog.org Cc: bzs at theworld.com Subject: Re: Is WHOIS going to go away? Dear John, The days when some in the technical community could just discard others arguments by saying that "[you] have no idea how the Internet works" have long passed. I will not get intimidated nor will I step back. Old tricks, won't work, it's as old as the dysfunctional WHOIS and will disappear. Also your last paragraph obliges me to clarify: it's not always a "he" that might be arguing! it's sometimes, though might it be rarely, a "she". No one asked to protect people from their governments (I have heard this before as well). But also people should not be endangered or even minimally disturbed by making their personal information public. There are many many scenarios when personal information can be abused, and governments might not be involved. I might not know as much as you do about how the Internet works. But I know one thing: There will be a change. The convenience of security researchers and trademark owners is not going to be set above domain name registrants right to data protection. But I am sure the cybersecurity community can come up with a more creative way of preserving cybersecurity without relying on using personal information of domain name registrants and violating their rights! Farzaneh In article <23257.12824.250276.763926 at gargle.gargle.HOWL> you write: >So you think restricting WHOIS access will protect dissidents from >abusive governments? > >Of all the rationalizations that one seems particularly weak. Oh, you're missing the point. This is a meme that's been floating around in academia for a decade: the brave dissident who somehow has managed to find web hosting, e-mail, broadband, and mobile phone service but for whom nothing stands between her and certain death but the proxy whois on her vanity domain. If someone makes this argument you can be 100% sure he's parroting something he heard somewhere and has no idea how the Internet actually works. ________________________________ From: NANOG on behalf of John Levine Sent: Thursday, April 19, 2018 10:43 PM To: nanog at nanog.org Cc: bzs at theworld.com Subject: Re: Is WHOIS going to go away? In article <23257.12824.250276.763926 at gargle.gargle.HOWL> you write: >So you think restricting WHOIS access will protect dissidents from >abusive governments? > >Of all the rationalizations that one seems particularly weak. Oh, you're missing the point. This is a meme that's been floating around in academia for a decade: the brave dissident who somehow has managed to find web hosting, e-mail, broadband, and mobile phone service but for whom nothing stands between her and certain death but the proxy whois on her vanity domain. If someone makes this argument you can be 100% sure he's parroting something he heard somewhere and has no idea how the Internet actually works. R's, John From Curtis.Starnes at granburyisd.org Tue Apr 24 18:04:38 2018 From: Curtis.Starnes at granburyisd.org (STARNES, CURTIS) Date: Tue, 24 Apr 2018 18:04:38 +0000 Subject: China Showdown Huawei vs ZTE In-Reply-To: References: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> <9578293AE169674F9A048B2BC9A081B402ACDD71D6@MUNPRDMBXA1.medline.com> Message-ID: -----Original Message----- >From: NANOG On Behalf Of Saku Ytti >Sent: Tuesday, April 24, 2018 11:59 AM >To: Naslund, Steve >Cc: nanog at nanog.org >Subject: Re: China Showdown Huawei vs ZTE >On 24 April 2018 at 19:50, Naslund, Steve wrote: >> Easy one, what law is the company incorporated under? Nothing against the Chinese companies (some of their stuff is really great), but it is admittedly hard to separate China's military industrial complex from their >communications suppliers. I can understand other countries not wanting critical infrastructure under their software control given that the Chinese government has been very active in industrial espionage. It is not that a US >company cannot be compromised but I think they might at least be held accountable (by their markets) when they get caught. >I'm sure all these companies have legal entities in all countries the operate in. So Huawei in US is US company and Huawei products bought in US from US Huawei are good,. but bad when bought from Huawei China? > -- > ++ytti From what I have read, any Huawei product purchases fell under scrutiny but after this came about Huawei announced they were going to pull out of U.S. markets. https://www.forbes.com/sites/jeanbaptiste/2018/04/19/analyst-chinas-huawei-to-quit-u-s-market/#2a0839d311cb From aaron1 at gvtc.com Tue Apr 24 18:06:43 2018 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 24 Apr 2018 13:06:43 -0500 Subject: China Showdown Huawei vs ZTE In-Reply-To: References: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> Message-ID: <8B28C61D-30B6-4531-B089-B3C0732DB45A@gvtc.com> Excuse my lack of knowledge... What does this mean? "Shareholders are people holding Vanguard/Blackrock." Aaron > On Apr 24, 2018, at 10:31 AM, Saku Ytti wrote: > > Shareholders are people holding Vanguard/Blackrock. From Sam at SanDiegoBroadband.com Tue Apr 24 18:07:30 2018 From: Sam at SanDiegoBroadband.com (Sam Norris) Date: Tue, 24 Apr 2018 11:07:30 -0700 Subject: Amazon Geolocation Message-ID: <297301d3dbf7$1e98c5d0$5bca5170$@SanDiegoBroadband.com> Hey all, Having a hard time finding someone within Amazon to understand geolocation problems. We have lots of customers that started getting the amazon prime video message about not being able to watch because of geolocation / vpn restrictions. We are a wisp. We run BGP with our own netblocks and upstream netblocks. We have at least 15 customers that have reported this problem - many of which opened tickets directly with amazon but they have no clue. My guess is its related to entire netblocks. MaxMind shows the correct info and always has. Can someone point me to a contact at Amazon that can help? Thx, Sam From saku at ytti.fi Tue Apr 24 18:20:45 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 24 Apr 2018 21:20:45 +0300 Subject: China Showdown Huawei vs ZTE In-Reply-To: <8B28C61D-30B6-4531-B089-B3C0732DB45A@gvtc.com> References: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> <8B28C61D-30B6-4531-B089-B3C0732DB45A@gvtc.com> Message-ID: Hey Aaron, > Excuse my lack of knowledge... What does this mean? "Shareholders are people holding Vanguard/Blackrock." Funds which are largest owners of Cisco shares. -- ++ytti From hugge at nordu.net Tue Apr 24 18:35:17 2018 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Tue, 24 Apr 2018 20:35:17 +0200 Subject: The story about MyEtherWallet.com hijack or how to become a millionare in 2 hours. Message-ID: <318b97db-8ebf-e4ff-b0ef-7a1d5f5c1b4c@nordu.net> Aloha. Surprised this hasnt "made the news" over at this list yet. https://doublepulsar.com/hijack-of-amazons-internet-domain-service-used-to-reroute-web-traffic-for-two-hours-unnoticed-3a6f0dda6a6f https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/2teeVLJ44RM/Yqk5GHSpCQAJ https://twitter.com/barton_paul/status/988788348272734217 TLDR; So it seems that AS10297 (some small hostingprovider in the US) suddenly started to announce de-aggregated AWS IP-space, containing quite alot of Route53 infrastructure, put up resolvers on their own on the hijacked IP-space and pointed *ATLEAST* www.myetherwallet.com to a ip-address that seems to be some kind of transparent proxy out of russia with a bogus SSL-cert (but still pretty good) (https://46.161.42.42/) I did digging in my own logs and played it through BGP-play - seems like it was in fact only Hurricane Electric (6939) that actually propagated this prefix to the Internet. Which makes sense since we have seen them being part of the problem in almost all recent hijacks. Can we do some collaborative digging in other tools you have handy (i guess thousand eyes probes etc could be of help here) to track how big the propagation was? Being abit involved in the Ethereum world it could be noted that the login to MyEtherWallet.com is abit special since you actually login with you wallet-seed and not user/pass to the site... giving the possibility to make really swift transfers without having actual access to the real site (for good ....and bad). -- hugge @ 2603 From SNaslund at medline.com Tue Apr 24 18:45:19 2018 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 24 Apr 2018 18:45:19 +0000 Subject: China Showdown Huawei vs ZTE In-Reply-To: References: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> <9578293AE169674F9A048B2BC9A081B402ACDD71D6@MUNPRDMBXA1.medline.com> Message-ID: <9578293AE169674F9A048B2BC9A081B402ACDD72F1@MUNPRDMBXA1.medline.com> >I'm sure all these companies have legal entities in all countries the operate in. So Huawei in US is US company and Huawei products bought in US from US Huawei are good,. but bad >when bought from Huawei China? IANAL however I was a network engineer for the US Air Force for over ten years. Here is how the US DoD looks at it. There are three tiers of defense contractors. Yes - Cisco, Juniper and other US controller entities that the DoD has already vetted and does business with on a routine basis. Also includes systems pre-integrated by defense contractors like Boeing and Lockheed that are sold as complete turn-key systems. Maybe - Allied (usually NATO) defense contractors that also have vetted security policy. That would be companies like BAE Systems, Dausault, and Siemens. This would also include US suppliers that may never have done business with the DoD before and would have to undergo further review prior to being awarded a contract. There are also some "buy American" consideration that required us to use US suppliers unless there was a valid reason why the foreign manufacturer was the better choice (say we have an air defense system from BAE that has been designed to work with a specific device as part of a system). That is an economic/political concern in addition to the security concern and is covered under contracting regulations. No way - entities considered to be under to control of or part of the military industrial complex of rival nations. That would include most Russian, Chinese, Iranian, etc companies. Also companies that refuse to comply with certain government sanctions or disclosure requirements. Also companies that employ specifically banned individuals under the export control act. This is not necessarily a technical legal thing like having a corporate entity in the US (every multinational does), it is an intelligence assessment of risk. For sensitive software there is a long laundry list of requirements surrounding source code control and signing. In almost all cases I am aware of the US DoD acquires a Restricted Software License which actually means that they have access to view to source code for whatever they are running and require a cryptographically secure way of knowing the running code matches. For many of the systems I worked with there were actually special software loads signed by DISA (Defense Information Systems Agency) that we had to run. DISA software loads also tended to block certain configurations known to be insecure and a lot of times enforced higher security or encryption requirement. Our hardware had to come off a list of approved devices and in very sensitive service the device were sent to an NSA lab for analysis and returned under courier control before they could enter certain areas or networks. If the device ever exited the facility they had to go back for recertification. This was for assurance against embedded hardware taps or bugging devices. They also compared the device against known good models to make sure the hardware was the same. The US Government considers Huawei and ZTE to have "close ties" to the Chinese government according to the Director of National Intelligence along with the heads of CIA, FBI, and the NSA as stated in testimony before the Senate Intelligence Committee. The founder of Huawei is the former engineering officer of the People's Liberation Army of China. Now, this only applies to US Government agencies according to their acquisition rules but there have been moves by the FCC to ban these devices from US cellular network. I am not advocating for or against any of these policies and you can run what you want (assuming it can be imported). I myself would be nervous running Huawei code in a device if a cyber war broke out between the US and China. Steven Naslund Chicago IL From johnl at iecc.com Tue Apr 24 18:56:35 2018 From: johnl at iecc.com (John Levine) Date: 24 Apr 2018 14:56:35 -0400 Subject: Is WHOIS going to go away? In-Reply-To: Message-ID: <20180424185635.E3B352577B19@ary.qy> In article you write: >The days when some in the technical community could just discard others arguments by saying that "[you] have no idea how the >Internet works" have long passed. I will not get intimidated nor will I step back. Old tricks, won't work, it's as old as the >dysfunctional WHOIS and will disappear. Now I'm confused. Surely you do not mean that we should take your arguments seriously even though you have no idea how the Internet works. In my experience, the nanog crowd can be grumpy but it is entirely open to discussions that are based on facts and an understanding of the issues. R's, John From amitchell at isipp.com Tue Apr 24 19:00:51 2018 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Tue, 24 Apr 2018 13:00:51 -0600 Subject: Amazon Geolocation In-Reply-To: <297301d3dbf7$1e98c5d0$5bca5170$@SanDiegoBroadband.com> References: <297301d3dbf7$1e98c5d0$5bca5170$@SanDiegoBroadband.com> Message-ID: <79C43C96-B2C1-40C8-8F9D-7E32D17F4105@isipp.com> Sam, may I share this with our Amazon contacts? Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Attorney at Law / Legislative Consultant GDPR Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Author: The Email Deliverability Handbook Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center > > Hey all, > > Having a hard time finding someone within Amazon to understand geolocation > problems. We have lots of customers that started getting the amazon prime video > message about not being able to watch because of geolocation / vpn restrictions. > > We are a wisp. We run BGP with our own netblocks and upstream netblocks. We > have at least 15 customers that have reported this problem - many of which > opened tickets directly with amazon but they have no clue. My guess is its > related to entire netblocks. > > MaxMind shows the correct info and always has. > > Can someone point me to a contact at Amazon that can help? > > Thx, > Sam > > > > From adam at nectolab.io Tue Apr 24 19:07:53 2018 From: adam at nectolab.io (Adam Montgomery) Date: Tue, 24 Apr 2018 19:07:53 +0000 Subject: Amazon Geolocation In-Reply-To: <79C43C96-B2C1-40C8-8F9D-7E32D17F4105@isipp.com> References: <297301d3dbf7$1e98c5d0$5bca5170$@SanDiegoBroadband.com> <79C43C96-B2C1-40C8-8F9D-7E32D17F4105@isipp.com> Message-ID: Hey Sam, we had the same problem and were able to get it resolved (and help a few others get unblocked as well). Shoot me the affected blocks off-list and I'll forward them along. Adam On Tue, Apr 24, 2018 at 12:03 PM Anne P. Mitchell Esq. wrote: > Sam, may I share this with our Amazon contacts? > > Anne > > Anne P. Mitchell, > Attorney at Law > CEO/President, > SuretyMail Email Reputation Certification and Inbox Delivery Assistance > http://www.SuretyMail.com/ > http://www.SuretyMail.eu/ > > Attorney at Law / Legislative Consultant > GDPR Compliance Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Author: The Email Deliverability Handbook > Legal Counsel: The CyberGreen Institute > Legal Counsel: The Earth Law Center > > > > > > Hey all, > > > > Having a hard time finding someone within Amazon to understand > geolocation > > problems. We have lots of customers that started getting the amazon > prime video > > message about not being able to watch because of geolocation / vpn > restrictions. > > > > We are a wisp. We run BGP with our own netblocks and upstream > netblocks. We > > have at least 15 customers that have reported this problem - many of > which > > opened tickets directly with amazon but they have no clue. My guess is > its > > related to entire netblocks. > > > > MaxMind shows the correct info and always has. > > > > Can someone point me to a contact at Amazon that can help? > > > > Thx, > > Sam > > > > > > > > > > > From amitchell at isipp.com Tue Apr 24 19:35:25 2018 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Tue, 24 Apr 2018 13:35:25 -0600 Subject: Amazon Geolocation In-Reply-To: <297301d3dbf7$1e98c5d0$5bca5170$@SanDiegoBroadband.com> References: <297301d3dbf7$1e98c5d0$5bca5170$@SanDiegoBroadband.com> Message-ID: <7FE6CBB9-F5E9-4197-B7BD-59A316E5A103@isipp.com> We have been told that the best, most expeditious way to get this resolved is: "https://www.amazonforum.com/forums/digital-content/prime-video, it's actively monitored, and confirmed issues are escalated to the correct engineering team." Anne Anne P. Mitchell, Attorney at Law CEO/President, SuretyMail Email Reputation Certification and Inbox Delivery Assistance http://www.SuretyMail.com/ http://www.SuretyMail.eu/ Attorney at Law / Legislative Consultant GDPR Compliance Consultant Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Author: The Email Deliverability Handbook Legal Counsel: The CyberGreen Institute Legal Counsel: The Earth Law Center From hugge at nordu.net Tue Apr 24 20:03:46 2018 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Tue, 24 Apr 2018 22:03:46 +0200 Subject: The story about MyEtherWallet.com hijack or how to become a millionare in 2 hours. In-Reply-To: References: <318b97db-8ebf-e4ff-b0ef-7a1d5f5c1b4c@nordu.net> Message-ID: "that depends". we for sure know that 150K or so got immediately snatched of the bat, but how much more wallets is at stake? no one knows. What is known however is that they are trying to deploy smokescreens with tons of transfers moving ETH around wallets and all seems to be ending up sooner or later in this account. https://etherscan.io/address/0xb3aaaae47070264f3595c5032ee94b620a583a39 Which is good for 17MUSD. That doesn't really matter though - i wanna speak what we do about this in the DFZ. Can someone from HE comment on how your ingress route-filtering policy looks like towards your customers? I typically base my peering-relationships on people/operators that i have some kind of level of trust in. > Is MyEtherWallet really doing 500k/hr in business though? > >> On Apr 24, 2018, at 2:35 PM, Fredrik Korsbäck wrote: >> >> Aloha. >> >> Surprised this hasnt "made the news" over at this list yet. >> >> https://doublepulsar.com/hijack-of-amazons-internet-domain-service-used-to-reroute-web-traffic-for-two-hours-unnoticed-3a6f0dda6a6f >> >> https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/2teeVLJ44RM/Yqk5GHSpCQAJ >> >> https://twitter.com/barton_paul/status/988788348272734217 >> >> TLDR; So it seems that AS10297 (some small hostingprovider in the US) suddenly started to announce de-aggregated AWS >> IP-space, containing quite alot of Route53 infrastructure, put up resolvers on their own on the hijacked IP-space and >> pointed *ATLEAST* www.myetherwallet.com to a ip-address that seems to be some kind of transparent proxy out of russia >> with a bogus SSL-cert (but still pretty good) (https://46.161.42.42/) >> >> I did digging in my own logs and played it through BGP-play - seems like it was in fact only Hurricane Electric (6939) >> that actually propagated this prefix to the Internet. Which makes sense since we have seen them being part of the >> problem in almost all recent hijacks. >> >> Can we do some collaborative digging in other tools you have handy (i guess thousand eyes probes etc could be of help >> here) to track how big the propagation was? >> >> Being abit involved in the Ethereum world it could be noted that the login to MyEtherWallet.com is abit special since >> you actually login with you wallet-seed and not user/pass to the site... giving the possibility to make really swift >> transfers without having actual access to the real site (for good ....and bad). >> >> -- >> hugge @ 2603 >> > -- hugge From saku at ytti.fi Tue Apr 24 20:10:51 2018 From: saku at ytti.fi (Saku Ytti) Date: Tue, 24 Apr 2018 23:10:51 +0300 Subject: China Showdown Huawei vs ZTE In-Reply-To: <9578293AE169674F9A048B2BC9A081B402ACDD72F1@MUNPRDMBXA1.medline.com> References: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> <9578293AE169674F9A048B2BC9A081B402ACDD71D6@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD72F1@MUNPRDMBXA1.medline.com> Message-ID: On 24 April 2018 at 21:45, Naslund, Steve wrote: Hey, > The US Government considers Huawei and ZTE to have "close ties" to the Chinese government according to the Director of National Intelligence along with the heads of CIA, FBI, and the NSA as stated in testimony before the Senate Intelligence Committee. The founder of Huawei is the former engineering officer of the People's Liberation Army of China. > > Now, this only applies to US Government agencies according to their acquisition rules but there have been moves by the FCC to ban these devices from US cellular network. I am not advocating for or against any of these policies and you can run what you want (assuming it can be imported). I myself would be nervous running Huawei code in a device if a cyber war broke out between the US and China. Thank you for the insight, quite interesting. Call me naive, but I don't think sticker in device has any implications on security, as components and code are sourced through complicated chains through various jurisdictions. Let's assume for a moment that attacker is NSA, I don't think that NSA would want to even push project through Cisco or Apple via official channels, even if legally allowed, to get some secret backdoor installed, because too many people would be involved in the project and controlling the information would become challenging. Two years from now lot of those involved people might be in different company or different country, how to avoid them from exposing the information? It seems much better vector would be to target individual person with commit rights, ensure you have leverage over them, then ask them to commit specific set of abstruse code, which is likely to pass code review but introduce functionality which benefits your agenda. Even if this one person would talk, would they know it was NSA, if they knew, would anyone believe them? Why would China work differently? Why not pwn one Cisco employee in India to get the code in that the party sees beneficial? -- ++ytti From bortzmeyer at nic.fr Tue Apr 24 20:17:51 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 24 Apr 2018 22:17:51 +0200 Subject: The story about MyEtherWallet.com hijack or how to become a millionare in 2 hours. In-Reply-To: <318b97db-8ebf-e4ff-b0ef-7a1d5f5c1b4c@nordu.net> References: <318b97db-8ebf-e4ff-b0ef-7a1d5f5c1b4c@nordu.net> Message-ID: <20180424201751.hqt4dgy4yhq655fy@nic.fr> On Tue, Apr 24, 2018 at 08:35:17PM +0200, Fredrik Korsbäck wrote a message of 28 lines which said: > Surprised this hasnt "made the news" over at this list yet. It may be also because NANOG email is handled by Google, who broke its antispam: : host aspmx.l.google.com[2a00:1450:400c:c08::1a] said: 550-5.7.1 This message does not have authentication information or fails to pass 550-5.7.1 authentication checks. To best protect our users from spam, the 550-5.7.1 message has been blocked. Please visit 550-5.7.1 https://support.google.com/mail/answer/81126#authentication for more 550 5.7.1 information. v20-v6si12240130wrb.82 - gsmtp (in reply to end of DATA command) From hugge at nordu.net Tue Apr 24 20:22:19 2018 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Tue, 24 Apr 2018 22:22:19 +0200 Subject: The story about MyEtherWallet.com hijack or how to become a millionare in 2 hours. In-Reply-To: <20180424200716.ifrcgbukijsqddfh@nic.fr> References: <318b97db-8ebf-e4ff-b0ef-7a1d5f5c1b4c@nordu.net> <20180424200716.ifrcgbukijsqddfh@nic.fr> Message-ID: <674f8728-4eb2-c079-8e15-6a5cbd2e8761@nordu.net> Well there is quite abit of data around that particular server. So it definitely happened. https://twitter.com/GossiTheDog/status/988873775285460992 This tweet is a good start. The server answer to me right now and google safe browsing has flagged it as well for being insecure (no the regular cert-fail warning but deceptivness warning) The SSL-cert is a self-signed one impersonating MyEtherWallet.com. Id take it that 15169 accepted the prefix for some reason over a bilateral peering-sesssion (to the best of my knowledge the equinix routeservers does indeed do filter, but please correct me on this one) with 10297 and hence poisoned the 8.8.8.8 resolver for some time with the wrong ip-addr. > On Tue, Apr 24, 2018 at 08:35:17PM +0200, > Fredrik Korsbäck wrote > a message of 28 lines which said: > >> Surprised this hasnt "made the news" over at this list yet. > > It was discussed several hours before on the Outages mailing list. > > Also, there are not a lot of hard facts. The BGP hijacking is clear > and easy to find in the usual places. > > The supposed rogue DNS server is much more elusive. Nobody apparently > thought of querying it with dig during the hijack. There are reports > of people being directed to a rogue www.myetherwallet.com but, again, > no detail, no IP address, not the certificate of the rogue server, > nothing. > >> seems to be some kind of transparent proxy out of russia with a >> bogus SSL-cert (but still pretty good) (https://46.161.42.42/) > > DNSDB does not confirm this: > > % isc-dnsdb-query rdata ip 46.161.42.42 > pigroot.sciencesupply.eu. IN A 46.161.42.42 > value.rollliquid.com. IN A 46.161.42.42 > campsprings.collaspepaw.com. IN A 46.161.42.42 > bronchopneumonic.collaspepaw.com. IN A 46.161.42.42 > server42.woodorganism.com. IN A 46.161.42.42 > ;;; Returned 5 RRs in 0.03 seconds. > ;;; DNSDB > > Currently, this machine does not accept connections. > > > > -- hugge From jbates at paradoxnetworks.net Tue Apr 24 20:34:47 2018 From: jbates at paradoxnetworks.net (Jack Bates) Date: Tue, 24 Apr 2018 15:34:47 -0500 Subject: The story about MyEtherWallet.com hijack or how to become a millionare in 2 hours. In-Reply-To: <318b97db-8ebf-e4ff-b0ef-7a1d5f5c1b4c@nordu.net> References: <318b97db-8ebf-e4ff-b0ef-7a1d5f5c1b4c@nordu.net> Message-ID: On 4/24/2018 1:35 PM, Fredrik Korsbäck wrote: > Surprised this hasnt "made the news" over at this list yet. > In the old days, the list membership would have noticed the hijack. BGP hijacks used to be a somewhat popular topic, but like spammer chasing, I think everyone grew bored of it and the lack of things actually being done. > TLDR; So it seems that AS10297 (some small hostingprovider in the US) suddenly started to announce de-aggregated AWS > IP-space, containing quite alot of Route53 infrastructure, put up resolvers on their own on the hijacked IP-space and > pointed *ATLEAST* www.myetherwallet.com to a ip-address that seems to be some kind of transparent proxy out of russia > with a bogus SSL-cert (but still pretty good) (https://46.161.42.42/) > > Why did they use a self-signed cert? If you control the dns or the endpoint, you can easily get a signed cert. Given how lax people were at detecting this, they would have gotten further if people hadn't been complaining about the cert notification. Jack From job at ntt.net Tue Apr 24 20:35:38 2018 From: job at ntt.net (Job Snijders) Date: Tue, 24 Apr 2018 20:35:38 +0000 Subject: The story about MyEtherWallet.com hijack or how to become a millionare in 2 hours. In-Reply-To: <674f8728-4eb2-c079-8e15-6a5cbd2e8761@nordu.net> References: <318b97db-8ebf-e4ff-b0ef-7a1d5f5c1b4c@nordu.net> <20180424200716.ifrcgbukijsqddfh@nic.fr> <674f8728-4eb2-c079-8e15-6a5cbd2e8761@nordu.net> Message-ID: <20180424203538.GH84035@vurt.meerval.net> On Tue, Apr 24, 2018 at 10:22:19PM +0200, Fredrik Korsbäck wrote: > Id take it that 15169 accepted the prefix for some reason over a > bilateral peering-sesssion (to the best of my knowledge the equinix > routeservers does indeed do filter, but please correct me on this one) > with 10297 and hence poisoned the 8.8.8.8 resolver for some time with > the wrong ip-addr. I have no reason to believe the Equinix route servers propagated or contributed to this hijack, I checked with them. It is a good thing their route server has filters, otherwise the damage could've been even worse! Kind regards, Job From bryan at shout.net Tue Apr 24 22:52:51 2018 From: bryan at shout.net (Bryan Holloway) Date: Tue, 24 Apr 2018 17:52:51 -0500 Subject: Amazon Geolocation In-Reply-To: <7FE6CBB9-F5E9-4197-B7BD-59A316E5A103@isipp.com> References: <297301d3dbf7$1e98c5d0$5bca5170$@SanDiegoBroadband.com> <7FE6CBB9-F5E9-4197-B7BD-59A316E5A103@isipp.com> Message-ID: Best. URL. Ever. ;) On 4/24/18 2:35 PM, Anne P. Mitchell Esq. wrote: > We have been told that the best, most expeditious way to get this resolved is: > > "https://www.amazonforum.com/forums/digital-content/prime-video, it's actively monitored, and confirmed issues are escalated to the correct engineering team." > > Anne > > Anne P. Mitchell, > Attorney at Law > CEO/President, > SuretyMail Email Reputation Certification and Inbox Delivery Assistance > http://www.SuretyMail.com/ > http://www.SuretyMail.eu/ > > Attorney at Law / Legislative Consultant > GDPR Compliance Consultant > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Author: The Email Deliverability Handbook > Legal Counsel: The CyberGreen Institute > Legal Counsel: The Earth Law Center > From dcorbe at hammerfiber.com Tue Apr 24 18:59:05 2018 From: dcorbe at hammerfiber.com (Daniel Corbe) Date: Tue, 24 Apr 2018 14:59:05 -0400 Subject: The story about MyEtherWallet.com hijack or how to become a millionare in 2 hours. In-Reply-To: <318b97db-8ebf-e4ff-b0ef-7a1d5f5c1b4c@nordu.net> References: <318b97db-8ebf-e4ff-b0ef-7a1d5f5c1b4c@nordu.net> Message-ID: Is MyEtherWallet really doing 500k/hr in business though? > On Apr 24, 2018, at 2:35 PM, Fredrik Korsbäck wrote: > > Aloha. > > Surprised this hasnt "made the news" over at this list yet. > > https://doublepulsar.com/hijack-of-amazons-internet-domain-service-used-to-reroute-web-traffic-for-two-hours-unnoticed-3a6f0dda6a6f > > https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/2teeVLJ44RM/Yqk5GHSpCQAJ > > https://twitter.com/barton_paul/status/988788348272734217 > > TLDR; So it seems that AS10297 (some small hostingprovider in the US) suddenly started to announce de-aggregated AWS > IP-space, containing quite alot of Route53 infrastructure, put up resolvers on their own on the hijacked IP-space and > pointed *ATLEAST* www.myetherwallet.com to a ip-address that seems to be some kind of transparent proxy out of russia > with a bogus SSL-cert (but still pretty good) (https://46.161.42.42/) > > I did digging in my own logs and played it through BGP-play - seems like it was in fact only Hurricane Electric (6939) > that actually propagated this prefix to the Internet. Which makes sense since we have seen them being part of the > problem in almost all recent hijacks. > > Can we do some collaborative digging in other tools you have handy (i guess thousand eyes probes etc could be of help > here) to track how big the propagation was? > > Being abit involved in the Ethereum world it could be noted that the login to MyEtherWallet.com is abit special since > you actually login with you wallet-seed and not user/pass to the site... giving the possibility to make really swift > transfers without having actual access to the real site (for good ....and bad). > > -- > hugge @ 2603 > From hank at efes.iucc.ac.il Wed Apr 25 05:29:08 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 25 Apr 2018 08:29:08 +0300 Subject: The story about MyEtherWallet.com hijack or how to become a millionare in 2 hours. In-Reply-To: <9dbaacc5-88ba-04e3-21f0-87d12365af13@efes.iucc.ac.il> References: <9dbaacc5-88ba-04e3-21f0-87d12365af13@efes.iucc.ac.il> Message-ID: <214f0231-7e1e-090b-624d-8eb2673f7596@efes.iucc.ac.il> On 24/04/2018 21:35, Fredrik Korsbäck wrote: > TLDR; So it seems that AS10297 (some small hostingprovider in the US) suddenly started to announce de-aggregated AWS > IP-space, containing quite alot of Route53 infrastructure, put up resolvers on their own on the hijacked IP-space and > pointed *ATLEAST* www.myetherwallet.com to a ip-address that seems to be some kind of transparent proxy out of russia > with a bogus SSL-cert (but still pretty good) (https://46.161.42.42/) > > I did digging in my own logs and played it through BGP-play - seems like it was in fact only Hurricane Electric (6939) > that actually propagated this prefix to the Internet. Which makes sense since we have seen them being part of the > problem in almost all recent hijacks. In addition to HE there was AS19151 -WV Fiber that accepted the /24s, but based on BGPlay (attached) it seems that the main culprit was HE that propagated it onward. -Hank From hank at efes.iucc.ac.il Wed Apr 25 06:19:58 2018 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 25 Apr 2018 09:19:58 +0300 Subject: The story about MyEtherWallet.com hijack or how to become a millionare in 2 hours. In-Reply-To: <214f0231-7e1e-090b-624d-8eb2673f7596@efes.iucc.ac.il> References: <9dbaacc5-88ba-04e3-21f0-87d12365af13@efes.iucc.ac.il> <214f0231-7e1e-090b-624d-8eb2673f7596@efes.iucc.ac.il> Message-ID: <6cc9c93d-daf6-b8b1-92d0-7955b3312af5@efes.iucc.ac.il> On 25/04/2018 08:29, Hank Nussbacher wrote: > On 24/04/2018 21:35, Fredrik Korsbäck wrote: > >> TLDR; So it seems that AS10297 (some small hostingprovider in the US) suddenly started to announce de-aggregated AWS >> IP-space, containing quite alot of Route53 infrastructure, put up resolvers on their own on the hijacked IP-space and >> pointed *ATLEAST* www.myetherwallet.com to a ip-address that seems to be some kind of transparent proxy out of russia >> with a bogus SSL-cert (but still pretty good) (https://46.161.42.42/) >> >> I did digging in my own logs and played it through BGP-play - seems like it was in fact only Hurricane Electric (6939) >> that actually propagated this prefix to the Internet. Which makes sense since we have seen them being part of the >> problem in almost all recent hijacks. > In addition to HE there was AS19151 -WV Fiber that accepted the /24s, > but based on BGPlay (attached) it seems that the main culprit was HE > that propagated it onward. > > -Hank > Would appear no attachments allowed :-( -Hank From rsk at gsp.org Wed Apr 25 13:04:15 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 25 Apr 2018 09:04:15 -0400 Subject: Is WHOIS going to go away? In-Reply-To: <23257.4316.455617.983247@gargle.gargle.HOWL> References: <20180414140649.GA85820@meow.BKantor.net> <01020162c488c27b-23c30a87-7b09-4b77-bb3d-364ef22fb5a5-000000@eu-west-1.amazonses.com> <87sh7xr919.fsf@mid.deneb.enyo.de> <01020162c5d09d64-c53d25c4-0b1d-4480-9990-ba7bb9bbeb71-000000@eu-west-1.amazonses.com> <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> Message-ID: <20180425130415.GA2389@gsp.org> On Thu, Apr 19, 2018 at 05:57:48PM -0400, bzs at theworld.com wrote: > One of the memes driving this WHOIS change is the old idea of > "starving the beast". > > People involved in policy discussions complain that "spammers" -- many > only marginally fit that term other than by the strictest > interpretation -- use the public WHOIS data to contact domain owners. > > I've countered that 20+ years experience trying to "starve the beast" > by trying to deny them access to email and other casual contact info > has proven the approach to be useless. I've been trying to kill this same meme for years, and it just won't die. It's related to the equally-silly meme that says that email/newsgroup archives should have the addresses of participant obfuscated, and it's just as wrong. Let me make yet one more likely-futile effort: 1. WHOIS data is a poor source of email addresses. It always has been. Much richer ones exist and new ones show up all day, every day. The same can be said for mailing list/newsgroup archives. Moreover, many of those people are poor choices as victims. 2. Those much richer sources include (and this is far from exhaustive): - subscribing to mailing lists - acquiring Usenet news feeds - querying mail servers - acquiring corporate email directories - insecure LDAP servers - insecure AD servers - use of backscatter/outscatter - use of auto-responders - use of mailing list mechanisms - use of abusive "callback" mechanisms - dictionary attacks - construction of plausible addresses (e.g. "firstname.lastname") - purchase of addresses in bulk on the open market. - purchase of addresses from vendors, web sites, etc. - purchase of addresses from registrars, ISPs, web hosts, etc. - domain registration (some registrars ARE spammers) - misplaced/lost/sold media - harvesting of the mail, address books and any other files present on any of the hundreds of millions of compromised systems annnnnnd - the security breach/dataloss incident of the day 3. The bottom line is that, starting about 15 years ago, it became effectively impossible to keep any email address *that is actually used* away from spammers. [1] Simultaneously, it became a best practice to assume this up front and design defenses accordingly. 4. You know who is best-protected by restrictions on WHOIS and obfuscated domain registration? Spammers, phishers, typosquatters, and other abusers. It's not a coincidence that the number of malicious domains has skyrocketed as these practices have spread. (And "skyrocket" is not an exaggeration. I've been studying abuser domains for 15+ years and I have no hesitation saying that easily 90% of all domains are malicious. And that's likely a serious understatement. Why? Because whereas you and I and other NANOG-ish people register one here, one there, whether for professional or personal or other use, abusers are registering them by the tens of thousands and more. Much more.) ---rsk [1] Yes, there are edge cases. I *know*. From rsk at gsp.org Wed Apr 25 13:18:39 2018 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 25 Apr 2018 09:18:39 -0400 Subject: Is WHOIS going to go away? In-Reply-To: <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> References: <20180419142724.GB3500@gsp.org> <23257.4316.455617.983247@gargle.gargle.HOWL> <23257.12824.250276.763926@gargle.gargle.HOWL> <23257.25098.986869.224276@gargle.gargle.HOWL> <23258.15165.925961.963661@gargle.gargle.HOWL> <9578293AE169674F9A048B2BC9A081B402ACDD161F@MUNPRDMBXA1.medline.com> Message-ID: <20180425131839.GB2389@gsp.org> On Fri, Apr 20, 2018 at 07:31:20PM +0000, Naslund, Steve wrote: > I don't see why there should not be a way to know who is publishing data on the Internet. +1 for this and what follows. Allow me, please, to piggyback on it with a similar thought: With great power, comes great responsibility. There is no difference between someone who runs a global network or a worldwide collection of datacenters, and someone who runs a tiny web server or a single domain, other than scale. Both of them enjoy extraordinary power, power that was difficult to imagine even for people with reliable and accurate crystal balls, a quarter century ago. They both operate a piece of the Internet that we share. And they are both responsible to each other -- whatever that means in context. They have to be accountable, because when people are unaccountable we get spam factories and network hijacking and DoS attacks and all the other myriad crap that chews up enormous amounts of time and money. This responsibility, this accountability isn't for everyone. And that's fine. But anyone who isn't up for it *should not sign up to operate a piece of the Internet*. There are a zillion other ways to participate without becoming an operator. ---rsk From me at payam124.com Wed Apr 25 09:33:35 2018 From: me at payam124.com (Payam Poursaied) Date: Wed, 25 Apr 2018 09:33:35 +0000 Subject: Can someone from instagram contact me off list? Message-ID: From keith at contoocook.net Wed Apr 25 14:10:26 2018 From: keith at contoocook.net (keith at contoocook.net) Date: Wed, 25 Apr 2018 10:10:26 -0400 Subject: Is WHOIS going to go away? Message-ID: <3nl6z4nf60nu48y225042018101026@CNWeb01> Well, personally for me, I use secret registration because I was tired of all the spam I got. Spammers scrape whois data for email addresses. I not trying to hide my identity on the web, I just don't like spam. I'm not some dark evil force. Cheers, Keith ----- Original Message ----- From: "Rich Kulawiec" To: Sent: Wednesday, April 25 2018 09:18:54 AM Subject: Re: Is WHOIS going to go away? > On Fri, Apr 20, 2018 at 07:31:20PM +0000, Naslund, Steve wrote: > > I don't see why there should not be a way to know who is publishing data on the Internet. > > +1 for this and what follows. Allow me, please, to piggyback on it > with a similar thought: > > With great power, comes great responsibility. > > There is no difference between someone who runs a global network or > a worldwide collection of datacenters, and someone who runs a tiny > web server or a single domain, other than scale. Both of them enjoy > extraordinary power, power that was difficult to imagine even for > people with reliable and accurate crystal balls, a quarter century ago. > They both operate a piece of the Internet that we share. > > And they are both responsible to each other -- whatever that means > in context. They have to be accountable, because when people are > unaccountable we get spam factories and network hijacking and DoS > attacks and all the other myriad crap that chews up enormous amounts > of time and money. > > This responsibility, this accountability isn't for everyone. And that's > fine. But anyone who isn't up for it *should not sign up to operate a > piece of the Internet*. There are a zillion other ways to participate > without becoming an operator. > > ---rsk > From amitchell at isipp.com Wed Apr 25 14:50:18 2018 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Wed, 25 Apr 2018 08:50:18 -0600 Subject: Is WHOIS going to go away? In-Reply-To: <3nl6z4nf60nu48y225042018101026@CNWeb01> References: <3nl6z4nf60nu48y225042018101026@CNWeb01> Message-ID: <6F107153-CF74-4CFA-9CFE-62035A4253FD@isipp.com> > > Well, personally for me, I use secret registration because I was tired of all the spam I got. Spammers scrape whois data for email addresses. I not trying to hide my identity on the web, I just don't like spam. I'm not some dark evil force. And of course then there's the conventional wisdom that (some) anti-spammers see secret registration as a sign that you are likely a spammer, or otherwise engaged in bad activities. Anne (who is of course professionally trained as a dark evil force ;-) ) Anne P. Mitchell, Attorney at Law GDPR 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 From list at satchell.net Wed Apr 25 15:23:18 2018 From: list at satchell.net (Stephen Satchell) Date: Wed, 25 Apr 2018 08:23:18 -0700 Subject: Is WHOIS going to go away? In-Reply-To: <3nl6z4nf60nu48y225042018101026@CNWeb01> References: <3nl6z4nf60nu48y225042018101026@CNWeb01> Message-ID: On 04/25/2018 07:10 AM, keith at contoocook.net wrote: > Well, personally for me, I use secret registration because I was tired of all the spam I got. Spammers scrape whois data for email addresses. I not trying to hide my identity on the web, I just don't like spam. I'm not some dark evil force. > Cheers, Keith > What I find interesting is that I didn't get all that much spam from my small collection of domains. Of course, the e-mail addresses associated with those domains is "admin at satchell.net" (and "abuse at satchell.net"). Indeed, abuse is completely ignored by spammers, while admin gets a couple of pieces of Far East spam a week. That's right, a week. I bought privacy service now, as well as renewal protection. I've lost three domains, and don't want to lose any more. From joquendo at e-fensive.net Wed Apr 25 15:28:46 2018 From: joquendo at e-fensive.net (J. Oquendo) Date: Wed, 25 Apr 2018 10:28:46 -0500 Subject: Comcast and DGA like behavior Message-ID: <20180425152846.b4bgw62i7o5y5v4l@e-fensive.net> Anyone else seeing DGA (1) like behavior for Comcast based customers? If so, is there any information on it? Seeing a lot of traffic to bogus domains all synonymous with their networks. 1: https://en.wikipedia.org/wiki/Domain_generation_algorithm -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM, GNFA "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 0A96 6318 EA49 4032 21C9 A7A8 81E9 3E95 414F 356E https://pgp.mit.edu/pks/lookup?op=get&search=0x81E93E95414F356E From morrowc.lists at gmail.com Wed Apr 25 15:34:33 2018 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 25 Apr 2018 11:34:33 -0400 Subject: Comcast and DGA like behavior In-Reply-To: <20180425152846.b4bgw62i7o5y5v4l@e-fensive.net> References: <20180425152846.b4bgw62i7o5y5v4l@e-fensive.net> Message-ID: On Wed, Apr 25, 2018 at 11:28 AM, J. Oquendo wrote: > Anyone else seeing DGA (1) like behavior for Comcast based > customers? If so, is there any information on it? Seeing a > lot of traffic to bogus domains all synonymous with their > networks. > don't they have a anti-botnet-automagic-walled-garden thing that's supposed to stop this? (also, example request RRs?) From aaron at heyaaron.com Wed Apr 25 15:39:56 2018 From: aaron at heyaaron.com (Aaron C. de Bruyn) Date: Wed, 25 Apr 2018 15:39:56 +0000 Subject: Is WHOIS going to go away? In-Reply-To: References: <3nl6z4nf60nu48y225042018101026@CNWeb01> Message-ID: You must be doing something wrong. ;) After registering a new domain name, I get ~10 poorly worded emails trying to convince me a I need professional web development services. I also get ~15 phone calls over a few weeks from very thick accents and call-center noise in the background telling me that I need professional web development services or search engine optimization. There's usually 1 or 2 calls with the same characteristics telling me that they work for Google and have noticed a problem with my 'listing' for my new site and I need to have them correct it for a small fee because that's how Google makes money. The phone calls don't happen if I use private registration. ;) -A On Wed, Apr 25, 2018 at 8:25 AM Stephen Satchell wrote: > On 04/25/2018 07:10 AM, keith at contoocook.net wrote: > > Well, personally for me, I use secret registration because I was tired > of all the spam I got. Spammers scrape whois data for email addresses. I > not trying to hide my identity on the web, I just don't like spam. I'm not > some dark evil force. > > Cheers, Keith > > > > What I find interesting is that I didn't get all that much spam from my > small collection of domains. Of course, the e-mail addresses associated > with those domains is "admin at satchell.net" (and "abuse at satchell.net"). > Indeed, abuse is completely ignored by spammers, while admin gets a > couple of pieces of Far East spam a week. That's right, a week. > > I bought privacy service now, as well as renewal protection. I've lost > three domains, and don't want to lose any more. > From fergdawgster at mykolab.com Wed Apr 25 15:40:19 2018 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Wed, 25 Apr 2018 08:40:19 -0700 Subject: Comcast and DGA like behavior In-Reply-To: References: <20180425152846.b4bgw62i7o5y5v4l@e-fensive.net> Message-ID: <9ABB379E-96FA-4C6A-AF69-B611846AC342@mykolab.com> > On Apr 25, 2018, at 8:34 AM, Christopher Morrow wrote: > > On Wed, Apr 25, 2018 at 11:28 AM, J. Oquendo wrote: >> Anyone else seeing DGA (1) like behavior for Comcast based >> customers? If so, is there any information on it? Seeing a >> lot of traffic to bogus domains all synonymous with their >> networks. >> > > don't they have a anti-botnet-automagic-walled-garden thing that's > supposed to stop this? > (also, example request RRs?) If a residential broadband consumer’s computer gets pwned, there’s nothing really stopping a criminal from registering any sort of domain/hostname and pointing a DNS A record at it. In fact, that’s pretty routine. But the aspect that it could be a DGA is a bit more difficult insofar as planning and logistics, but not improbable, methinks. - ferg — Paul Ferguson ICEBRG.io Seattle, Washington, USA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Message signed with OpenPGP URL: From rob at invaluement.com Wed Apr 25 17:47:24 2018 From: rob at invaluement.com (Rob McEwen) Date: Wed, 25 Apr 2018 13:47:24 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <3nl6z4nf60nu48y225042018101026@CNWeb01> Message-ID: On 4/25/2018 11:39 AM, Aaron C. de Bruyn via NANOG wrote: > don't happen if I use private registration SUGGESTION: Initially register with private registration - then change it to regular non-hidden registration a few weeks later or so. (hopefully before putting it into production, especially if used for/with/in emails) I think this will cut down on the majority of those crazy spam phone calls. -- Rob McEwen https://www.invaluement.com From rubensk at gmail.com Wed Apr 25 17:52:54 2018 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 25 Apr 2018 14:52:54 -0300 Subject: Is WHOIS going to go away? In-Reply-To: References: <3nl6z4nf60nu48y225042018101026@CNWeb01> Message-ID: On Wed, Apr 25, 2018 at 2:47 PM, Rob McEwen wrote: > On 4/25/2018 11:39 AM, Aaron C. de Bruyn via NANOG wrote: > >> don't happen if I use private registration >> > > > SUGGESTION: Initially register with private registration - then change it > to regular non-hidden registration a few weeks later or so. (hopefully > before putting it into production, especially if used for/with/in emails) I > think this will cut down on the majority of those crazy spam phone calls. I sometimes get those e-mails a few months after registration. So while your suggestion will cut down a part of it, there will still be a good chunk left. And when it comes up for renewal, it gets up again. Rubens From rob at invaluement.com Wed Apr 25 18:02:11 2018 From: rob at invaluement.com (Rob McEwen) Date: Wed, 25 Apr 2018 14:02:11 -0400 Subject: Is WHOIS going to go away? In-Reply-To: <6F107153-CF74-4CFA-9CFE-62035A4253FD@isipp.com> References: <3nl6z4nf60nu48y225042018101026@CNWeb01> <6F107153-CF74-4CFA-9CFE-62035A4253FD@isipp.com> Message-ID: <847740a9-a1de-b9f1-614b-a8da542fb1fb@invaluement.com> On 4/25/2018 10:50 AM, Anne P. Mitchell Esq. wrote: > And of course then there's the conventional wisdom that (some) anti-spammers see secret registration as a sign that you are likely a spammer, or otherwise engaged in bad activities For example: http://www.spamresource.com/2010/02/whois-privacy-protect-what-spamfighters.html (and I concur... although I do understand the frustration about the phone spam, too - I recently registered a dozen domains and I was getting 10+ calls a day for weeks - which I why I recommend starting with a hidden registration - then switching to an unhidden registration some weeks later. This isn't a perfect solution, but it helps since the hit freshly registered domains the hardest.) -- Rob McEwen https://www.invaluement.com From alan.buxey at gmail.com Thu Apr 26 12:38:18 2018 From: alan.buxey at gmail.com (Alan Buxey) Date: Thu, 26 Apr 2018 13:38:18 +0100 Subject: China Showdown Huawei vs ZTE In-Reply-To: References: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> <9578293AE169674F9A048B2BC9A081B402ACDD71D6@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD72F1@MUNPRDMBXA1.medline.com> Message-ID: https://www.theregister.co.uk/2018/04/26/hyperoptics_zte_routers/ yet another ZTE issue . :( alan From saku at ytti.fi Thu Apr 26 12:48:58 2018 From: saku at ytti.fi (Saku Ytti) Date: Thu, 26 Apr 2018 15:48:58 +0300 Subject: China Showdown Huawei vs ZTE In-Reply-To: References: <643827B5-9B5F-41EC-B46D-72972C8AC0DE@gmail.com> <9578293AE169674F9A048B2BC9A081B402ACDD71D6@MUNPRDMBXA1.medline.com> <9578293AE169674F9A048B2BC9A081B402ACDD72F1@MUNPRDMBXA1.medline.com> Message-ID: https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10819 https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10713 https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180307-cpcp https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170405-ame I think quite careful analysis would be needed to draw any conclusion if there are statistically relevant difference in security issues. After I fixed my tinfoil hat with some duct tape, I can say that to me the ScreenOS particularly doesn't look like just someone forgot some development backdoor to release software, but rather looks like someone intentionally sneaked backdoor to software, which doesn't look like backdoor. But it's hard to say for sure which are incompetency and which are malice. On 26 April 2018 at 15:38, Alan Buxey wrote: > https://www.theregister.co.uk/2018/04/26/hyperoptics_zte_routers/ > > yet another ZTE issue . :( > > alan -- ++ytti From valdis.kletnieks at vt.edu Thu Apr 26 13:14:14 2018 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 26 Apr 2018 09:14:14 -0400 Subject: Is WHOIS going to go away? In-Reply-To: References: <3nl6z4nf60nu48y225042018101026@CNWeb01> Message-ID: <6123.1524748454@turing-police.cc.vt.edu> On Wed, 25 Apr 2018 13:47:24 -0400, Rob McEwen said: > SUGGESTION: Initially register with private registration - then change > it to regular non-hidden registration a few weeks later or so. That will work for about 2 weeks - until the people who currently run automated software looking for new registrations to spam fix their software to lurk until the new registration becomes non-hidden. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From nanog at ics-il.net Thu Apr 26 13:24:31 2018 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 26 Apr 2018 08:24:31 -0500 (CDT) Subject: Is WHOIS going to go away? In-Reply-To: <6123.1524748454@turing-police.cc.vt.edu> References: <3nl6z4nf60nu48y225042018101026@CNWeb01> <6123.1524748454@turing-police.cc.vt.edu> Message-ID: <108426597.1488.1524749068837.JavaMail.mhammett@ThunderFuck> I think I have received more e-mails from NANOG about WHOIS-derived SPAM in the past week than I have received actual WHOIS-derived SPAM in the past year. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "valdis kletnieks" To: "Rob McEwen" Cc: nanog at nanog.org Sent: Thursday, April 26, 2018 8:14:14 AM Subject: Re: Is WHOIS going to go away? On Wed, 25 Apr 2018 13:47:24 -0400, Rob McEwen said: > SUGGESTION: Initially register with private registration - then change > it to regular non-hidden registration a few weeks later or so. That will work for about 2 weeks - until the people who currently run automated software looking for new registrations to spam fix their software to lurk until the new registration becomes non-hidden. From lprehn at inet.tu-berlin.de Thu Apr 26 08:46:38 2018 From: lprehn at inet.tu-berlin.de (Lars Prehn) Date: Thu, 26 Apr 2018 10:46:38 +0200 Subject: Internet topology resources Message-ID: <0329f34a-e0d6-31ac-f785-da9f69f3c645@inet.tu-berlin.de> Hi all, two quick questions: Is there any way to retrieve BGP data (e.g. table dumps, updates, ...) such that i.) the data is not already available in the RIPE RIS, Routeviews, PCH, Isolario, or BGPmon projects and ii.) it is not necessary to query a Looking Glass to death (e.g. get all neighbors, for each neighbor get all prefixes, for each prefix get all announcements)? Are there any traceroute (or related) projects that currently still make their data publically available except for MLAB, RIPE Atlas, Caida, the Bismark Projekt, the portolan project? In addition, if you know somebody that knows somebody (...) that probably might be capable of giving me access to an IXP Route Server dump, a set of traceroutes that is not published publically yet, or something related I would *really* appreciate if you could forward me the contact! :) All data is supposed to be used in a research context, more specific my master thesis, therefore I would also accept annonymized data as long as it still contains useful topology information. Best regards, Lars From tmanito at protonmail.com Thu Apr 26 18:33:11 2018 From: tmanito at protonmail.com (Timothy Manito) Date: Thu, 26 Apr 2018 14:33:11 -0400 Subject: Internet topology resources In-Reply-To: <0329f34a-e0d6-31ac-f785-da9f69f3c645@inet.tu-berlin.de> References: <0329f34a-e0d6-31ac-f785-da9f69f3c645@inet.tu-berlin.de> Message-ID: <6kTEg1kfpOStaDIePeg2egEGHDUFYleu5z0vKOg2B6FWfu_8q5t3s3cl-_lvU653_CMZrMtmlvdXLrfPnmWa2M1TPveJXYIGm1hY8bnRoY4=@protonmail.com> Is this some sort of BGP AS Path Visualization like what ThousandEyes are doing? Sent from ProtonMail mobile -------- Original Message -------- On Apr 26, 2018, 4:46 PM, Lars Prehn wrote: > Hi all, > > two quick questions: > > Is there any way to retrieve BGP data (e.g. table dumps, updates, ...) > such that i.) the data is not already available in the RIPE RIS, > Routeviews, PCH, Isolario, or BGPmon projects and ii.) it is not > necessary to query a Looking Glass to death (e.g. get all neighbors, for > each neighbor get all prefixes, for each prefix get all announcements)? > > Are there any traceroute (or related) projects that currently still make > their data publically available except for MLAB, RIPE Atlas, Caida, the > Bismark Projekt, the portolan project? > > In addition, if you know somebody that knows somebody (...) that > probably might be capable of giving me access to an IXP Route Server > dump, a set of traceroutes that is not published publically yet, or > something related I would *really* appreciate if you could forward me > the contact! :) All data is supposed to be used in a research context, > more specific my master thesis, therefore I would also accept > annonymized data as long as it still contains useful topology information. > > Best regards, > > Lars From lprehn at inet.tu-berlin.de Thu Apr 26 20:35:08 2018 From: lprehn at inet.tu-berlin.de (Lars Prehn) Date: Thu, 26 Apr 2018 22:35:08 +0200 Subject: Internet topology resources In-Reply-To: <6kTEg1kfpOStaDIePeg2egEGHDUFYleu5z0vKOg2B6FWfu_8q5t3s3cl-_lvU653_CMZrMtmlvdXLrfPnmWa2M1TPveJXYIGm1hY8bnRoY4=@protonmail.com> References: <0329f34a-e0d6-31ac-f785-da9f69f3c645@inet.tu-berlin.de> <6kTEg1kfpOStaDIePeg2egEGHDUFYleu5z0vKOg2B6FWfu_8q5t3s3cl-_lvU653_CMZrMtmlvdXLrfPnmWa2M1TPveJXYIGm1hY8bnRoY4=@protonmail.com> Message-ID: <291ae9b1-7b2d-b8e8-dd5b-6afeda450a7d@inet.tu-berlin.de> No. Visualizing AS paths, as such, is not planned within the scope of my thesis :) However, I'm really interested in getting an accurate snapshot of the current Internet's AS-level topology. The topology-related data ThousandEyes collects would fit my needs perfectly. If anyone may be able to provide similar data for academic research purposes I would really appreciate receiving a mail. Best regards, Lars Am 26.04.18 um 20:33 schrieb Timothy Manito: > Is this some sort of BGP AS Path Visualization like what ThousandEyes > are doing? > > > Sent from ProtonMail mobile > > > > -------- Original Message -------- > On Apr 26, 2018, 4:46 PM, Lars Prehn < lprehn at inet.tu-berlin.de> wrote: > > > Hi all, > > two quick questions: > > Is there any way to retrieve BGP data (e.g. table dumps, updates, > ...) > such that i.) the data is not already available in the RIPE RIS, > Routeviews, PCH, Isolario, or BGPmon projects and ii.) it is not > necessary to query a Looking Glass to death (e.g. get all > neighbors, for > each neighbor get all prefixes, for each prefix get all > announcements)? > > Are there any traceroute (or related) projects that currently > still make > their data publically available except for MLAB, RIPE Atlas, > Caida, the > Bismark Projekt, the portolan project? > > > In addition, if you know somebody that knows somebody (...) that > probably might be capable of giving me access to an IXP Route Server > dump, a set of traceroutes that is not published publically yet, or > something related I would *really* appreciate if you could forward me > the contact! :) All data is supposed to be used in a research > context, > more specific my master thesis, therefore I would also accept > annonymized data as long as it still contains useful topology > information. > > Best regards, > > Lars > From ldumont at northernsysadmin.com Fri Apr 27 02:20:07 2018 From: ldumont at northernsysadmin.com (Laurent) Date: Thu, 26 Apr 2018 22:20:07 -0400 Subject: Slight recurring Packet Loss at Equinix Ashburn Message-ID: <8f74e531-ef7c-a064-d411-028f0a6806cb@northernsysadmin.com> Hi everyone, Apologies for the noise and feel-free to reply off-list. We have a transit link to Equinix Ashburn where we see regular 12-20% packet loss on "some" of the peers there. We are working with the transit partner and Equinix NOC for the past few days. I can provide graph and IPs off-list if needed but I just wanted to do a quick cursosy check if anyone else saw similar issues over the past two weeks. Thank you From nanog at studio442.com.au Fri Apr 27 11:12:48 2018 From: nanog at studio442.com.au (Julien Goodwin) Date: Fri, 27 Apr 2018 21:12:48 +1000 Subject: Internet topology resources In-Reply-To: <6kTEg1kfpOStaDIePeg2egEGHDUFYleu5z0vKOg2B6FWfu_8q5t3s3cl-_lvU653_CMZrMtmlvdXLrfPnmWa2M1TPveJXYIGm1hY8bnRoY4=@protonmail.com> References: <0329f34a-e0d6-31ac-f785-da9f69f3c645@inet.tu-berlin.de> <6kTEg1kfpOStaDIePeg2egEGHDUFYleu5z0vKOg2B6FWfu_8q5t3s3cl-_lvU653_CMZrMtmlvdXLrfPnmWa2M1TPveJXYIGm1hY8bnRoY4=@protonmail.com> Message-ID: <70e4bcc6-a423-2dfe-72d7-bee09b56a294@studio442.com.au> On 27/04/18 04:33, Timothy Manito via NANOG wrote: > Is this some sort of BGP AS Path Visualization like what ThousandEyes are doing? I wrote something like that last year using all AS15169 peerings, sourcing data from BMP, then rendering out all the various paths just using graphviz. The most useful thing was the version I made which did that for direct peers and their single-homed (at least as far as we could tell) customers. So many networks have a couple of prefixes they forgot to advertise on peerings, a transit they forgot to v6 enable, or an "I'm sure the bosses didn't know about this one" v6 transit path. The most amusing graph was probably Akamai, since they reuse AS20940 all over the planet for distinct nodes. That one probably qualifies as modern art. From andy at newslink.com Fri Apr 27 15:46:44 2018 From: andy at newslink.com (Andy Ringsmuth) Date: Fri, 27 Apr 2018 10:46:44 -0500 Subject: Remote power cycle recommendations Message-ID: I’m sure many here are familiar with or using/have used devices to remotely power cycle equipment. I’m considering a Dataprobe iBoot-G2 and am curious if you’ve had experience with it, or other recommendations. I only need one outlet to be remotely power cycle-able. I have one piece of equipment that is occasionally a little flaky and, well, you know the hassle. What do people recommend? There seem to be plenty out there which are more designed to auto-reboot when Internet connectivity is lost, aka remotely reboot the ‘ol cable modem for instance, but that’s not my scenario. Thanks in advance. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From pozar at lns.com Fri Apr 27 16:16:50 2018 From: pozar at lns.com (Tim Pozar) Date: Fri, 27 Apr 2018 09:16:50 -0700 Subject: Remote power cycle recommendations In-Reply-To: References: Message-ID: <434bd1fc-dcc7-cf29-cb5d-741fea3a0fd9@lns.com> I have been picking up Server Technology CW-8H1-C20M boxes on eBay for about $45 to $65 each... https://www.ebay.com/itm/Server-Technology-CW-8H1-C20M-Switched-Power-Distribution-PDU-1U-Rackmount/332622720429 You can even get some recent firmware for these. https://www.servertech.com/support/rack-pdu-firmware-downloads/switched-rack-pdu-firmware-downloads One thing you will need is a NEMA 5-15P to C19 power cable to fit these units. I am sure you can find these cheaper than... https://www.amazon.com/gp/product/B009Z22DRC Tim On 4/27/18 8:46 AM, Andy Ringsmuth wrote: > I’m sure many here are familiar with or using/have used devices to remotely power cycle equipment. I’m considering a Dataprobe iBoot-G2 and am curious if you’ve had experience with it, or other recommendations. > > I only need one outlet to be remotely power cycle-able. I have one piece of equipment that is occasionally a little flaky and, well, you know the hassle. > > What do people recommend? There seem to be plenty out there which are more designed to auto-reboot when Internet connectivity is lost, aka remotely reboot the ‘ol cable modem for instance, but that’s not my scenario. > > Thanks in advance. > > ---- > Andy Ringsmuth > andy at newslink.com > News Link – Manager Technology, Travel & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397 (402) 304-0083 cellular > From keefe-af at ethoplex.com Fri Apr 27 16:39:34 2018 From: keefe-af at ethoplex.com (Keefe John) Date: Fri, 27 Apr 2018 11:39:34 -0500 Subject: Remote power cycle recommendations In-Reply-To: <434bd1fc-dcc7-cf29-cb5d-741fea3a0fd9@lns.com> References: <434bd1fc-dcc7-cf29-cb5d-741fea3a0fd9@lns.com> Message-ID: <3938925a-6d81-e1a8-bcbc-541773b5ba97@ethoplex.com> We've used Digital Loggers products for nearly 15 years. https://www.digital-loggers.com/ Keefe On 4/27/2018 11:16 AM, Tim Pozar wrote: > I have been picking up Server Technology CW-8H1-C20M boxes on eBay for > about $45 to $65 each... > > https://www.ebay.com/itm/Server-Technology-CW-8H1-C20M-Switched-Power-Distribution-PDU-1U-Rackmount/332622720429 > > You can even get some recent firmware for these. > > https://www.servertech.com/support/rack-pdu-firmware-downloads/switched-rack-pdu-firmware-downloads > > One thing you will need is a NEMA 5-15P to C19 power cable to fit these > units. I am sure you can find these cheaper than... > > https://www.amazon.com/gp/product/B009Z22DRC > > Tim > > On 4/27/18 8:46 AM, Andy Ringsmuth wrote: >> I’m sure many here are familiar with or using/have used devices to remotely power cycle equipment. I’m considering a Dataprobe iBoot-G2 and am curious if you’ve had experience with it, or other recommendations. >> >> I only need one outlet to be remotely power cycle-able. I have one piece of equipment that is occasionally a little flaky and, well, you know the hassle. >> >> What do people recommend? There seem to be plenty out there which are more designed to auto-reboot when Internet connectivity is lost, aka remotely reboot the ‘ol cable modem for instance, but that’s not my scenario. >> >> Thanks in advance. >> >> ---- >> Andy Ringsmuth >> andy at newslink.com >> News Link – Manager Technology, Travel & Facilities >> 2201 Winthrop Rd., Lincoln, NE 68502-4158 >> (402) 475-6397 (402) 304-0083 cellular >> From bill at herrin.us Fri Apr 27 17:03:32 2018 From: bill at herrin.us (William Herrin) Date: Fri, 27 Apr 2018 13:03:32 -0400 Subject: Remote power cycle recommendations In-Reply-To: References: Message-ID: On Fri, Apr 27, 2018 at 11:46 AM, Andy Ringsmuth wrote: > I’m sure many here are familiar with or using/have used devices to remotely power cycle equipment. I’m considering a Dataprobe iBoot-G2 and am curious if you’ve had experience with it, or other recommendations. > > I only need one outlet to be remotely power cycle-able. I have one piece of equipment that is occasionally a little flaky and, well, you know the hassle. The ancient (read: cheap used) APC AP9211's still get the job done. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From r.engehausen at gmail.com Fri Apr 27 17:05:57 2018 From: r.engehausen at gmail.com (Roy) Date: Fri, 27 Apr 2018 10:05:57 -0700 Subject: Remote power cycle recommendations In-Reply-To: References: Message-ID: We use Synaccess https://www.synaccess-net.com/switched/ From sghuter at nsrc.org Fri Apr 27 16:10:00 2018 From: sghuter at nsrc.org (Steven G. Huter) Date: Fri, 27 Apr 2018 09:10:00 -0700 (PDT) Subject: Internet topology resources In-Reply-To: <291ae9b1-7b2d-b8e8-dd5b-6afeda450a7d@inet.tu-berlin.de> References: <0329f34a-e0d6-31ac-f785-da9f69f3c645@inet.tu-berlin.de> <6kTEg1kfpOStaDIePeg2egEGHDUFYleu5z0vKOg2B6FWfu_8q5t3s3cl-_lvU653_CMZrMtmlvdXLrfPnmWa2M1TPveJXYIGm1hY8bnRoY4=@protonmail.com> <291ae9b1-7b2d-b8e8-dd5b-6afeda450a7d@inet.tu-berlin.de> Message-ID: On Thu, 26 Apr 2018, Lars Prehn wrote: > However, I'm really interested in getting an accurate snapshot of the current > Internet's AS-level topology. The topology-related data ThousandEyes collects > would fit my needs perfectly. If anyone may be able to provide similar data > for academic research purposes I would really appreciate receiving a mail. Hello Lars Checking to see what this research activity produced could be helpful. Towards an Accurate, Geo-Aware, PoP-Level Perspective of the Internet's Inter-AS Connectivity https://nsf.gov/awardsearch/showAward?AWD_ID=1320977 Steve From bruns at 2mbit.com Fri Apr 27 17:21:17 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 27 Apr 2018 11:21:17 -0600 Subject: Remote power cycle recommendations In-Reply-To: References: Message-ID: <46d9740b-3080-17d0-34b4-322ef7303587@2mbit.com> On 4/27/2018 11:03 AM, William Herrin wrote: > On Fri, Apr 27, 2018 at 11:46 AM, Andy Ringsmuth wrote: >> I’m sure many here are familiar with or using/have used devices to remotely power cycle equipment. I’m considering a Dataprobe iBoot-G2 and am curious if you’ve had experience with it, or other recommendations. >> >> I only need one outlet to be remotely power cycle-able. I have one piece of equipment that is occasionally a little flaky and, well, you know the hassle. > > The ancient (read: cheap used) APC AP9211's still get the job done. > > Regards, > Bill Herrin > Def can't recommend the AP9211s enough to people needing remote power control. You should be able to put the more modern AP961X series of cards in it as well. The AP9617 is the basic module, the 9619 has environmental monitoring, and the 9618 has both the environmental stuff plus an analog modem. The management modules can be reloaded with various types of firmware to make them compatible with everything from the rack mount PDUs to Symmetras and the run of the mill desktop or rack mount UPSs. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From cscora at apnic.net Fri Apr 27 18:03:00 2018 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Apr 2018 04:03:00 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20180427180300.95646102FF@thyme.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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. 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 28 Apr, 2018 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 696622 Prefixes after maximum aggregation (per Origin AS): 268740 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 335828 Total ASes present in the Internet Routing Table: 60573 Prefixes per ASN: 11.50 Origin-only ASes present in the Internet Routing Table: 52334 Origin ASes announcing only one prefix: 22916 Transit ASes present in the Internet Routing Table: 8239 Transit-only ASes present in the Internet Routing Table: 272 Average AS path length visible in the Internet Routing Table: 4.0 Max AS path length visible: 32 Max AS path prepend of ASN ( 30873) 28 Prefixes from unregistered ASNs in the Routing Table: 52 Number of instances of unregistered ASNs: 52 Number of 32-bit ASNs allocated by the RIRs: 22370 Number of 32-bit ASNs visible in the Routing Table: 18029 Prefixes from 32-bit ASNs in the Routing Table: 74974 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 3 Prefixes being announced from unallocated address space: 274 Number of addresses announced to Internet: 2858007298 Equivalent to 170 /8s, 89 /16s and 187 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.9 Total number of prefixes smaller than registry allocations: 231989 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 190773 Total APNIC prefixes after maximum aggregation: 54174 APNIC Deaggregation factor: 3.52 Prefixes being announced from the APNIC address blocks: 189607 Unique aggregates announced from the APNIC address blocks: 77418 APNIC Region origin ASes present in the Internet Routing Table: 8760 APNIC Prefixes per ASN: 21.64 APNIC Region origin ASes announcing only one prefix: 2447 APNIC Region transit ASes present in the Internet Routing Table: 1312 Average APNIC Region AS path length visible: 4.0 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3723 Number of APNIC addresses announced to Internet: 767006722 Equivalent to 45 /8s, 183 /16s and 152 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 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: 207204 Total ARIN prefixes after maximum aggregation: 99040 ARIN Deaggregation factor: 2.09 Prefixes being announced from the ARIN address blocks: 208175 Unique aggregates announced from the ARIN address blocks: 98531 ARIN Region origin ASes present in the Internet Routing Table: 18158 ARIN Prefixes per ASN: 11.46 ARIN Region origin ASes announcing only one prefix: 6718 ARIN Region transit ASes present in the Internet Routing Table: 1795 Average ARIN Region AS path length visible: 3.6 Max ARIN Region AS path length visible: 20 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2345 Number of ARIN addresses announced to Internet: 1104075680 Equivalent to 65 /8s, 206 /16s and 219 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-397212 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: 190185 Total RIPE prefixes after maximum aggregation: 91664 RIPE Deaggregation factor: 2.07 Prefixes being announced from the RIPE address blocks: 186106 Unique aggregates announced from the RIPE address blocks: 110990 RIPE Region origin ASes present in the Internet Routing Table: 25134 RIPE Prefixes per ASN: 7.40 RIPE Region origin ASes announcing only one prefix: 11403 RIPE Region transit ASes present in the Internet Routing Table: 3498 Average RIPE Region AS path length visible: 4.1 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6928 Number of RIPE addresses announced to Internet: 715764352 Equivalent to 42 /8s, 169 /16s and 178 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-207259 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: 89824 Total LACNIC prefixes after maximum aggregation: 19834 LACNIC Deaggregation factor: 4.53 Prefixes being announced from the LACNIC address blocks: 91232 Unique aggregates announced from the LACNIC address blocks: 40975 LACNIC Region origin ASes present in the Internet Routing Table: 7081 LACNIC Prefixes per ASN: 12.88 LACNIC Region origin ASes announcing only one prefix: 1968 LACNIC Region transit ASes present in the Internet Routing Table: 1310 Average LACNIC Region AS path length visible: 4.7 Max LACNIC Region AS path length visible: 32 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4618 Number of LACNIC addresses announced to Internet: 172822240 Equivalent to 10 /8s, 77 /16s and 14 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 18582 Total AfriNIC prefixes after maximum aggregation: 3981 AfriNIC Deaggregation factor: 4.67 Prefixes being announced from the AfriNIC address blocks: 21228 Unique aggregates announced from the AfriNIC address blocks: 7681 AfriNIC Region origin ASes present in the Internet Routing Table: 1140 AfriNIC Prefixes per ASN: 18.62 AfriNIC Region origin ASes announcing only one prefix: 379 AfriNIC Region transit ASes present in the Internet Routing Table: 229 Average AfriNIC Region AS path length visible: 4.5 Max AfriNIC Region AS path length visible: 23 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 415 Number of AfriNIC addresses announced to Internet: 97958400 Equivalent to 5 /8s, 214 /16s and 186 /24s 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 4538 5404 4192 74 ERX-CERNET-BKB China Education and Rese 7545 4389 415 431 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2899 11134 790 KIXS-AS-KR Korea Telecom, KR 9829 2810 1499 545 BSNL-NIB National Internet Backbone, IN 7552 2766 1155 71 VIETEL-AS-AP Viettel Group, VN 9394 2626 4922 26 CTTNET China TieTong Telecommunications 45899 2517 1574 160 VNPT-AS-VN VNPT Corp, VN 17974 2284 928 79 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9808 2190 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2098 417 206 TATACOMM-AS TATA Communications formerl 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 6327 3379 1323 84 SHAW - Shaw Communications Inc., CA 22773 3289 2988 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2168 405 109 MEGAPATH5-US - MegaPath Corporation, US 20115 2097 2499 453 CHARTER-NET-HKY-NC - Charter Communicat 16509 2075 4446 643 AMAZON-02 - Amazon.com, Inc., US 209 1969 5070 607 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1962 338 176 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1872 232 540 CABLEONE - CABLE ONE, INC., US 16625 1746 852 1253 AKAMAI-AS - Akamai Technologies, Inc., 7018 1703 20213 1257 ATT-INTERNET4 - AT&T Services, Inc., US 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 12479 4088 1516 505 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 20940 2672 726 1962 AKAMAI-ASN1, US 8551 2073 378 43 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 12389 2036 1876 707 ROSTELECOM-AS, RU 34984 2019 334 485 TELLCOM-AS, TR 9121 1979 1692 19 TTNET, TR 13188 1609 100 43 TRIOLAN, UA 8402 1245 544 14 CORBINA-AS OJSC "Vimpelcom", RU 6849 1241 355 21 UKRTELNET, UA 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 8151 4442 3385 585 Uninet S.A. de C.V., MX 10620 3591 542 244 Telmex Colombia S.A., CO 11830 2645 369 86 Instituto Costarricense de Electricidad 6503 1612 437 53 Axtel, S.A.B. de C.V., MX 7303 1519 1026 193 Telecom Argentina S.A., AR 28573 1034 2251 184 CLARO S.A., BR 6147 1010 377 31 Telefonica del Peru S.A.A., PE 3816 1009 505 123 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 927 126 85 Alestra, S. de R.L. de C.V., MX 18881 909 1074 29 TELEF�NICA BRASIL S.A, BR 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 1171 396 45 LINKdotNET-AS, EG 37611 830 107 9 Afrihost, ZA 36903 739 371 141 MT-MPLS, MA 8452 669 1730 18 TE-AS TE-AS, EG 36992 665 1412 41 ETISALAT-MISR, EG 24835 598 850 15 RAYA-AS, EG 29571 474 68 12 ORANGE-COTE-IVOIRE, CI 37492 452 376 81 ORANGE-, TN 23889 362 103 14 MauritiusTelecom, MU 37342 361 32 1 MOVITEL, MZ 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 4538 5404 4192 74 ERX-CERNET-BKB China Education and Rese 8151 4442 3385 585 Uninet S.A. de C.V., MX 7545 4389 415 431 TPG-INTERNET-AP TPG Telecom Limited, AU 12479 4088 1516 505 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 10620 3591 542 244 Telmex Colombia S.A., CO 6327 3379 1323 84 SHAW - Shaw Communications Inc., CA 22773 3289 2988 149 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 4766 2899 11134 790 KIXS-AS-KR Korea Telecom, KR 9829 2810 1499 545 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4389 3958 TPG-INTERNET-AP TPG Telecom Limited, AU 8151 4442 3857 Uninet S.A. de C.V., MX 39891 3778 3758 ALJAWWALSTC-AS, SA 12479 4088 3583 UNI2-AS, ES 10620 3591 3347 Telmex Colombia S.A., CO 6327 3379 3295 SHAW - Shaw Communications Inc., CA 22773 3289 3140 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 2766 2695 VIETEL-AS-AP Viettel Group, VN 9394 2626 2600 CTTNET China TieTong Telecommunications Corpora 11830 2645 2559 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 230105 UNALLOCATED 38.110.79.0/24 23015 CMC180-TOR-AS - Cambridge Merc 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 65537 DOCUMENT 62.162.120.0/24 6821 MT-AS-OWN bul. Orce Nikolov bb 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 65024 PRIVATE 87.103.232.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 87.103.233.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 87.103.234.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.78.0/24 39407 CHITATELECOM-AS, RU 65024 PRIVATE 95.189.80.0/22 39407 CHITATELECOM-AS, RU Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 100.66.224.0/19 209 CENTURYLINK-US-LEGACY-QWEST - Qwest Communicati 100.127.16.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM 100.127.18.0/23 28885 OMANTEL-NAP-AS OmanTel NAP, OM Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.136.0/24 37500 -Reserved AS-, ZZ 41.76.138.0/24 37500 -Reserved AS-, ZZ 41.76.139.0/24 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/24 37500 -Reserved AS-, ZZ 41.76.141.0/24 37500 -Reserved AS-, ZZ 41.76.142.0/24 37500 -Reserved AS-, ZZ 41.76.143.0/24 37500 -Reserved AS-, ZZ 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:14 /9:11 /10:37 /11:100 /12:288 /13:565 /14:1096 /15:1901 /16:13407 /17:7837 /18:13590 /19:25171 /20:39380 /21:45168 /22:86697 /23:70128 /24:388993 /25:847 /26:607 /27:654 /28:36 /29:21 /30:17 /31:4 /32:53 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3168 3379 SHAW - Shaw Communications Inc., CA 39891 2946 3778 ALJAWWALSTC-AS, SA 12479 2830 4088 UNI2-AS, ES 22773 2543 3289 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2061 2168 MEGAPATH5-US - MegaPath Corporation, US 11830 1993 2645 Instituto Costarricense de Electricidad y Telec 30036 1714 1962 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 11492 1615 1872 CABLEONE - CABLE ONE, INC., US 10620 1601 3591 Telmex Colombia S.A., CO 8551 1536 2073 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1591 2:843 4:19 5:2802 6:65 7:1 8:1116 12:1870 13:185 14:1745 15:30 16:3 17:204 18:68 20:47 21:5 23:2579 24:2163 25:2 27:2277 31:1975 32:87 35:27 36:508 37:2769 38:1445 39:256 40:119 41:3093 42:574 43:1976 44:109 45:4304 46:3040 47:204 49:1312 50:1047 51:304 52:1020 54:372 55:4 56:12 57:42 58:1556 59:992 60:430 61:2154 62:1814 63:1788 64:4926 65:2199 66:4611 67:2367 68:1144 69:3191 70:1147 71:561 72:2101 74:2719 75:414 76:439 77:1549 78:1698 79:1847 80:1490 81:1409 82:1079 83:777 84:1043 85:2059 86:590 87:1302 88:938 89:2330 90:206 91:6340 92:1168 93:2370 94:2379 95:2825 96:663 97:358 98:946 99:133 100:81 101:1281 102:40 103:17600 104:3524 105:232 106:659 107:1770 108:710 109:2718 110:1604 111:1774 112:1267 113:1262 114:1123 115:1633 116:1643 117:1730 118:2167 119:1643 120:983 121:1053 122:2451 123:1815 124:1467 125:1891 128:1002 129:648 130:453 131:1597 132:666 133:196 134:1016 135:227 136:457 137:493 138:1924 139:601 140:426 141:694 142:803 143:975 144:799 145:461 146:1184 147:786 148:1593 149:700 150:732 151:1060 152:767 153:311 154:1025 155:763 156:929 157:781 158:642 159:1738 160:925 161:751 162:2584 163:546 164:1050 165:1569 166:431 167:1396 168:3066 169:800 170:3694 171:432 172:1060 173:1984 174:885 175:759 176:1943 177:4014 178:2433 179:1212 180:2247 181:2193 182:2386 183:1145 184:956 185:13421 186:3608 187:2370 188:2770 189:2032 190:8091 191:1468 192:9836 193:5885 194:4773 195:3955 196:2530 197:1457 198:5525 199:5882 200:7399 201:4997 202:10326 203:10185 204:4562 205:2879 206:3095 207:3204 208:3979 209:3948 210:4033 211:2116 212:3005 213:2730 214:957 215:61 216:5928 217:2126 218:912 219:622 220:1754 221:995 222:1038 223:1242 End of report From la at qrator.net Fri Apr 27 20:03:49 2018 From: la at qrator.net (Alexander Lyamin) Date: Fri, 27 Apr 2018 22:03:49 +0200 Subject: Internet topology resources In-Reply-To: References: <0329f34a-e0d6-31ac-f785-da9f69f3c645@inet.tu-berlin.de> <6kTEg1kfpOStaDIePeg2egEGHDUFYleu5z0vKOg2B6FWfu_8q5t3s3cl-_lvU653_CMZrMtmlvdXLrfPnmWa2M1TPveJXYIGm1hY8bnRoY4=@protonmail.com> <291ae9b1-7b2d-b8e8-dd5b-6afeda450a7d@inet.tu-berlin.de> Message-ID: Geo-positioning, in general sucks. Internet topology has very little to do with geo-data, however, i would highly recommend this guys https://www.ipip.net/ On Fri, Apr 27, 2018 at 6:10 PM, Steven G. Huter wrote: > On Thu, 26 Apr 2018, Lars Prehn wrote: > > However, I'm really interested in getting an accurate snapshot of the >> current Internet's AS-level topology. The topology-related data >> ThousandEyes collects would fit my needs perfectly. If anyone may be able >> to provide similar data for academic research purposes I would really >> appreciate receiving a mail. >> > > Hello Lars > > Checking to see what this research activity produced could be helpful. > > Towards an Accurate, Geo-Aware, PoP-Level Perspective of the Internet's > Inter-AS Connectivity > > https://nsf.gov/awardsearch/showAward?AWD_ID=1320977 > > Steve > -- Alexander Lyamin, VP & Founder Qrator * Labs CZ * office: +420 602 558 144 <++420+602+558+144> mob: +420 774 303 807 <++420+774+303+807> skype: melanor9 mailto: la at qrator.net From bob at FiberInternetCenter.com Fri Apr 27 21:27:56 2018 From: bob at FiberInternetCenter.com (Bob Evans) Date: Fri, 27 Apr 2018 14:27:56 -0700 Subject: Amazon AWS Europe issues Message-ID: <934b8cf37a27af1d388b84ad7ff1fc1f.squirrel@66.201.44.180> Anyone here form Amazon that can contact me offline about issues our customers are having regarding AWS problems connecting from our California network to Europe. One specific is .... ext-eu-km-80-global-market-live-2004446585.eu-west-1.elb.amazonaws.com (52.17.152.249) Thank You Bob Evans CTO From james.voip at gmail.com Fri Apr 27 21:58:57 2018 From: james.voip at gmail.com (james jones) Date: Fri, 27 Apr 2018 17:58:57 -0400 Subject: Instagram Abuse Contact Message-ID: I need a clueful Instagram abuse contact. -James From jared at puck.nether.net Fri Apr 27 23:18:06 2018 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 27 Apr 2018 19:18:06 -0400 Subject: Hulu Peering In-Reply-To: References: Message-ID: <02A98945-F4D6-498D-B32C-06C74AEC28E1@puck.nether.net> > On Apr 23, 2018, at 2:26 PM, joel jaeggli wrote: > > > On 4/23/18 11:14 AM, craig washington wrote: >> Hey all, >> >> >> Just wondering if anyone peers with Hulu at any public exchange. >> >> I don't see anything on them in the peeringdb or anything that stands out from a google search besides it looks like they may be doing something with Equinix. > Hulu's streaming media bits come from a few CDNs. > > My current cartoon network bits are coming from verizon digital media > services. I believe some other CDNs also host them. https://www.peeringdb.com/asn/20940 If you have trouble with the listed contacts, please ping me and I’ll take a closer look. - Jared From alan.buxey at gmail.com Sat Apr 28 08:42:01 2018 From: alan.buxey at gmail.com (Alan Buxey) Date: Sat, 28 Apr 2018 09:42:01 +0100 Subject: Remote power cycle recommendations In-Reply-To: <46d9740b-3080-17d0-34b4-322ef7303587@2mbit.com> References: <46d9740b-3080-17d0-34b4-322ef7303587@2mbit.com> Message-ID: +1 for the APC kit :) alan From spell at api-digital.com Sat Apr 28 00:26:35 2018 From: spell at api-digital.com (Scott Pell) Date: Sat, 28 Apr 2018 00:26:35 +0000 Subject: Hulu Peering In-Reply-To: <02A98945-F4D6-498D-B32C-06C74AEC28E1@puck.nether.net> References: <02A98945-F4D6-498D-B32C-06C74AEC28E1@puck.nether.net> Message-ID: Akamai. On Fri, Apr 27, 2018 at 6:19 PM Jared Mauch wrote: > > > > On Apr 23, 2018, at 2:26 PM, joel jaeggli wrote: > > > > > > On 4/23/18 11:14 AM, craig washington wrote: > >> Hey all, > >> > >> > >> Just wondering if anyone peers with Hulu at any public exchange. > >> > >> I don't see anything on them in the peeringdb or anything that stands > out from a google search besides it looks like they may be doing something > with Equinix. > > Hulu's streaming media bits come from a few CDNs. > > > > My current cartoon network bits are coming from verizon digital media > > services. > > I believe some other CDNs also host them. > > https://www.peeringdb.com/asn/20940 > > If you have trouble with the listed contacts, please ping me and I’ll take > a closer look. > > - Jared -- [image: photo] *Scott Pell* CIO, API Digital p:(256) 428-8743 | e:scott at api-digital.com | w:api-digital.com a:200 Westside Square, Suite 600, Huntsville, AL 35801 From ben at 6by7.net Fri Apr 27 17:47:59 2018 From: ben at 6by7.net (Ben Cannon) Date: Fri, 27 Apr 2018 10:47:59 -0700 Subject: Remote power cycle recommendations In-Reply-To: <46d9740b-3080-17d0-34b4-322ef7303587@2mbit.com> References: <46d9740b-3080-17d0-34b4-322ef7303587@2mbit.com> Message-ID: <9D4B4D04-DD47-4E47-B746-B3D5B8AF1B85@6by7.net> Third for the APC9211, though I’ll add that you might “think” you only want one outlet now, but once you have the ability you will invariably want to control more ;) -Ben > On Apr 27, 2018, at 10:21 AM, Brielle Bruns wrote: > >> On 4/27/2018 11:03 AM, William Herrin wrote: >>> On Fri, Apr 27, 2018 at 11:46 AM, Andy Ringsmuth wrote: >>> I’m sure many here are familiar with or using/have used devices to remotely power cycle equipment. I’m considering a Dataprobe iBoot-G2 and am curious if you’ve had experience with it, or other recommendations. >>> >>> I only need one outlet to be remotely power cycle-able. I have one piece of equipment that is occasionally a little flaky and, well, you know the hassle. >> The ancient (read: cheap used) APC AP9211's still get the job done. >> Regards, >> Bill Herrin > > Def can't recommend the AP9211s enough to people needing remote power control. You should be able to put the more modern AP961X series of cards in it as well. The AP9617 is the basic module, the 9619 has environmental monitoring, and the 9618 has both the environmental stuff plus an analog modem. > > The management modules can be reloaded with various types of firmware to make them compatible with everything from the rack mount PDUs to Symmetras and the run of the mill desktop or rack mount UPSs. > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org From ahebert at pubnix.net Mon Apr 30 12:17:15 2018 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 30 Apr 2018 08:17:15 -0400 Subject: Remote power cycle recommendations In-Reply-To: References: <46d9740b-3080-17d0-34b4-322ef7303587@2mbit.com> Message-ID:     Well I don't have all the model # handy, But we have a rack setup like this =D     2 feed 220v/30a going into:         2 x ATS AP4431 (an older version) feeding:             2 x AP7941 - Manageable                 21 x C13 - per AP - for the devices.                 2 x C19 going into:                     2 x ATS AP7723 - Monitorable                         8 x C13 - per AP - For servers (with ILO/iDRAC) with single power supplies.     1 feed 110v/15a going into:         Some APC(?) rackmount UPS             1 x AP7920B (an older version of it) - Manageable                 For device like OOB Modem, Server...     All used, with spares, for under 2k.     Its too bad for APC for making such sturdy devices and providing award winning documentation =D BOM for new:     AP4431 -> $1275     AP7941 -> AP8941 -> $1000     AP7723 -> AP4434 -> $1050     AP7920B - $579     Total: ~$7230     Which is pretty good considering.  PS: Check if the Mgmt Card is included at that price. Caution:     1. DO NOT put any infrastructure interfaces on the net; put them behind a high grade (2FA | Certificate+TLS) VPN access;         I saw so many, so called PCI Certified, clients do it...     2. And remember to not go over 24A total or you may turn a breaker to dust.     3. It is not optimal because of the 110v but we had it... ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 04/28/18 04:42, Alan Buxey wrote: > +1 for the APC kit :) > > alan > From Jeroen.Wunnink at gtt.net Mon Apr 30 13:58:32 2018 From: Jeroen.Wunnink at gtt.net (Jeroen Wunnink) Date: Mon, 30 Apr 2018 13:58:32 +0000 Subject: Remote power cycle recommendations In-Reply-To: References: Message-ID: Various APC-rackmountable equipment. They come in all sorts of sizes and capacity. C13/C19, single breaker, dual feed/breaker, 19" rackmount, 0 HE vertical rackmount in the back. They have a web/snmp/telnet interface, separate account management, so very easy to control. Delayed power-on per outlet options after an outage so you won't peak/blow your main breakers is an important one as well. Jeroen Wunnink Integration Engineering Manager www.gtt.net On 27/04/2018, 17:47, "NANOG on behalf of Andy Ringsmuth" wrote: I’m sure many here are familiar with or using/have used devices to remotely power cycle equipment. I’m considering a Dataprobe iBoot-G2 and am curious if you’ve had experience with it, or other recommendations. I only need one outlet to be remotely power cycle-able. I have one piece of equipment that is occasionally a little flaky and, well, you know the hassle. What do people recommend? There seem to be plenty out there which are more designed to auto-reboot when Internet connectivity is lost, aka remotely reboot the ‘ol cable modem for instance, but that’s not my scenario. Thanks in advance. ---- Andy Ringsmuth andy at newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397 (402) 304-0083 cellular From list at satchell.net Mon Apr 30 15:46:55 2018 From: list at satchell.net (Stephen Satchell) Date: Mon, 30 Apr 2018 08:46:55 -0700 Subject: Remote power cycle recommendations In-Reply-To: References: Message-ID: I've worked with APC, Synaccess, and a couple other brands of power controllers. One constant: the IP stack implementations tend to be a bit fragile. This is not restricted to power controllers; I have a GPS NTP appliance that is affected by the same sorts of things. I'll stick with APC and Synaccess, because I currently work with those. You want to avoid presenting these conditions to the embedded stack: 1. ARP storms 2. Lots of layer 2 and layer 3 broadcast traffic 3. Probes for ports not implemented in the stack 4. Too much traffic (SNMP in particular) I like keeping all such devices on a single management VLAN dedicated to embedded-stack devices. The Ethernet hardware tends to be competent at filtering packets not intended for the device, so you don't have to go overboard with VLANs. It's the software behind the hardware that is easy to overwhelm if you throw too many packets at it. (But you knew this already) From bruns at 2mbit.com Mon Apr 30 16:19:38 2018 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 30 Apr 2018 10:19:38 -0600 Subject: Remote power cycle recommendations In-Reply-To: References: Message-ID: On 4/30/2018 9:46 AM, Stephen Satchell wrote: > I've worked with APC, Synaccess, and a couple other brands of power > controllers.  One constant:  the IP stack implementations tend to be a > bit fragile.  This is not restricted to power controllers; I have a GPS > NTP appliance that is affected by the same sorts of things. > > I'll stick with APC and Synaccess, because I currently work with those. > You want to avoid presenting these conditions to the embedded stack: > > 1.  ARP storms > 2.  Lots of layer 2 and layer 3 broadcast traffic > 3.  Probes for ports not implemented in the stack > 4.  Too much traffic (SNMP in particular) > > I like keeping all such devices on a single management VLAN dedicated to > embedded-stack devices.  The Ethernet hardware tends to be competent at > filtering packets not intended for the device, so you don't have to go > overboard with VLANs.  It's the software behind the hardware that is > easy to overwhelm if you throw too many packets at it. > > (But you knew this already) In particular, if at all possible, do not use the AP9606 era cards with the APCs. They are 10BaseT and take fragile to a whole new level. I usually have to manually force the port to 10 on the switch or put it on a cheap dumb older switch. The 961X series is 100BaseT and somewhat less temperamental. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bill at herrin.us Mon Apr 30 17:05:16 2018 From: bill at herrin.us (William Herrin) Date: Mon, 30 Apr 2018 13:05:16 -0400 Subject: Remote power cycle recommendations In-Reply-To: References: Message-ID: On Mon, Apr 30, 2018 at 12:19 PM, Brielle Bruns wrote: > In particular, if at all possible, do not use the AP9606 era cards with the > APCs. They are 10BaseT and take fragile to a whole new level. I usually > have to manually force the port to 10 on the switch or put it on a cheap > dumb older switch. They're fragile but they're not _that_ fragile. A switch that can't figure out 10 mbps half duplex... now that's fragile. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From Jacques.Latour at cira.ca Mon Apr 30 17:11:11 2018 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Mon, 30 Apr 2018 17:11:11 +0000 Subject: Call for presentations TechDay at ICANN 62 Message-ID: <25ce3f235e9e41cab277ec055250e4fa@cira.ca> Call for Presentations 35th TechDay at ICANN 62 in Panama City The ICANN Tech Working Group is again planning a technical workshop at the ICANN 62 meeting in Panama City on Monday 2018-06-25 after the DNSSEC Lunch. The TechDay workshop has been a part of ICANN meetings since 2006 and has provided a forum for both experienced and new people to meet, present and discuss technical topics related to registry and DNS work and security. We are specially interested in: 1. Emerging Threats 2. In addition, we welcome suggestions for additional topics, such as; * Registry security, services and systems * DNS & anycast security, services and systems * Big Data & associated data analysis * IETF DNS protocol updates (Privacy, Encryption) * (Recent) DDOS Attacks and Mitigation If you are interested in presenting, please email ccNSO-techday at icann.org Regards, Jacques On behalf of the TechDay Planning Committee From list at satchell.net Mon Apr 30 18:58:13 2018 From: list at satchell.net (Stephen Satchell) Date: Mon, 30 Apr 2018 11:58:13 -0700 Subject: Remote power cycle recommendations In-Reply-To: References: Message-ID: <2d69b73f-20c9-2ee1-e5de-65756c54e861@satchell.net> On 04/30/2018 10:05 AM, William Herrin wrote: > On Mon, Apr 30, 2018 at 12:19 PM, Brielle Bruns wrote: >> In particular, if at all possible, do not use the AP9606 era cards with the >> APCs. They are 10BaseT and take fragile to a whole new level. I usually >> have to manually force the port to 10 on the switch or put it on a cheap >> dumb older switch. > They're fragile but they're not_that_ fragile. A switch that can't > figure out 10 mbps half duplex... now that's fragile. Personally, I've not run into THAT problem in years. What I have run into is when you have a 10base-T target and you connect it to a 100base-T (or faster) infrastructure, the switch as part of the rate changing will tend to flood the poor embedded stack if your application layer isn't very, very careful to space out packets. At best your embedded-stack device will lose packets. At worst, you will have to power-cycle the poor dear in order to get it to start listening to the network again. Let me repeat, this observation is not restricted to the AP9606 cards; it seems to be an issue with embedded-stack devices in general. Subject change: one other thing about the AP9606 cards: they have a battery on them, and you do have to change that battery every decade or so... From lists at benappy.com Mon Apr 30 19:19:12 2018 From: lists at benappy.com (Michel 'ic' Luczak) Date: Mon, 30 Apr 2018 21:19:12 +0200 Subject: Remote power cycle recommendations In-Reply-To: References: Message-ID: If rack-mount is not a hard requirement, I would definitely look into Ubiquiti’s mPower range. You will find anything from a single socket (WiFi only) to a 6 socket PDU (WiFi and Ethernet, probably 8 sockets for US but I’m in Europe) with central management system (free) and detailed consumption graphs and costs if you provide the kWh cost. I’m running many of those with the controller/management software installed remotely in a central location and have several alerts and automation scripts setup when consumption goes beyond a certain level (meaning the equipment has crashed). https://www.ubnt.com/mfi/mpower/ Regards, Michel > On 27 Apr 2018, at 17:46, Andy Ringsmuth wrote: > > I’m sure many here are familiar with or using/have used devices to remotely power cycle equipment. I’m considering a Dataprobe iBoot-G2 and am curious if you’ve had experience with it, or other recommendations. > > I only need one outlet to be remotely power cycle-able. I have one piece of equipment that is occasionally a little flaky and, well, you know the hassle. > > What do people recommend? There seem to be plenty out there which are more designed to auto-reboot when Internet connectivity is lost, aka remotely reboot the ‘ol cable modem for instance, but that’s not my scenario. > > Thanks in advance. > > ---- > Andy Ringsmuth > andy at newslink.com > News Link – Manager Technology, Travel & Facilities > 2201 Winthrop Rd., Lincoln, NE 68502-4158 > (402) 475-6397 (402) 304-0083 cellular > From lists at benappy.com Mon Apr 30 19:51:58 2018 From: lists at benappy.com (Michel 'ic' Luczak) Date: Mon, 30 Apr 2018 21:51:58 +0200 Subject: Remote power cycle recommendations In-Reply-To: <1EF60D6B-1560-4692-9C72-81D424189A7F@6by7.net> References: <1EF60D6B-1560-4692-9C72-81D424189A7F@6by7.net> Message-ID: <0F03738A-8A84-472B-B89C-7DED726C2ADD@benappy.com> I had more or less the same experience with APC Masterswitches (fried a few of those) ;) + the included free backdoors and default admin passwords and write communities (I got my whole platform shutdown by someone once). I guess YMMV. > On 30 Apr 2018, at 21:49, Ben Cannon wrote: > > I want to love these, but I’ve had enough problems (3 bad units, one 8 port wiped it’s config and reset itself) causing outages, out of the 6 or so devices I’ve deployed, to ever use them in a critical production role. > >> On Apr 30, 2018, at 12:19 PM, Michel 'ic' Luczak wrote: >> >> If rack-mount is not a hard requirement, I would definitely look into Ubiquiti’s mPower range. You will find anything from a single socket (WiFi only) to a 6 socket PDU (WiFi and Ethernet, probably 8 sockets for US but I’m in Europe) with central management system (free) and detailed consumption graphs and costs if you provide the kWh cost. >> >> I’m running many of those with the controller/management software installed remotely in a central location and have several alerts and automation scripts setup when consumption goes beyond a certain level (meaning the equipment has crashed). >> >> https://www.ubnt.com/mfi/mpower/ >> >> Regards, Michel >> >>> On 27 Apr 2018, at 17:46, Andy Ringsmuth wrote: >>> >>> I’m sure many here are familiar with or using/have used devices to remotely power cycle equipment. I’m considering a Dataprobe iBoot-G2 and am curious if you’ve had experience with it, or other recommendations. >>> >>> I only need one outlet to be remotely power cycle-able. I have one piece of equipment that is occasionally a little flaky and, well, you know the hassle. >>> >>> What do people recommend? There seem to be plenty out there which are more designed to auto-reboot when Internet connectivity is lost, aka remotely reboot the ‘ol cable modem for instance, but that’s not my scenario. >>> >>> Thanks in advance. >>> >>> ---- >>> Andy Ringsmuth >>> andy at newslink.com >>> News Link – Manager Technology, Travel & Facilities >>> 2201 Winthrop Rd., Lincoln, NE 68502-4158 >>> (402) 475-6397 (402) 304-0083 cellular >>> >> > From ben at 6by7.net Mon Apr 30 19:49:45 2018 From: ben at 6by7.net (Ben Cannon) Date: Mon, 30 Apr 2018 12:49:45 -0700 Subject: Remote power cycle recommendations In-Reply-To: References: Message-ID: <1EF60D6B-1560-4692-9C72-81D424189A7F@6by7.net> I want to love these, but I’ve had enough problems (3 bad units, one 8 port wiped it’s config and reset itself) causing outages, out of the 6 or so devices I’ve deployed, to ever use them in a critical production role. > On Apr 30, 2018, at 12:19 PM, Michel 'ic' Luczak wrote: > > If rack-mount is not a hard requirement, I would definitely look into Ubiquiti’s mPower range. You will find anything from a single socket (WiFi only) to a 6 socket PDU (WiFi and Ethernet, probably 8 sockets for US but I’m in Europe) with central management system (free) and detailed consumption graphs and costs if you provide the kWh cost. > > I’m running many of those with the controller/management software installed remotely in a central location and have several alerts and automation scripts setup when consumption goes beyond a certain level (meaning the equipment has crashed). > > https://www.ubnt.com/mfi/mpower/ > > Regards, Michel > >> On 27 Apr 2018, at 17:46, Andy Ringsmuth wrote: >> >> I’m sure many here are familiar with or using/have used devices to remotely power cycle equipment. I’m considering a Dataprobe iBoot-G2 and am curious if you’ve had experience with it, or other recommendations. >> >> I only need one outlet to be remotely power cycle-able. I have one piece of equipment that is occasionally a little flaky and, well, you know the hassle. >> >> What do people recommend? There seem to be plenty out there which are more designed to auto-reboot when Internet connectivity is lost, aka remotely reboot the ‘ol cable modem for instance, but that’s not my scenario. >> >> Thanks in advance. >> >> ---- >> Andy Ringsmuth >> andy at newslink.com >> News Link – Manager Technology, Travel & Facilities >> 2201 Winthrop Rd., Lincoln, NE 68502-4158 >> (402) 475-6397 (402) 304-0083 cellular >> > From ben at 6by7.net Mon Apr 30 19:54:37 2018 From: ben at 6by7.net (Ben Cannon) Date: Mon, 30 Apr 2018 12:54:37 -0700 Subject: Remote power cycle recommendations In-Reply-To: <0F03738A-8A84-472B-B89C-7DED726C2ADD@benappy.com> References: <1EF60D6B-1560-4692-9C72-81D424189A7F@6by7.net> <0F03738A-8A84-472B-B89C-7DED726C2ADD@benappy.com> Message-ID: <8B980E27-7B2E-40ED-B4E4-2BCFA3412C42@6by7.net> Good point, and important reminder to segment! None of this stuff is to be considered secure. Don’t feel bad, I left a box I’d just put a fresh slackware install on, this was perhaps 2000 or 1999 too keep in mind, anyway I left it running with a public IP and no root password. For an hour. Came back from lunch to finish the install and it was already hacked. -Ben. > On Apr 30, 2018, at 12:51 PM, Michel 'ic' Luczak wrote: > > I had more or less the same experience with APC Masterswitches (fried a few of those) ;) + the included free backdoors and default admin passwords and write communities (I got my whole platform shutdown by someone once). I guess YMMV. > >> On 30 Apr 2018, at 21:49, Ben Cannon wrote: >> >> I want to love these, but I’ve had enough problems (3 bad units, one 8 port wiped it’s config and reset itself) causing outages, out of the 6 or so devices I’ve deployed, to ever use them in a critical production role. >> >>> On Apr 30, 2018, at 12:19 PM, Michel 'ic' Luczak wrote: >>> >>> If rack-mount is not a hard requirement, I would definitely look into Ubiquiti’s mPower range. You will find anything from a single socket (WiFi only) to a 6 socket PDU (WiFi and Ethernet, probably 8 sockets for US but I’m in Europe) with central management system (free) and detailed consumption graphs and costs if you provide the kWh cost. >>> >>> I’m running many of those with the controller/management software installed remotely in a central location and have several alerts and automation scripts setup when consumption goes beyond a certain level (meaning the equipment has crashed). >>> >>> https://www.ubnt.com/mfi/mpower/ >>> >>> Regards, Michel >>> >>>> On 27 Apr 2018, at 17:46, Andy Ringsmuth wrote: >>>> >>>> I’m sure many here are familiar with or using/have used devices to remotely power cycle equipment. I’m considering a Dataprobe iBoot-G2 and am curious if you’ve had experience with it, or other recommendations. >>>> >>>> I only need one outlet to be remotely power cycle-able. I have one piece of equipment that is occasionally a little flaky and, well, you know the hassle. >>>> >>>> What do people recommend? There seem to be plenty out there which are more designed to auto-reboot when Internet connectivity is lost, aka remotely reboot the ‘ol cable modem for instance, but that’s not my scenario. >>>> >>>> Thanks in advance. >>>> >>>> ---- >>>> Andy Ringsmuth >>>> andy at newslink.com >>>> News Link – Manager Technology, Travel & Facilities >>>> 2201 Winthrop Rd., Lincoln, NE 68502-4158 >>>> (402) 475-6397 (402) 304-0083 cellular >>>> >>> >> >