From ivanov_andrei at yahoo.com Mon Jul 1 01:47:17 2019 From: ivanov_andrei at yahoo.com (Andrei Ivanov) Date: Sun, 30 Jun 2019 18:47:17 -0700 Subject: AS16509 (Amazon) peering contact In-Reply-To: <3979AE529B56AB47942E2423B707F16E0313A74C18@RTC-EXCH01.RESERVE.LDS> References: <993d8a35-65c1-d3a5-338e-914b9912c44b@netravnen.de> <3979AE529B56AB47942E2423B707F16E0313A74C18@RTC-EXCH01.RESERVE.LDS> Message-ID: <8b7d18dd-53ad-5a49-2cc6-41865a53a14e@yahoo.com> Don't get too excited. For us it took almost 40 weeks to get peering session set up. --andrei On 6/27/19 2:47 PM, Kody Vicknair wrote: > I've always worked with Tim Bates. They were exceptionally quick with standing up my session. like same day quick... > From beecher at beecher.cc Mon Jul 1 13:42:23 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 1 Jul 2019 09:42:23 -0400 Subject: Ideas to products (Shark Tank(-ish) @ Austin) In-Reply-To: References: Message-ID: Referencing our published presentation guidelines , https://nanog.org/participate/presentation-guidelines/ ( emphasis mine ) : While it is not our goal to censor presentation content, *we do ask that > speakers refrain from disclosing proprietary information, or using > presentations as a platform to promote their place of employment*. As > such, we ask that you adhere to our presentation guidelines. NANOG allows > logos to be used in the following ways: As described, I think it would be challenging to satisfy the bolded. By any analysis, an investor pitch session would be both of these. Generally speaking, aside from the time allotted at the start of the program for our meeting sponsor, we try to keep the business out of the room. That being said, there might be a way to modify this idea to better align with the content goals we strive to achieve. The CFP is ( spoiler alert ) going out today, and the PC would be glad to have the submission and work with you to see if a fit could be found. On Sat, Jun 29, 2019 at 11:12 AM Mehmet Akcin wrote: > Hey there, > > I am trying to put together an event at NANOG Austin (will submit pc when > CFP is open). So many of us had very interesting ideas over the years. Some > of these ideas became products or companies making life easy for engineers > and operators. Could there be other ideas waiting to be supported? Perhaps. > I am sure you all watched shark tank! In simplest words i am trying to > organize an event very similar to Shark Tank!( we will call it some other > name tho) > > There will be some known investors on the stage and you will 5 mins for > your pitch and 10 mins to answer questions, and hopefully make a deal. > > I will help those who want to pitch their idea with their p&l , > presentation and other things as they needed. > > Please contact me if you have any questions offlist and want to pitch your > idea. We need a single paragraph to get you started. > > Mehmet > -- > Mehmet > +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Mon Jul 1 14:09:01 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 1 Jul 2019 10:09:01 -0400 Subject: Ideas to products (Shark Tank(-ish) @ Austin) In-Reply-To: References: Message-ID: Matt- The challenge would be the function of the organization as reported to the IRS versus what the organization actually does. If your exemption status is based on Activity A , and you started to do Completely Unrelated Activity B without proper notification and process with the IRS, you can lose that 501(c)3 status. This happened to an organization I was involved with many years ago. For your example, a 501(c)3 organization created for the objective is connecting investors to businesses is perfectly fine. If that organization later started funding scholarships for underprivileged children without properly involving the IRS, they could jeopardize that exempt status. The Program Committee would absolutely work with the Board to get a proper opinion if content was being considered for acceptance that could run us afoul of those rules. On Sat, Jun 29, 2019 at 4:09 PM Matt Harris wrote: > On Sat, Jun 29, 2019 at 11:35 AM Mehmet Akcin wrote: > >> Great point ;-) thanks Tom >> >> On Sat, Jun 29, 2019 at 09:29 Tom Daly wrote: >> >>> Mehmet, >>> >>> Good idea, the opportunity for innovation and supporting ideas of others >>> in our operator groups is important, but NANOG is probably the wrong venue. >>> >>> Have you considered NANOG's 501c3 not-for-profit status in your analysis >>> of bringing this idea to the community? As a presenter, how would one >>> protect his/her intellectual property being shown to the proposed "sharks" >>> and/or the audience? (would an audience be permitted in the room?) >>> >>> I can't speak for the NANOG Board nor the Program Committee, but as an >>> interested party in NANOG's 501(c)3 not-for-profit status, I am pretty >>> certain this activity would jeopardize our recognized exemption with the >>> IRS. I think this is an important detail you explore before proceeding. >>> >> > As someone who had dealt with non-profit management many times and served > on several non-profit entity boards of varying sorts, I don't see any issue > here at all with simply hosting such an event. As long as NANOG handles the > procedes from the event properly, there should be no issue. In fact, there > are 501(c)3 organizations which exist with a primary goal very similar to > this: connecting investors with potential investments. Check out Code2040, > the Techstars Foundation, and Change Catalyst, among others. > > I'd like to hear why you feel this sort of event may cause an issue or > jeopardize NANOG's tax status. Can you be a bit more clear about why you > are concerned about this? Perhaps there's something I'm overlooking. > > As far as intellectual property goes, it would of course be up to the > presenter how much they would want to share publicly. Not all intellectual > property is a "trade secret", plenty is covered by copyrights and patents > and can generally be shared with an audience without granting said audience > unlimited rights to that intellectual property. For example, just because > you attend a concert with a particularly performer does not mean you then > have rights to illegally download that performer's mp3s. Of course anyone > who does treat their work product as a trade secret would not share such > work product with any audience. If a presenter did wish to share additional > information with the "shark"/investor participants above and beyond what is > shown to the general audience, they could establish non-disclosure > agreements with the interested parties. NDA's between potential investors > and recipients of investments are extremely common. This would of course be > between the presenter and their attorney to determine the appropriate > course of action and to draw up any relevant documents. Any time anyone is > considering accepting an investment in their work product, I would very > highly recommend that they engage an attorney whom they trust in order to > vet any agreements and ensure that they fully understand all ramifications > thereof. > > Good luck folks! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Lembesis at tevapharm.com Mon Jul 1 20:52:14 2019 From: Alex.Lembesis at tevapharm.com (Alex Lembesis) Date: Mon, 1 Jul 2019 20:52:14 +0000 Subject: Internap (AS 12178) Contact Message-ID: <5f422650a255407eba4821fd8ddf7854@USEXCAPP13.Teva.Corp> Wondering if anyone knows of a contact @ Internap that can reach out to me off-list. We're only receiving a default route from them now, when we should be receiving the full table. Any help is much appreciated. Thanks! This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alex.Lembesis at tevapharm.com Mon Jul 1 21:19:45 2019 From: Alex.Lembesis at tevapharm.com (Alex Lembesis) Date: Mon, 1 Jul 2019 21:19:45 +0000 Subject: Internap (AS 12178) Contact In-Reply-To: <5f422650a255407eba4821fd8ddf7854@USEXCAPP13.Teva.Corp> References: <5f422650a255407eba4821fd8ddf7854@USEXCAPP13.Teva.Corp> Message-ID: <8d0cf19761fb4bbca1ae33000e431568@USEXCAPP13.Teva.Corp> Was able to get in touch with someone. Thank you guys! From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Alex Lembesis (External) Sent: Monday, July 01, 2019 4:52 PM To: nanog at nanog.org Subject: Internap (AS 12178) Contact Wondering if anyone knows of a contact @ Internap that can reach out to me off-list. We're only receiving a default route from them now, when we should be receiving the full table. Any help is much appreciated. Thanks! This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. This message is intended solely for the designated recipient(s). It may contain confidential or proprietary information and may be subject to attorney-client privilege or other confidentiality protections. If you are not a designated recipient you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at satchell.net Tue Jul 2 14:16:36 2019 From: list at satchell.net (Stephen Satchell) Date: Tue, 2 Jul 2019 07:16:36 -0700 Subject: Intermittent "bad gateway" Message-ID: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> Are we having another BGP problem this morning? From ross at tajvar.io Tue Jul 2 14:20:52 2019 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 2 Jul 2019 10:20:52 -0400 Subject: Intermittent "bad gateway" In-Reply-To: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> References: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> Message-ID: Gotta be more specific than that... What carrier(s) are you using? If you do a traceroute do your packets take a weird path? Etc. On Tue, Jul 2, 2019, 10:19 AM Stephen Satchell wrote: > Are we having another BGP problem this morning? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason.w.kuehl at gmail.com Tue Jul 2 14:20:03 2019 From: jason.w.kuehl at gmail.com (Jason Kuehl) Date: Tue, 2 Jul 2019 10:20:03 -0400 Subject: Intermittent "bad gateway" In-Reply-To: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> References: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> Message-ID: Unknown but this looks very different from before. https://www.cloudflarestatus.com/ On Tue, Jul 2, 2019 at 10:18 AM Stephen Satchell wrote: > Are we having another BGP problem this morning? > -- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.kuehl at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhuff at ox.com Tue Jul 2 14:22:06 2019 From: mhuff at ox.com (Matthew Huff) Date: Tue, 2 Jul 2019 14:22:06 +0000 Subject: Intermittent "bad gateway" In-Reply-To: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> References: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> Message-ID: <0ee292e7322a45b0837e5a61f84a3aab@ox.com> We got reports on that on some cloudflare sites, but it disappeared pretty quickly. Looks like a CDN issue. -----Original Message----- From: NANOG On Behalf Of Stephen Satchell Sent: Tuesday, July 2, 2019 10:17 AM To: nanog at nanog.org Subject: Intermittent "bad gateway" Are we having another BGP problem this morning? From lists-nanog at schultz.top Tue Jul 2 14:23:13 2019 From: lists-nanog at schultz.top (Patrick Schultz) Date: Tue, 2 Jul 2019 16:23:13 +0200 Subject: Intermittent "bad gateway" In-Reply-To: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> References: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> Message-ID: <643d533b-5305-2132-074b-7f8f452f3623@schultz.top> citing https://www.cloudflarestatus.com/ >Cloudflare has implemented a fix for this issue and is currently monitoring the results Seems to be a CloudFlare hiccup. Am 02.07.2019 um 16:16 schrieb Stephen Satchell: > Are we having another BGP problem this morning? From mdr at tesp.com Tue Jul 2 14:23:18 2019 From: mdr at tesp.com (Michael Rathbun) Date: Tue, 02 Jul 2019 09:23:18 -0500 Subject: Intermittent "bad gateway" In-Reply-To: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> References: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> Message-ID: On Tue, 2 Jul 2019 07:16:36 -0700, Stephen Satchell wrote: >Are we having another BGP problem this morning? Cloudflare did fall over for a bit this morning. mdr -- Sometimes half-ass is exactly the right amount of ass. -- Wonderella From aveline at misaka.io Tue Jul 2 14:23:20 2019 From: aveline at misaka.io (Siyuan Miao) Date: Tue, 2 Jul 2019 22:23:20 +0800 Subject: Intermittent "bad gateway" In-Reply-To: References: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> Message-ID: Hah do you mean CloudFlare 502? On Tue, Jul 2, 2019 at 10:23 PM Ross Tajvar wrote: > Gotta be more specific than that... > > What carrier(s) are you using? If you do a traceroute do your packets take > a weird path? Etc. > > On Tue, Jul 2, 2019, 10:19 AM Stephen Satchell wrote: > >> Are we having another BGP problem this morning? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jk at ip-clear.de Tue Jul 2 14:25:15 2019 From: jk at ip-clear.de (=?utf-8?q?J=C3=B6rg?= Kost) Date: Tue, 02 Jul 2019 16:25:15 +0200 Subject: Intermittent "bad gateway" In-Reply-To: References: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> Message-ID: <02B3D537-B6F6-42F3-9BC9-F677F6746FC0@ip-clear.de> I think that Stephen is referring to a Cloudflare issue 20 minutes ago. On 2 Jul 2019, at 16:20, Ross Tajvar wrote: > Gotta be more specific than that... > > What carrier(s) are you using? If you do a traceroute do your packets take > a weird path? Etc. > > On Tue, Jul 2, 2019, 10:19 AM Stephen Satchell wrote: > >> Are we having another BGP problem this morning? >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kushal.r at h4g.co Tue Jul 2 14:28:00 2019 From: kushal.r at h4g.co (Kushal R.) Date: Tue, 2 Jul 2019 19:58:00 +0530 Subject: Intermittent "bad gateway" In-Reply-To: References: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> Message-ID: Most likely referring to the CloudFlare issue - https://www.cloudflarestatus.com/incidents/tx4pgxs6zxdr — Kushal R. Executive Management | Host4Geeks Email: kushal.r at h4g.co Skype: kush.raha Phone: +1-310-405-0010 On 2 July 2019 at 7:54:26 pm, Ross Tajvar (ross at tajvar.io) wrote: Gotta be more specific than that... What carrier(s) are you using? If you do a traceroute do your packets take a weird path? Etc. On Tue, Jul 2, 2019, 10:19 AM Stephen Satchell wrote: Are we having another BGP problem this morning? -------------- next part -------------- An HTML attachment was scrubbed... URL: From clayton at MNSi.Net Tue Jul 2 14:43:11 2019 From: clayton at MNSi.Net (Clayton Zekelman) Date: Tue, 02 Jul 2019 10:43:11 -0400 Subject: Intermittent "bad gateway" In-Reply-To: <02B3D537-B6F6-42F3-9BC9-F677F6746FC0@ip-clear.de> References: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> <02B3D537-B6F6-42F3-9BC9-F677F6746FC0@ip-clear.de> Message-ID: <1562078593_48734@surgemail.mnsi.net> I've had the same error on a Cloudflare hosted site (tineye.com) while trying to upload an image for search since yesterday. It's still happening as of a minute ago. At 10:25 AM 02/07/2019, Jörg Kost wrote: >I think that Stephen is referring to a Cloudflare issue 20 minutes ago. > >On 2 Jul 2019, at 16:20, Ross Tajvar wrote: >Gotta be more specific than that... > >What carrier(s) are you using? If you do a >traceroute do your packets take a weird path? Etc. > >On Tue, Jul 2, 2019, 10:19 AM Stephen Satchell ><list at satchell.net> wrote: >Are we having another BGP problem this morning? -------------- next part -------------- An HTML attachment was scrubbed... URL: From phin at phineas.io Tue Jul 2 14:20:37 2019 From: phin at phineas.io (Phineas) Date: Tue, 2 Jul 2019 15:20:37 +0100 Subject: Intermittent "bad gateway" In-Reply-To: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> References: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> Message-ID: Looks like it's an issue isolated to Cloudflare - Matthew tweeted: https://twitter.com/eastdakota/status/1146057946494713858 On Tue, Jul 2, 2019 at 3:19 PM Stephen Satchell wrote: > Are we having another BGP problem this morning? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhagman262 at gmail.com Tue Jul 2 14:35:58 2019 From: rhagman262 at gmail.com (Ryan Hagman) Date: Tue, 2 Jul 2019 10:35:58 -0400 Subject: Intermittent "bad gateway" In-Reply-To: References: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> Message-ID: https://www.cloudflarestatus.com/incidents/tx4pgxs6zxdr One hell of a fall. On Tue, Jul 2, 2019 at 10:33 AM Michael Rathbun wrote: > On Tue, 2 Jul 2019 07:16:36 -0700, Stephen Satchell > wrote: > > >Are we having another BGP problem this morning? > > Cloudflare did fall over for a bit this morning. > > mdr > -- > Sometimes half-ass is exactly the right amount of ass. > -- Wonderella > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Tue Jul 2 15:30:38 2019 From: bryan at shout.net (Bryan Holloway) Date: Tue, 2 Jul 2019 10:30:38 -0500 Subject: Intermittent "bad gateway" In-Reply-To: References: <3ca76aac-29a4-7d43-8817-a7ad9ddb89ba@satchell.net> Message-ID: Maybe Verizon can blog about it. On 7/2/19 9:35 AM, Ryan Hagman wrote: > https://www.cloudflarestatus.com/incidents/tx4pgxs6zxdr > > One hell of a fall. > > On Tue, Jul 2, 2019 at 10:33 AM Michael Rathbun > wrote: > > On Tue, 2 Jul 2019 07:16:36 -0700, Stephen Satchell > > > wrote: > > >Are we having another BGP problem this morning? > > Cloudflare did fall over for a bit this morning. > > mdr > -- >    Sometimes half-ass is exactly the right amount of ass. >        -- Wonderella > From mark.tinka at seacom.mu Wed Jul 3 04:35:56 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 3 Jul 2019 06:35:56 +0200 Subject: few big monolithic PEs vs many small PEs In-Reply-To: References: <005b01d526dc$c1af2800$450d7800$@netconsultings.com> <5024d726-e718-4852-73c5-6af8bb15b672@seacom.mu> Message-ID: <214d3b87-2222-a683-5ea9-72bcf375d1e2@seacom.mu> On 27/Jun/19 21:41, James Bensley wrote: > > > Large boxes like the MX2020, ASR9922, NCS6K, etc. these can only reasonably be used as P nodes in my opinion. The NCS6000 was always designed as a core router to replace the CRS. We just haven't seen the need for one since the CRS-X we run we operate (8-slot chassis) is still more than enough for our requirements. But yes, all of these edge routers, nowadays, are very decent core boxes also, particularly if you run a BGP-free core and have no need to support non-Ethernet links to any reasonable degree in there. Mark. From brak at gameservers.com Wed Jul 3 13:36:07 2019 From: brak at gameservers.com (Brian Rak) Date: Wed, 3 Jul 2019 09:36:07 -0400 Subject: Microsoft SNDS contact Message-ID: We've been trying to get SNDS access for our IP space, and we keep running into issues where the SNDS site is unable to determine what emails it should use to authorize access.  SNDS support has so far been very unhelpful, they keep trying to tell us to submit the space as individual /24's, which is less then helpful when we have multiple /18s we're trying to set up. Does anyone have a contact at Microsoft that can help? From christoffer at netravnen.de Wed Jul 3 13:50:01 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Wed, 3 Jul 2019 15:50:01 +0200 Subject: Microsoft SNDS contact In-Reply-To: References: Message-ID: <2cb8d125-cf3b-9cea-3f40-0d1895189932@netravnen.de> On 03/07/2019 15:36, Brian Rak wrote: > We've been trying to get SNDS access for our IP space, and we keep > running into issues where the SNDS site is unable to determine what > emails it should use to authorize access. What if you key in the AS ? $ whois -rB AS | grep @ % Abuse contact for 'AS' is '' https://sendersupport.olc.protection.outlook.com/snds/addnetwork.aspx Which RIR is your ASN listed with? Christoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From christoffer at netravnen.de Wed Jul 3 14:09:09 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Wed, 3 Jul 2019 16:09:09 +0200 Subject: Microsoft SNDS contact In-Reply-To: <2cb8d125-cf3b-9cea-3f40-0d1895189932@netravnen.de> References: <2cb8d125-cf3b-9cea-3f40-0d1895189932@netravnen.de> Message-ID: On 03/07/2019 15:50, Hansen, Christoffer wrote: > https://sendersupport.olc.protection.outlook.com/snds/addnetwork.aspx E.g. with asn 20473. Key that in. I can select the address fetched from a background WHOIS lookup by MS Smart Network Data Service. For the confirmation email to be sent to. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From brak at gameservers.com Wed Jul 3 14:13:09 2019 From: brak at gameservers.com (Brian Rak) Date: Wed, 3 Jul 2019 10:13:09 -0400 Subject: [EXTERNAL] Re: Microsoft SNDS contact In-Reply-To: References: <2cb8d125-cf3b-9cea-3f40-0d1895189932@netravnen.de> Message-ID: <908b5ee9-6c0c-5d2e-59b3-c0ce42c3dfd1@gameservers.com> On 7/3/2019 10:09 AM, Hansen, Christoffer wrote: > On 03/07/2019 15:50, Hansen, Christoffer wrote: >> https://sendersupport.olc.protection.outlook.com/snds/addnetwork.aspx > E.g. with asn 20473. Key that in. I can select the address fetched from > a background WHOIS lookup by MS Smart Network Data Service. For the > confirmation email to be sent to. > We've tried this approach in the past, but it ends up dragging in a lot of IP space that we're announcing on behalf of customers. This is less then ideal, as then we either have to go back and manually remove all the customer owned IP space, or deal with a bunch of noise from it.  We'd be willing to accept that as a solution if it were a one-off thing, but it's a lot of extra work to do every time we acquire more IP space. From christoffer at netravnen.de Wed Jul 3 14:29:20 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Wed, 3 Jul 2019 16:29:20 +0200 Subject: [nanog] Trouble adding ip space to sdns account (WAS: Microsoft SDNS contact) In-Reply-To: <908b5ee9-6c0c-5d2e-59b3-c0ce42c3dfd1@gameservers.com> References: <2cb8d125-cf3b-9cea-3f40-0d1895189932@netravnen.de> <908b5ee9-6c0c-5d2e-59b3-c0ce42c3dfd1@gameservers.com> Message-ID: Brian, On 03/07/2019 16:13, Brian Rak wrote: > We've tried this approach in the past, but it ends up dragging in a lot > of IP space that we're announcing on behalf of customers. You willing to share the IP blocks you have trouble adding to your SDNS account? (on- or off-list, whichever you prefer) Christoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From brak at gameservers.com Wed Jul 3 14:46:23 2019 From: brak at gameservers.com (Brian Rak) Date: Wed, 3 Jul 2019 10:46:23 -0400 Subject: [EXTERNAL] Re: Microsoft SNDS contact In-Reply-To: References: <2cb8d125-cf3b-9cea-3f40-0d1895189932@netravnen.de> <908b5ee9-6c0c-5d2e-59b3-c0ce42c3dfd1@gameservers.com> Message-ID: <53d05b69-1497-b6d6-adeb-65165040cbeb@gameservers.com> Yea, that's the email we've been using (that's trying to tell us to just split it into /24s) On 7/3/2019 10:27 AM, Udeme Ukutt wrote: > Hey Brian - try msn-snds at microsoft.com > . IIRC that's more geared towards JMRP, > but I think there's a chance. > > Udeme > Postmaster at Wish > > On Wed, Jul 3, 2019 at 10:14 AM Brian Rak > wrote: > > > On 7/3/2019 10:09 AM, Hansen, Christoffer wrote: > > On 03/07/2019 15:50, Hansen, Christoffer wrote: > >> > https://sendersupport.olc.protection.outlook.com/snds/addnetwork.aspx > > E.g. with asn 20473. Key that in. I can select the address > fetched from > > a background WHOIS lookup by MS Smart Network Data Service. For the > > confirmation email to be sent to. > > > > We've tried this approach in the past, but it ends up dragging in > a lot > of IP space that we're announcing on behalf of customers. This is > less > then ideal, as then we either have to go back and manually remove all > the customer owned IP space, or deal with a bunch of noise from it. > We'd be willing to accept that as a solution if it were a one-off > thing, > but it's a lot of extra work to do every time we acquire more IP > space. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From curtis at generous.com Thu Jul 4 01:38:40 2019 From: curtis at generous.com (Curtis Generous) Date: Wed, 03 Jul 2019 21:38:40 -0400 Subject: Any contact at VERIZON who manages @VTEXT.COM? Message-ID: <5DEC93C4-1D2A-4B48-A31D-F40CD8C787C5@generous.com> We started seeing emails to @VTEXT.COM being periodically rejected earlier in the week, and now most/all our getting soft-bounced. Anyone here on the list have contact info at VERIZON who can assist in troubleshooting this?  All normal channels to get hold of their support have failed Thanks --curtis -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Thu Jul 4 09:46:05 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 4 Jul 2019 11:46:05 +0200 Subject: CloudFlare issues? In-Reply-To: References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> Message-ID: <40120735-b4f7-2e4f-6aca-d0920c461ed6@seacom.mu> I finally thought about this after I got off my beer high :-). Some of our customers complained about losing access to Cloudflare's resources during the Verizon debacle. Since we are doing ROV and dropping Invalids, this should not have happened, given most of Cloudflare's IPv4 and IPv6 routes are ROA'd. However, since we are not using the ARIN TAL (for known reasons), this explains why this also broke for us. Back to beer now :-)... Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnschmidt at i3d.net Thu Jul 4 09:56:32 2019 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Thu, 4 Jul 2019 09:56:32 +0000 Subject: CloudFlare issues? In-Reply-To: <40120735-b4f7-2e4f-6aca-d0920c461ed6@seacom.mu> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> <40120735-b4f7-2e4f-6aca-d0920c461ed6@seacom.mu> Message-ID: <56f186b1-7899-f685-ae5b-6aec84a02e34@i3d.net> So that means it's time for everyone to migrate their ARIN resources to a sane RIR that does allow normal access to and redistribution of its RPKI TAL? ;-) The RPKI TAL problem + an industry-standard IRRDB instead of WHOIS-RWS were both major reasons for us to bring our ARIN IPv4 address space to RIPE. Unfortunately we had to renumber our handful of IPv6 customers because ARIN doesn't do IPv6 inter-RIR transfers, but hey, no pain no gain. Therefore, Cloudflare folks - when are you transferring your resources away from ARIN? :D Best regards, Martijn On 7/4/19 11:46 AM, Mark Tinka wrote: I finally thought about this after I got off my beer high :-). Some of our customers complained about losing access to Cloudflare's resources during the Verizon debacle. Since we are doing ROV and dropping Invalids, this should not have happened, given most of Cloudflare's IPv4 and IPv6 routes are ROA'd. However, since we are not using the ARIN TAL (for known reasons), this explains why this also broke for us. Back to beer now :-)... Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Francois.Lecavalier at mindgeek.com Thu Jul 4 15:22:23 2019 From: Francois.Lecavalier at mindgeek.com (Francois Lecavalier) Date: Thu, 4 Jul 2019 15:22:23 +0000 Subject: CloudFlare issues? Message-ID: Hi Mark, Following that Verizon debacle I got onboard with ROV, after a couple research I stopped my choice on the ....drum roll.... CloudFlare GoRTR (https://github.com/cloudflare/gortr). If you trust them enough they provide an updated JSON every 15 minutes of the global RIR aggregate. I'll see down the road if we'll fetch them ourselves but at least it got us up and running in less than an hour. It was also easy for us to deploy as the routers and the servers are on the same PoP directly connected, so we don't need the whole encryption recipe they provide for mass distribution. But I also have a question for all the ROA folks out there. So far we are not taking any action other than lowering the local-pref - we want to make sure this is stable before we start denying prefixes. So the question, is it safe as of this date to : 1.Accept valid, 2. Accept unknown, 3. Reject invalid? Have any large network who implemented it dealt with unreachable destinations? I'm wondering as I haven't found any blog mentioning anything in this regard and ClouFlare docs only shows example for valid and invalid, but nothing for unknown. My assumption is that 1.Accept valid, 2. Accept unknown, 3. Reject invalid shouldn't break anything. Thanks, -Francois This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier ?lectronique est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous recevez ce courrier ?lectronique par erreur, veuillez m'en aviser imm?diatement, par retour de courrier ?lectronique ou par un autre moyen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Thu Jul 4 15:33:57 2019 From: job at ntt.net (Job Snijders) Date: Thu, 4 Jul 2019 17:33:57 +0200 Subject: CloudFlare issues? In-Reply-To: References: Message-ID: <20190704153357.GF49950@hanna.meerval.net> Dear Francois, On Thu, Jul 04, 2019 at 03:22:23PM +0000, Francois Lecavalier wrote: > Following that Verizon debacle I got onboard with ROV, after a couple > research I stopped my choice on the ....drum roll.... CloudFlare GoRTR > (https://github.com/cloudflare/gortr). If you trust them enough they > provide an updated JSON every 15 minutes of the global RIR aggregate. At this point in time I think the ideal deployment model is to perform the validation within your administrative domain and run your own validators. You can combine routinator with gortr, or use cloudflare's octorpki software https://github.com/cloudflare/cfrpki > I'll see down the road if we'll fetch them ourselves but at least it > got us up and running in less than an hour. It was also easy for us > to deploy as the routers and the servers are on the same PoP directly > connected, so we don't need the whole encryption recipe they provide > for mass distribution. yeah, that is true! > But I also have a question for all the ROA folks out there. So far we > are not taking any action other than lowering the local-pref - we want > to make sure this is stable before we start denying prefixes. So the > question, is it safe as of this date to : 1.Accept valid, 2. Accept > unknown, 3. Reject invalid? Have any large network who implemented it > dealt with unreachable destinations? I'm wondering as I haven't found > any blog mentioning anything in this regard and ClouFlare docs only > shows example for valid and invalid, but nothing for unknown. I believe at this point in time it is safe to accept valid and unknown (combined with an IRR filter), and reject RPKI invalid BGP announcements at your EBGP borders. Large examples of other organisations who already are rejecting invalid announcements are AT&T, Nordunet, DE-CIX, YYCIX, XS4ALL, MSK-IX, INEX, France-IX, Seacomm, Workonline, KPN International, and hundreds of others. You can run an analysis yourself to see how traffic would be impacted in your network using pmacct or Kentik, see this post for more info: https://mailman.nanog.org/pipermail/nanog/2019-February/099522.html > My assumption is that 1.Accept valid, 2. Accept unknown, 3. Reject > invalid shouldn't break anything. Correct! Let us know how it went :-) Kind regards, Job From benm at workonline.africa Thu Jul 4 15:50:47 2019 From: benm at workonline.africa (Ben Maddison) Date: Thu, 4 Jul 2019 15:50:47 +0000 Subject: CloudFlare issues? In-Reply-To: <20190704153357.GF49950@hanna.meerval.net> References: <20190704153357.GF49950@hanna.meerval.net> Message-ID: <69fbe93d64a0b5a2e5df93648e506fe6e3c9c861.camel@workonline.africa> Hi Francois, On Thu, 2019-07-04 at 17:33 +0200, Job Snijders wrote: > Dear Francois, > > On Thu, Jul 04, 2019 at 03:22:23PM +0000, Francois Lecavalier wrote: > > > At this point in time I think the ideal deployment model is to > perform > the validation within your administrative domain and run your own > validators. +1 > > > But I also have a question for all the ROA folks out there. So far > > we > > are not taking any action other than lowering the local-pref - we > > want > > to make sure this is stable before we start denying prefixes. So > > the > > question, is it safe as of this date to : 1.Accept valid, 2. Accept > > unknown, 3. Reject invalid? Have any large network who implemented > > it > > dealt with unreachable destinations? I'm wondering as I haven't > > found > > any blog mentioning anything in this regard and ClouFlare docs only > > shows example for valid and invalid, but nothing for unknown. > We have been dropping Invalids since April, and have had only a (single-digit) handful of support requests related to those becoming unreachable. The larger challenge has been related to vendor implementation choices and bugs, particularly on ios-xe. Happy to go into more detail if anyone is interested. I would recommend *not* taking any policy action that distinguishes Valid from Unknown. If you find that you have routes for the same prefix/len with both statuses, then that is a bug and/or misconfiguration which you could turn into a loop by taking policy action on that difference. Cheers, Ben From mark.tinka at seacom.mu Thu Jul 4 17:10:11 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 4 Jul 2019 19:10:11 +0200 Subject: CloudFlare issues? In-Reply-To: References: Message-ID: <0ef7b4f2-2b23-ea4a-9eb7-a3159dc50353@seacom.mu> On 4/Jul/19 17:22, Francois Lecavalier wrote: >   > > Following that Verizon debacle I got onboard with ROV, after a couple > research I stopped my choice on the ….drum roll…. CloudFlare GoRTR > (https://github.com/cloudflare/gortr).  If you trust them enough they > provide an updated JSON every 15 minutes of the global RIR aggregate.  > I’ll see down the road if we’ll fetch them ourselves but at least it > got us up and running in less than an hour.  It was also easy for us > to deploy as the routers and the servers are on the same PoP directly > connected, so we don’t need the whole encryption recipe they provide > for mass distribution. > Funny you should mention this... I was speaking with Tom today during an RPKI talk he gave at MyNOG, about whether we'd be willing to trust their RTR streams. But, I'm glad you found a quick solution to get you up and running. Welcome to the club. >   > > But I also have a question for all the ROA folks out there.  So far we > are not taking any action other than lowering the local-pref – we want > to make sure this is stable before we start denying prefixes.  So the > question, is it safe as of this date to : 1.Accept valid, 2. Accept > unknown, 3. Reject invalid?  Have any large network who implemented it > dealt with unreachable destinations?  I’m wondering as I haven’t found > any blog mentioning anything in this regard and ClouFlare docs only > shows example for valid and invalid, but nothing for unknown. > >   > > My assumption is that 1.Accept valid, 2. Accept unknown, 3. Reject > invalid shouldn’t break anything. > Well, a Valid and NotFound state implicitly mean that the routes can be used for routing/forwarding. In that case, the only policy we create and apply is against Invalid routes, which is to DROP them. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Thu Jul 4 17:13:42 2019 From: nick at foobar.org (Nick Hilliard) Date: Thu, 4 Jul 2019 18:13:42 +0100 Subject: CloudFlare issues? In-Reply-To: References: Message-ID: <07da7a47-175d-494d-d101-cc4e22c9c54e@foobar.org> Francois Lecavalier wrote on 04/07/2019 16:22: > My assumption is that 1.Accept valid, 2. Accept unknown, 3. Reject > invalid shouldn’t break anything. Accepting valid ROAs is a better idea after checking that the source AS is legitimate from the peer. Nick From mark.tinka at seacom.mu Thu Jul 4 17:14:46 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 4 Jul 2019 19:14:46 +0200 Subject: CloudFlare issues? In-Reply-To: <20190704153357.GF49950@hanna.meerval.net> References: <20190704153357.GF49950@hanna.meerval.net> Message-ID: <8ce587ce-350d-47d1-b595-00563cfb7f69@seacom.mu> On 4/Jul/19 17:33, Job Snijders wrote: > At this point in time I think the ideal deployment model is to perform > the validation within your administrative domain and run your own > validators. In essence, this is also my thought process. I think Cloudflare are very well-intentioned in making it as painless as possible to support other operators to get RPKI deployed (and more power to them to going to such lengths to do so), but you have to determine whether you are willing to let a service such as this run outside of our domain. Every year, someone asks me whether I'd be willing to outsource my route reflector VNF's to AWS/Azure/e.t.c. My answer to that falls within the realms of handling RPKI for your network :-). Mark. From mark.tinka at seacom.mu Thu Jul 4 17:17:36 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 4 Jul 2019 19:17:36 +0200 Subject: CloudFlare issues? In-Reply-To: <69fbe93d64a0b5a2e5df93648e506fe6e3c9c861.camel@workonline.africa> References: <20190704153357.GF49950@hanna.meerval.net> <69fbe93d64a0b5a2e5df93648e506fe6e3c9c861.camel@workonline.africa> Message-ID: <2c3ffab2-3ac4-253e-cb74-3648cdff0123@seacom.mu> On 4/Jul/19 17:50, Ben Maddison via NANOG wrote: > We have been dropping Invalids since April, and have had only a > (single-digit) handful of support requests related to those becoming > unreachable. We've had 2 cases where customers could not reach a prefix. Both were mistakes (as we've found most Invalid routes to be), which were promptly fixed. One of them was where a cloud provider decided to originate a longer prefix on behalf of their content-producing customer, using their own AS as opposed to the one the customer had used to create the ROA for the covering block. Mark. From jason+nanog at lixfeld.ca Thu Jul 4 18:14:21 2019 From: jason+nanog at lixfeld.ca (Jason Lixfeld) Date: Thu, 4 Jul 2019 14:14:21 -0400 Subject: Real-world MPLS P/LSR experience on BCM T3 (X5/X7) vs T2+ Message-ID: <983F7EC3-F4A6-49EB-BA98-2FFCA86E9848@lixfeld.ca> Hey all, In the role of an MPLS P/LSR, I’m curious if there have been any gotchas (or fixes) revealed with BCM T3 vs. T2+. I remember reading somewhere some years ago that there were oddities on the T2+ that I’d like to believe have been addressed on T3, but does anyone have any real-world experience with T3 in an MPLS core? (IS-IS, LDP, rLFA, 2-3 labels wide, likely SR/Seamless/BGP-LU/whatever down the road) I’m sure J, C, A, etc. all have their own challenges wrapping their code around the APIs, so would be curious to hear anything anyone has to share along those lines as well. Thanks in advance. From Francois.Lecavalier at mindgeek.com Thu Jul 4 18:46:46 2019 From: Francois.Lecavalier at mindgeek.com (Francois Lecavalier) Date: Thu, 4 Jul 2019 18:46:46 +0000 Subject: CloudFlare issues? In-Reply-To: <69fbe93d64a0b5a2e5df93648e506fe6e3c9c861.camel@workonline.africa> References: <20190704153357.GF49950@hanna.meerval.net> <69fbe93d64a0b5a2e5df93648e506fe6e3c9c861.camel@workonline.africa> Message-ID: <83e2bf6a0e8a46cbbe87db246e771297@mindgeek.com> >> At this point in time I think the ideal deployment model is to perform >> the validation within your administrative domain and run your own >> validators. >+1 We'll definitely look into this shortly. I definitely don't want to leave a security measure in the end of a third party but with my team being so busy it was a quick temp fix. > The larger challenge has been related to vendor implementation choices and bugs, particularly on ios-xe. Happy to go into more detail if anyone is interested. We are on Juniper MX204's at the edge and they have been solid for the last 60 weeks - we ran into a long list of bugs on other platforms but not on these. So I had about 4200 routes marked as invalid. After looking at a sample of them it looks like most of them have a valid ROA with an improper mask length - so there is ultimately a route to these prefixes and at worse would result in "suboptimal" routing - or should I say: the remote network can't control its route propagation anymore. In most case they are a stub networks with a single /24 reassigned from the upstream provider. I have no traffic going directly to these networks and I don't expect any to go there anytime soon. It's been close to 3 hours now since I dropped them - radio silence. Whoever fears implementing RPKI/ROA/ROV, simply don't. It's very easy to implement, validate and troubleshoot. -----Original Message----- From: Ben Maddison Sent: Thursday, July 4, 2019 11:51 AM To: job at ntt.net; Francois Lecavalier Cc: nanog at nanog.org Subject: [External] Re: CloudFlare issues? Hi Francois, On Thu, 2019-07-04 at 17:33 +0200, Job Snijders wrote: > Dear Francois, > > On Thu, Jul 04, 2019 at 03:22:23PM +0000, Francois Lecavalier wrote: > > > At this point in time I think the ideal deployment model is to perform > the validation within your administrative domain and run your own > validators. +1 > > > But I also have a question for all the ROA folks out there. So far > > we are not taking any action other than lowering the local-pref - we > > want to make sure this is stable before we start denying prefixes. > > So the question, is it safe as of this date to : 1.Accept valid, 2. > > Accept unknown, 3. Reject invalid? Have any large network who > > implemented it dealt with unreachable destinations? I'm wondering > > as I haven't found any blog mentioning anything in this regard and > > ClouFlare docs only shows example for valid and invalid, but nothing > > for unknown. > We have been dropping Invalids since April, and have had only a (single-digit) handful of support requests related to those becoming unreachable. The larger challenge has been related to vendor implementation choices and bugs, particularly on ios-xe. Happy to go into more detail if anyone is interested. I would recommend *not* taking any policy action that distinguishes Valid from Unknown. If you find that you have routes for the same prefix/len with both statuses, then that is a bug and/or misconfiguration which you could turn into a loop by taking policy action on that difference. Cheers, Ben This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen. From benm at workonline.africa Thu Jul 4 18:54:04 2019 From: benm at workonline.africa (Ben Maddison) Date: Thu, 4 Jul 2019 18:54:04 +0000 Subject: CloudFlare issues? In-Reply-To: <83e2bf6a0e8a46cbbe87db246e771297@mindgeek.com> References: <20190704153357.GF49950@hanna.meerval.net> <69fbe93d64a0b5a2e5df93648e506fe6e3c9c861.camel@workonline.africa>, <83e2bf6a0e8a46cbbe87db246e771297@mindgeek.com> Message-ID: Welcome to the club! Get Outlook for Android ________________________________ From: Francois Lecavalier Sent: Thursday, July 4, 2019 8:46:46 PM To: Ben Maddison; job at ntt.net Cc: nanog at nanog.org Subject: RE: CloudFlare issues? >> At this point in time I think the ideal deployment model is to perform >> the validation within your administrative domain and run your own >> validators. >+1 We'll definitely look into this shortly. I definitely don't want to leave a security measure in the end of a third party but with my team being so busy it was a quick temp fix. > The larger challenge has been related to vendor implementation choices and bugs, particularly on ios-xe. Happy to go into more detail if anyone is interested. We are on Juniper MX204's at the edge and they have been solid for the last 60 weeks - we ran into a long list of bugs on other platforms but not on these. So I had about 4200 routes marked as invalid. After looking at a sample of them it looks like most of them have a valid ROA with an improper mask length - so there is ultimately a route to these prefixes and at worse would result in "suboptimal" routing - or should I say: the remote network can't control its route propagation anymore. In most case they are a stub networks with a single /24 reassigned from the upstream provider. I have no traffic going directly to these networks and I don't expect any to go there anytime soon. It's been close to 3 hours now since I dropped them - radio silence. Whoever fears implementing RPKI/ROA/ROV, simply don't. It's very easy to implement, validate and troubleshoot. -----Original Message----- From: Ben Maddison Sent: Thursday, July 4, 2019 11:51 AM To: job at ntt.net; Francois Lecavalier Cc: nanog at nanog.org Subject: [External] Re: CloudFlare issues? Hi Francois, On Thu, 2019-07-04 at 17:33 +0200, Job Snijders wrote: > Dear Francois, > > On Thu, Jul 04, 2019 at 03:22:23PM +0000, Francois Lecavalier wrote: > > > At this point in time I think the ideal deployment model is to perform > the validation within your administrative domain and run your own > validators. +1 > > > But I also have a question for all the ROA folks out there. So far > > we are not taking any action other than lowering the local-pref - we > > want to make sure this is stable before we start denying prefixes. > > So the question, is it safe as of this date to : 1.Accept valid, 2. > > Accept unknown, 3. Reject invalid? Have any large network who > > implemented it dealt with unreachable destinations? I'm wondering > > as I haven't found any blog mentioning anything in this regard and > > ClouFlare docs only shows example for valid and invalid, but nothing > > for unknown. > We have been dropping Invalids since April, and have had only a (single-digit) handful of support requests related to those becoming unreachable. The larger challenge has been related to vendor implementation choices and bugs, particularly on ios-xe. Happy to go into more detail if anyone is interested. I would recommend *not* taking any policy action that distinguishes Valid from Unknown. If you find that you have routes for the same prefix/len with both statuses, then that is a bug and/or misconfiguration which you could turn into a loop by taking policy action on that difference. Cheers, Ben This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Thu Jul 4 18:57:26 2019 From: job at ntt.net (Job Snijders) Date: Thu, 4 Jul 2019 20:57:26 +0200 Subject: CloudFlare issues? In-Reply-To: <83e2bf6a0e8a46cbbe87db246e771297@mindgeek.com> References: <20190704153357.GF49950@hanna.meerval.net> <69fbe93d64a0b5a2e5df93648e506fe6e3c9c861.camel@workonline.africa> <83e2bf6a0e8a46cbbe87db246e771297@mindgeek.com> Message-ID: On Thu, Jul 4, 2019 at 8:46 PM Francois Lecavalier wrote: > It's been close to 3 hours now since I dropped them - radio silence. I am going to assume that "radio silence" for you means that your network is fully functional and none of your customers have raised issues! :-) > Whoever fears implementing RPKI/ROA/ROV, simply don't. It's very easy to implement, validate and troubleshoot. Thank you for sharing your report. I believe it is good to share rpki stories with each other, not just to celebrate the deployment of an exciting technology, but also to help provide debugging information ahead of time should there be issues between provider A and B due to a ROA misconfiguration. Announcing to the public that one has deployed RPKI - in this stage of the lifecycle of the tech - probably is a productive action to consider. Anyway, you can now enjoy https://rpki.net/s/rpki-test even more! :-) Kind regards, Job From mark.tinka at seacom.mu Thu Jul 4 18:59:34 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 4 Jul 2019 20:59:34 +0200 Subject: CloudFlare issues? In-Reply-To: <83e2bf6a0e8a46cbbe87db246e771297@mindgeek.com> References: <20190704153357.GF49950@hanna.meerval.net> <69fbe93d64a0b5a2e5df93648e506fe6e3c9c861.camel@workonline.africa> <83e2bf6a0e8a46cbbe87db246e771297@mindgeek.com> Message-ID: <3c3db53c-818a-4fc6-aaf0-d79a1c51c52d@seacom.mu> On 4/Jul/19 20:46, Francois Lecavalier wrote: > It's been close to 3 hours now since I dropped them - radio silence. > > Whoever fears implementing RPKI/ROA/ROV, simply don't. It's very easy to implement, validate and troubleshoot. Well done! Congrats! Mark. From mark.tinka at seacom.mu Thu Jul 4 18:59:55 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 4 Jul 2019 20:59:55 +0200 Subject: CloudFlare issues? In-Reply-To: <83e2bf6a0e8a46cbbe87db246e771297@mindgeek.com> References: <20190704153357.GF49950@hanna.meerval.net> <69fbe93d64a0b5a2e5df93648e506fe6e3c9c861.camel@workonline.africa> <83e2bf6a0e8a46cbbe87db246e771297@mindgeek.com> Message-ID: On 4/Jul/19 20:46, Francois Lecavalier wrote: > It's been close to 3 hours now since I dropped them - radio silence. > > Whoever fears implementing RPKI/ROA/ROV, simply don't. It's very easy to implement, validate and troubleshoot. Well done! Congrats! Mark. From job at ntt.net Thu Jul 4 19:20:39 2019 From: job at ntt.net (Job Snijders) Date: Thu, 4 Jul 2019 21:20:39 +0200 Subject: CloudFlare issues? In-Reply-To: References: <20190704153357.GF49950@hanna.meerval.net> <69fbe93d64a0b5a2e5df93648e506fe6e3c9c861.camel@workonline.africa> <83e2bf6a0e8a46cbbe87db246e771297@mindgeek.com> Message-ID: > Anyway, you can now enjoy https://rpki.net/s/rpki-test even more! :-) my apologies, I fumbled the ball on typing in that URL, I intended to point here: https://www.ripe.net/s/rpki-test From cscora at apnic.net Fri Jul 5 18:04:06 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 6 Jul 2019 04:04:06 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190705180407.1AAE2C44A1@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 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 06 Jul, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 760370 Prefixes after maximum aggregation (per Origin AS): 293074 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 366150 Total ASes present in the Internet Routing Table: 64764 Prefixes per ASN: 11.74 Origin-only ASes present in the Internet Routing Table: 55696 Origin ASes announcing only one prefix: 23947 Transit ASes present in the Internet Routing Table: 9068 Transit-only ASes present in the Internet Routing Table: 284 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 42 Max AS path prepend of ASN ( 27978) 31 Prefixes from unregistered ASNs in the Routing Table: 22 Number of instances of unregistered ASNs: 24 Number of 32-bit ASNs allocated by the RIRs: 27720 Number of 32-bit ASNs visible in the Routing Table: 22620 Prefixes from 32-bit ASNs in the Routing Table: 102165 Number of bogon 32-bit ASNs visible in the Routing Table: 17 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 217 Number of addresses announced to Internet: 2838933888 Equivalent to 169 /8s, 54 /16s and 177 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.3 Total number of prefixes smaller than registry allocations: 252618 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 205898 Total APNIC prefixes after maximum aggregation: 61349 APNIC Deaggregation factor: 3.36 Prefixes being announced from the APNIC address blocks: 201560 Unique aggregates announced from the APNIC address blocks: 84128 APNIC Region origin ASes present in the Internet Routing Table: 9868 APNIC Prefixes per ASN: 20.43 APNIC Region origin ASes announcing only one prefix: 2749 APNIC Region transit ASes present in the Internet Routing Table: 1476 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4868 Number of APNIC addresses announced to Internet: 770901888 Equivalent to 45 /8s, 243 /16s and 7 /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-141625 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: 225924 Total ARIN prefixes after maximum aggregation: 105561 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 225090 Unique aggregates announced from the ARIN address blocks: 106979 ARIN Region origin ASes present in the Internet Routing Table: 18511 ARIN Prefixes per ASN: 12.16 ARIN Region origin ASes announcing only one prefix: 6867 ARIN Region transit ASes present in the Internet Routing Table: 1905 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2786 Number of ARIN addresses announced to Internet: 1067927168 Equivalent to 63 /8s, 167 /16s and 70 /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-399260 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, 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: 209782 Total RIPE prefixes after maximum aggregation: 99531 RIPE Deaggregation factor: 2.11 Prefixes being announced from the RIPE address blocks: 205861 Unique aggregates announced from the RIPE address blocks: 122658 RIPE Region origin ASes present in the Internet Routing Table: 26193 RIPE Prefixes per ASN: 7.86 RIPE Region origin ASes announcing only one prefix: 11584 RIPE Region transit ASes present in the Internet Routing Table: 3732 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 35 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8244 Number of RIPE addresses announced to Internet: 720259712 Equivalent to 42 /8s, 238 /16s and 74 /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-210331 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: 97349 Total LACNIC prefixes after maximum aggregation: 22262 LACNIC Deaggregation factor: 4.37 Prefixes being announced from the LACNIC address blocks: 98646 Unique aggregates announced from the LACNIC address blocks: 42909 LACNIC Region origin ASes present in the Internet Routing Table: 8592 LACNIC Prefixes per ASN: 11.48 LACNIC Region origin ASes announcing only one prefix: 2289 LACNIC Region transit ASes present in the Internet Routing Table: 1575 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 39 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 6143 Number of LACNIC addresses announced to Internet: 173820928 Equivalent to 10 /8s, 92 /16s and 76 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 21394 Total AfriNIC prefixes after maximum aggregation: 4353 AfriNIC Deaggregation factor: 4.91 Prefixes being announced from the AfriNIC address blocks: 28996 Unique aggregates announced from the AfriNIC address blocks: 9283 AfriNIC Region origin ASes present in the Internet Routing Table: 1301 AfriNIC Prefixes per ASN: 22.29 AfriNIC Region origin ASes announcing only one prefix: 458 AfriNIC Region transit ASes present in the Internet Routing Table: 255 Average AfriNIC Region AS path length visible: 4.9 Max AfriNIC Region AS path length visible: 27 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 579 Number of AfriNIC addresses announced to Internet: 105794560 Equivalent to 6 /8s, 78 /16s and 76 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 45/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 7545 4808 564 544 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3221 1459 31 VIETEL-AS-AP Viettel Group, VN 45899 3013 1738 121 VNPT-AS-VN VNPT Corp, VN 9808 2773 9043 63 CMNET-GD Guangdong Mobile Communication 9829 2696 1489 562 BSNL-NIB National Internet Backbone, IN 4766 2515 11119 760 KIXS-AS-KR Korea Telecom, KR 4755 2142 428 183 TATACOMM-AS TATA Communications formerl 9394 2094 4882 26 CTTNET China TieTong Telecommunications 9498 2082 427 172 BBIL-AP BHARTI Airtel Ltd., IN 7713 2058 608 612 TELKOMNET-AS-AP PT Telekomunikasi Indon 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 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3679 240 616 CABLEONE - CABLE ONE, INC., US 6327 3577 1324 90 SHAW - Shaw Communications Inc., CA 22773 3431 2974 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 2984 6377 1368 AMAZON-02 - Amazon.com, Inc., US 16625 2621 1378 1900 AKAMAI-AS - Akamai Technologies, Inc., 30036 2157 347 246 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2152 2762 524 CHARTER-20115 - Charter Communications, 18566 2098 405 107 MEGAPATH5-US - MegaPath Corporation, US 5650 2083 3074 1459 FRONTIER-FRTR - Frontier Communications 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 5435 1629 141 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3232 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2705 512 1934 AKAMAI-ASN1, US 12389 2350 2230 662 ROSTELECOM-AS, RU 34984 2095 344 546 TELLCOM-AS, TR 9121 1641 1692 19 TTNET, TR 9009 1631 177 876 M247, GB 13188 1604 100 47 TRIOLAN, UA 61317 1468 151 496 ASDETUK http://www.heficed.com, GB 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 6220 3355 592 Uninet S.A. de C.V., MX 10620 3409 534 440 Telmex Colombia S.A., CO 11830 2696 370 54 Instituto Costarricense de Electricidad 7303 1474 1022 274 Telecom Argentina S.A., AR 6503 1219 425 53 Axtel, S.A.B. de C.V., MX 28573 1166 2243 206 CLARO S.A., BR 6147 1095 377 31 Telefonica del Peru S.A.A., PE 3816 1040 524 114 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 975 468 241 Mega Cable, S.A. de C.V., MX 11172 937 112 61 Alestra, S. de R.L. de C.V., MX 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 393 22 LINKdotNET-AS, EG 37611 970 107 9 Afrihost, ZA 24835 885 634 22 RAYA-AS, EG 36992 838 1535 77 ETISALAT-MISR, EG 36903 831 418 129 MT-MPLS, MA 8452 676 1859 20 TE-AS TE-AS, EG 29571 518 68 11 ORANGE-COTE-IVOIRE, CI 37492 483 470 56 ORANGE-, TN 37342 408 32 1 MOVITEL, MZ 15399 386 45 11 WANANCHI-, KE 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 8151 6220 3355 592 Uninet S.A. de C.V., MX 12479 5435 1629 141 UNI2-AS, ES 7545 4808 564 544 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3679 240 616 CABLEONE - CABLE ONE, INC., US 6327 3577 1324 90 SHAW - Shaw Communications Inc., CA 22773 3431 2974 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3409 534 440 Telmex Colombia S.A., CO 8551 3232 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5435 5294 UNI2-AS, ES 7545 4808 4264 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 4039 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3577 3487 SHAW - Shaw Communications Inc., CA 22773 3431 3274 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 7552 3221 3190 VIETEL-AS-AP Viettel Group, VN 8551 3232 3186 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11492 3679 3063 CABLEONE - CABLE ONE, INC., US 10620 3409 2969 Telmex Colombia S.A., CO 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 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.184.9.0/24 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 41.76.136.0/22 37500 -Reserved AS-, ZZ 41.76.140.0/22 37500 -Reserved AS-, ZZ 41.78.180.0/23 37265 -Reserved AS-, ZZ 41.220.48.0/20 36900 -Reserved AS-, ZZ 41.242.92.0/24 37643 -Reserved AS-, ZZ 41.242.93.0/24 37643 -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:10 /9:11 /10:37 /11:100 /12:294 /13:569 /14:1135 /15:1911 /16:13256 /17:8002 /18:13939 /19:25814 /20:40323 /21:47471 /22:95060 /23:76939 /24:434610 /25:889 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4389 5435 UNI2-AS, ES 6327 3366 3577 SHAW - Shaw Communications Inc., CA 7155 3156 4064 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2883 3679 CABLEONE - CABLE ONE, INC., US 8551 2685 3232 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2664 3431 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2044 2696 Instituto Costarricense de Electricidad y Telec 18566 1993 2098 MEGAPATH5-US - MegaPath Corporation, US 30036 1908 2157 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1704 2:1054 3:6 4:19 5:3062 6:45 7:1 8:1342 9:1 11:1 12:1808 13:367 14:2065 15:38 16:6 17:258 18:79 20:57 23:2808 24:2574 25:4 27:2451 31:2018 32:99 35:37 36:877 37:3065 38:1770 39:289 40:120 41:3202 42:826 43:2096 44:151 45:8681 46:3343 47:261 49:1354 50:1109 51:337 52:1010 54:279 55:698 56:6 57:46 58:1768 59:1091 60:537 61:2198 62:1956 63:1856 64:4984 65:2210 66:4842 67:2775 68:1174 69:3553 70:1389 71:658 72:2633 74:2711 75:1295 76:569 77:1803 78:1836 79:2273 80:1851 81:1493 82:1132 83:944 84:1131 85:2299 86:557 87:1544 88:1051 89:2557 90:208 91:6601 92:1434 93:2473 94:2475 95:3320 96:945 97:339 98:961 99:789 100:87 101:1195 102:640 103:21667 104:3636 105:266 106:786 107:1758 108:697 109:3778 110:1728 111:2019 112:1526 113:1386 114:1240 115:1735 116:1760 117:1925 118:2175 119:1652 120:1056 121:1054 122:2248 123:1795 124:1497 125:2020 128:1358 129:840 130:550 131:1824 132:770 133:222 134:1097 135:250 136:598 137:780 138:2061 139:904 140:606 141:895 142:793 143:1056 144:883 145:275 146:1299 147:842 148:1719 149:984 150:788 151:1016 152:1091 153:337 154:4274 155:908 156:1649 157:1027 158:663 159:1949 160:1608 161:931 162:2958 163:829 164:1269 165:1496 166:478 167:1415 168:3441 169:897 170:4195 171:611 172:1663 173:2209 174:1040 175:990 176:2373 177:4013 178:2559 179:1375 180:2153 181:2354 182:2727 183:1103 184:2277 185:15360 186:3656 187:2479 188:2942 189:1989 190:8228 191:1453 192:10063 193:6747 194:5503 195:4150 196:2968 197:1614 198:5938 199:5977 200:7103 201:5109 202:10412 203:10193 204:4550 205:3073 206:3262 207:3239 208:3938 209:4271 210:3934 211:2045 212:3122 213:2975 214:1117 215:54 216:5895 217:2235 218:895 219:608 220:1907 221:976 222:979 223:1414 End of report From sandy at tislabs.com Fri Jul 5 18:46:23 2019 From: sandy at tislabs.com (Sandra Murphy) Date: Fri, 5 Jul 2019 14:46:23 -0400 Subject: CloudFlare issues? In-Reply-To: <56f186b1-7899-f685-ae5b-6aec84a02e34@i3d.net> References: <05BB24C5-9322-414B-B3DC-58BB6C895E80@gmail.com> <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> <40120735-b4f7-2e4f-6aca-d0920c461ed6@seacom.mu> <56f186b1-7899-f685-ae5b-6aec84a02e34@i3d.net> Message-ID: Martijn - i3D.net is not in the list Job posted yesterday of RPKI ROV deployment. Your message below hints that you may be using RPKI. Are you doing ROV? (You may be in the “hundreds of others” category.) —Sandy Begin forwarded message: From: Job Snijders Subject: Re: CloudFlare issues? Date: July 4, 2019 at 11:33:57 AM EDT To: Francois Lecavalier Cc: "nanog at nanog.org" I believe at this point in time it is safe to accept valid and unknown (combined with an IRR filter), and reject RPKI invalid BGP announcements at your EBGP borders. Large examples of other organisations who already are rejecting invalid announcements are AT&T, Nordunet, DE-CIX, YYCIX, XS4ALL, MSK-IX, INEX, France-IX, Seacomm, Workonline, KPN International, and hundreds of others. > On Jul 4, 2019, at 5:56 AM, i3D.net - Martijn Schmidt via NANOG wrote: > > So that means it's time for everyone to migrate their ARIN resources to a sane RIR that does allow normal access to and redistribution of its RPKI TAL? ;-) > > The RPKI TAL problem + an industry-standard IRRDB instead of WHOIS-RWS were both major reasons for us to bring our ARIN IPv4 address space to RIPE. Unfortunately we had to renumber our handful of IPv6 customers because ARIN doesn't do IPv6 inter-RIR transfers, but hey, no pain no gain. > > Therefore, Cloudflare folks - when are you transferring your resources away from ARIN? :D > > Best regards, > Martijn > > On 7/4/19 11:46 AM, Mark Tinka wrote: >> I finally thought about this after I got off my beer high :-). >> >> Some of our customers complained about losing access to Cloudflare's resources during the Verizon debacle. Since we are doing ROV and dropping Invalids, this should not have happened, given most of Cloudflare's IPv4 and IPv6 routes are ROA'd. >> >> However, since we are not using the ARIN TAL (for known reasons), this explains why this also broke for us. >> >> Back to beer now :-)... >> >> Mark. > From sfrost at snowman.net Fri Jul 5 19:10:13 2019 From: sfrost at snowman.net (Stephen Frost) Date: Fri, 5 Jul 2019 15:10:13 -0400 Subject: CenturyLink/Level3 feedback In-Reply-To: <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> Message-ID: <20190705191013.GU29202@tamriel.snowman.net> Greetings, I have to admit that I was hoping to be able to report to this list that CL was able to spin up a new 1G in fairly short order (after all, this is what they assured me of when discussing it with them...) but it's now been over a month, with them telling me it'll be another couple weeks because they need to send a tech out (the wiring and all of the equipment has been ready to go, though that also took longer than it should have imv...). And this in an already lit building in northern Virginia, not some back of the woods location, small town, or something going across an ocean. Pretty disappointing. Thanks, * Mike Hammett (nanog at ics-il.net) wrote: > Anything more than a week for things not requiring last mile construction is ridiculous. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > ----- Original Message ----- > > From: "JASON BOTHE via NANOG" > To: "Mehmet Akcin" > Cc: "nanog" > Sent: Wednesday, June 5, 2019 9:56:14 AM > Subject: Re: CenturyLink/Level3 feedback > > It’s taking over a year to get waves turned up in EU. I’m currently willing to wager on what comes up first, them or amazon peering (that’s taking just as long). After the merger, we have seen Level3 slide into the CL abyss becoming a pain to deal with. Pricing and ordering has been outsourced we’ve been told and decisions are no longer at a regional level. Frustrating at best. > > > On Jun 4, 2019, at 09:30, Mehmet Akcin wrote: > > > > hi there, > > > > Just a general high-level question about Centurylink/Level3 post-merger, how is your overall experience with CenturyLink? if you could be sitting with the CEO of the company what is one thing you would ask him to fix? > > > > please keep it high level and general. i intend to pass these to him and his team in an upcoming meeting. > > > > Mehmet > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mikebolitho at gmail.com Fri Jul 5 19:12:42 2019 From: mikebolitho at gmail.com (Mike Bolitho) Date: Fri, 5 Jul 2019 12:12:42 -0700 Subject: CenturyLink/Level3 feedback In-Reply-To: <20190705191013.GU29202@tamriel.snowman.net> References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> <20190705191013.GU29202@tamriel.snowman.net> Message-ID: Just out of curiosity, what network are they bringing you up on? - Mike Bolitho On Fri, Jul 5, 2019 at 12:11 PM Stephen Frost wrote: > Greetings, > > I have to admit that I was hoping to be able to report to this list that > CL was able to spin up a new 1G in fairly short order (after all, this > is what they assured me of when discussing it with them...) but it's now > been over a month, with them telling me it'll be another couple weeks > because they need to send a tech out (the wiring and all of the > equipment has been ready to go, though that also took longer than it > should have imv...). > > And this in an already lit building in northern Virginia, not some back > of the woods location, small town, or something going across an ocean. > > Pretty disappointing. > > Thanks, > > * Mike Hammett (nanog at ics-il.net) wrote: > > Anything more than a week for things not requiring last mile > construction is ridiculous. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > > ----- Original Message ----- > > > > From: "JASON BOTHE via NANOG" > > To: "Mehmet Akcin" > > Cc: "nanog" > > Sent: Wednesday, June 5, 2019 9:56:14 AM > > Subject: Re: CenturyLink/Level3 feedback > > > > It’s taking over a year to get waves turned up in EU. I’m currently > willing to wager on what comes up first, them or amazon peering (that’s > taking just as long). After the merger, we have seen Level3 slide into the > CL abyss becoming a pain to deal with. Pricing and ordering has been > outsourced we’ve been told and decisions are no longer at a regional level. > Frustrating at best. > > > > > On Jun 4, 2019, at 09:30, Mehmet Akcin wrote: > > > > > > hi there, > > > > > > Just a general high-level question about Centurylink/Level3 > post-merger, how is your overall experience with CenturyLink? if you could > be sitting with the CEO of the company what is one thing you would ask him > to fix? > > > > > > please keep it high level and general. i intend to pass these to him > and his team in an upcoming meeting. > > > > > > Mehmet > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfrost at snowman.net Fri Jul 5 19:25:18 2019 From: sfrost at snowman.net (Stephen Frost) Date: Fri, 5 Jul 2019 15:25:18 -0400 Subject: CenturyLink/Level3 feedback In-Reply-To: References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> <20190705191013.GU29202@tamriel.snowman.net> Message-ID: <20190705192518.GW29202@tamriel.snowman.net> Greetings, This looks to be former Qwest, from what I've been able to tell. IPs we were assigned were out of AS209. Thanks, Stephen * Mike Bolitho (mikebolitho at gmail.com) wrote: > Just out of curiosity, what network are they bringing you up on? > > - Mike Bolitho > > > On Fri, Jul 5, 2019 at 12:11 PM Stephen Frost wrote: > > > Greetings, > > > > I have to admit that I was hoping to be able to report to this list that > > CL was able to spin up a new 1G in fairly short order (after all, this > > is what they assured me of when discussing it with them...) but it's now > > been over a month, with them telling me it'll be another couple weeks > > because they need to send a tech out (the wiring and all of the > > equipment has been ready to go, though that also took longer than it > > should have imv...). > > > > And this in an already lit building in northern Virginia, not some back > > of the woods location, small town, or something going across an ocean. > > > > Pretty disappointing. > > > > Thanks, > > > > * Mike Hammett (nanog at ics-il.net) wrote: > > > Anything more than a week for things not requiring last mile > > construction is ridiculous. > > > > > > > > > > > > > > > ----- > > > Mike Hammett > > > Intelligent Computing Solutions > > > > > > Midwest Internet Exchange > > > > > > The Brothers WISP > > > > > > ----- Original Message ----- > > > > > > From: "JASON BOTHE via NANOG" > > > To: "Mehmet Akcin" > > > Cc: "nanog" > > > Sent: Wednesday, June 5, 2019 9:56:14 AM > > > Subject: Re: CenturyLink/Level3 feedback > > > > > > It’s taking over a year to get waves turned up in EU. I’m currently > > willing to wager on what comes up first, them or amazon peering (that’s > > taking just as long). After the merger, we have seen Level3 slide into the > > CL abyss becoming a pain to deal with. Pricing and ordering has been > > outsourced we’ve been told and decisions are no longer at a regional level. > > Frustrating at best. > > > > > > > On Jun 4, 2019, at 09:30, Mehmet Akcin wrote: > > > > > > > > hi there, > > > > > > > > Just a general high-level question about Centurylink/Level3 > > post-merger, how is your overall experience with CenturyLink? if you could > > be sitting with the CEO of the company what is one thing you would ask him > > to fix? > > > > > > > > please keep it high level and general. i intend to pass these to him > > and his team in an upcoming meeting. > > > > > > > > Mehmet > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From clayton at MNSi.Net Fri Jul 5 19:34:00 2019 From: clayton at MNSi.Net (Clayton Zekelman) Date: Fri, 05 Jul 2019 15:34:00 -0400 Subject: CenturyLink/Level3 feedback In-Reply-To: <20190705191013.GU29202@tamriel.snowman.net> References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> <20190705191013.GU29202@tamriel.snowman.net> Message-ID: <1562355244_29426@surgemail.mnsi.net> We tried to order a 100G circuit from them terminating in an existing Level3 FPP at a location that we've had at least two 1G circuits and a 10G circuit terminated at. They refused to process the order because they needed to "extend the demarc " to our suite. There is no suite. It's a FPP in the basement of the building. Our FPP is next to it. We've done this before... They said that the equipment (the FPP) may not be 100G compatible, and they may need to install a new one that can support 100G. We told them to just forget it and we'd order from Zayo... ... At 03:10 PM 05/07/2019, Stephen Frost wrote: >Greetings, > >I have to admit that I was hoping to be able to report to this list that >CL was able to spin up a new 1G in fairly short order (after all, this >is what they assured me of when discussing it with them...) but it's now >been over a month, with them telling me it'll be another couple weeks >because they need to send a tech out (the wiring and all of the >equipment has been ready to go, though that also took longer than it >should have imv...). > >And this in an already lit building in northern Virginia, not some back >of the woods location, small town, or something going across an ocean. > >Pretty disappointing. > >Thanks, > >* Mike Hammett (nanog at ics-il.net) wrote: > > Anything more than a week for things not > requiring last mile construction is ridiculous. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > > ----- Original Message ----- > > > > From: "JASON BOTHE via NANOG" > > To: "Mehmet Akcin" > > Cc: "nanog" > > Sent: Wednesday, June 5, 2019 9:56:14 AM > > Subject: Re: CenturyLink/Level3 feedback > > > > It’s taking over a year to get waves turned > up in EU. I’m currently willing to wager on > what comes up first, them or amazon peering > (that’s taking just as long). After the > merger, we have seen Level3 slide into the CL > abyss becoming a pain to deal with. Pricing and > ordering has been outsourced we’ve been told > and decisions are no longer at a regional level. Frustrating at best. > > > > > On Jun 4, 2019, at 09:30, Mehmet Akcin wrote: > > > > > > hi there, > > > > > > Just a general high-level question about > Centurylink/Level3 post-merger, how is your > overall experience with CenturyLink? if you > could be sitting with the CEO of the company > what is one thing you would ask him to fix? > > > > > > please keep it high level and general. i > intend to pass these to him and his team in an upcoming meeting. > > > > > > Mehmet > > > > > -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From jared at puck.nether.net Fri Jul 5 19:38:12 2019 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 5 Jul 2019 15:38:12 -0400 Subject: CenturyLink/Level3 feedback In-Reply-To: <20190705191013.GU29202@tamriel.snowman.net> References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> <20190705191013.GU29202@tamriel.snowman.net> Message-ID: > On Jul 5, 2019, at 3:10 PM, Stephen Frost wrote: > > Greetings, > > I have to admit that I was hoping to be able to report to this list that > CL was able to spin up a new 1G in fairly short order (after all, this > is what they assured me of when discussing it with them...) but it's now > been over a month, with them telling me it'll be another couple weeks > because they need to send a tech out (the wiring and all of the > equipment has been ready to go, though that also took longer than it > should have imv...). > > And this in an already lit building in northern Virginia, not some back > of the woods location, small town, or something going across an ocean. Sometimes you’d be surprised, it may not be straightforward on their end. Remember, most people here are likely experts at some part or many parts, what we do is likely wizardry to others. I have a saying you’re welcome to steal if you don’t steal it too much: “We are moving at the speed the organization is capable”. I suspect that’s the case for them in a post-acquisition world trying to sort through all the integration work. - Jared From martijnschmidt at i3d.net Fri Jul 5 21:14:12 2019 From: martijnschmidt at i3d.net (i3D.net - Martijn Schmidt) Date: Fri, 5 Jul 2019 21:14:12 +0000 Subject: CloudFlare issues? In-Reply-To: References: <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> <40120735-b4f7-2e4f-6aca-d0920c461ed6@seacom.mu> <56f186b1-7899-f685-ae5b-6aec84a02e34@i3d.net> Message-ID: Hey Sandy, At this time i3D.net is not able to fully implement RPKI for technical reasons: there are still some Brocade routers in our network which don't support it. We are making very good progress migrating the entire network over to Juniper routers which do support RPKI, and we will certainly deploy ROV when that is done, but with upwards of 40 default-free backbone routers spread over six continents it's not a logistically trivial task. That being said, a network doesn't need to use ROV to benefit from the routing security afforded by the RPKI protocol. Nearly all of the prefixes originated by AS49544 have been covered by RPKI ROAs for several years now. Those networks which have already deployed ROV are inoculated against route hijacks of i3D.net's IP space in scenarios where the bad paths would be marked as RPKI invalid. Considering that i3D.net was founded in The Netherlands and that a significant amount of our enterprise customers have businesses which are focused on the Dutch market, the fact that two of the major eyeball networks in the country (that'd be KPN & XS4ALL) are using ROV is already a huge win for everyone involved. And, let's not forget that the degree of protection afforded by this relatively passive participation in RPKI is directly proportional to the use of a non-ARIN TAL. Real-world example: Mark Tinka's remark concerning Seacom's connection to Cloudflare's IP space being affected by the hijack due to the ARIN TAL problem, despite both involved parties fully deploying RPKI by both signing ROAs and implementing ROV. Best regards, Martijn On 7/5/19 8:46 PM, Sandra Murphy wrote: > Martijn - i3D.net is not in the list Job posted yesterday of RPKI ROV deployment. Your message below hints that you may be using RPKI. Are you doing ROV? (You may be in the “hundreds of others” category.) > > —Sandy > > Begin forwarded message: > > From: Job Snijders > Subject: Re: CloudFlare issues? > Date: July 4, 2019 at 11:33:57 AM EDT > To: Francois Lecavalier > Cc: "nanog at nanog.org" > > I believe at this point in time it is safe to accept valid and unknown > (combined with an IRR filter), and reject RPKI invalid BGP announcements > at your EBGP borders. Large examples of other organisations who already > are rejecting invalid announcements are AT&T, Nordunet, DE-CIX, YYCIX, > XS4ALL, MSK-IX, INEX, France-IX, Seacomm, Workonline, KPN International, > and hundreds of others. > > > >> On Jul 4, 2019, at 5:56 AM, i3D.net - Martijn Schmidt via NANOG wrote: >> >> So that means it's time for everyone to migrate their ARIN resources to a sane RIR that does allow normal access to and redistribution of its RPKI TAL? ;-) >> >> The RPKI TAL problem + an industry-standard IRRDB instead of WHOIS-RWS were both major reasons for us to bring our ARIN IPv4 address space to RIPE. Unfortunately we had to renumber our handful of IPv6 customers because ARIN doesn't do IPv6 inter-RIR transfers, but hey, no pain no gain. >> >> Therefore, Cloudflare folks - when are you transferring your resources away from ARIN? :D >> >> Best regards, >> Martijn >> >> On 7/4/19 11:46 AM, Mark Tinka wrote: >>> I finally thought about this after I got off my beer high :-). >>> >>> Some of our customers complained about losing access to Cloudflare's resources during the Verizon debacle. Since we are doing ROV and dropping Invalids, this should not have happened, given most of Cloudflare's IPv4 and IPv6 routes are ROA'd. >>> >>> However, since we are not using the ARIN TAL (for known reasons), this explains why this also broke for us. >>> >>> Back to beer now :-)... >>> >>> Mark. From michael at wi-fiber.io Sat Jul 6 00:30:11 2019 From: michael at wi-fiber.io (Michael Crapse) Date: Fri, 5 Jul 2019 18:30:11 -0600 Subject: Uhaul not routing IPs Message-ID: Our customers are trying to access uhauldealer.com and are unable to load the page. Classic case of incorrect geolocation and/or up filtering. Our emails to their webmaster/wan team have gone unanswered or bounced If anyone knows how to contact them please contact me off list -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at wi-fiber.io Sat Jul 6 00:59:26 2019 From: michael at wi-fiber.io (Michael Crapse) Date: Fri, 5 Jul 2019 18:59:26 -0600 Subject: Uhaul not routing IPs In-Reply-To: <597b8969-6a27-450a-af78-691ff00444d2@neilhanlon.com> References: <597b8969-6a27-450a-af78-691ff00444d2@neilhanlon.com> Message-ID: The server does not respond to our clients when they originate from a certain subnet, but they do with a different subnet On Fri, Jul 5, 2019, 6:57 PM Neil Hanlon wrote: > Hi Michael, > > Wondering if you might be able to clarify a few points... I'm not from > uhaul but am a casual observer and have a couple questions. What does "not > routing ips" mean? Where is traffic stopping? > > Can you clarify "unable to load the page"? Have any example traceroutes? > Error messages? > > I'm also a a bit unsure what geolocolation or routing has to do with this > at all. Your message seems to go back and forth between being application > level and network level, so I think clearing up exactly the symptoms of > your issues would be helpful. > > -Neil > On Jul 5, 2019, at 20:32, Michael Crapse wrote: >> >> Our customers are trying to access uhauldealer.com and are unable to >> load the page. Classic case of incorrect geolocation and/or up filtering. >> Our emails to their webmaster/wan team have gone unanswered or bounced >> If anyone knows how to contact them please contact me off list >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at wi-fiber.io Sat Jul 6 01:07:28 2019 From: michael at wi-fiber.io (Michael Crapse) Date: Fri, 5 Jul 2019 19:07:28 -0600 Subject: Uhaul not routing IPs In-Reply-To: <6985ece3-5766-47db-a3ce-211715e21560@shrug.pw> References: <6985ece3-5766-47db-a3ce-211715e21560@shrug.pw> Message-ID: Forgot to attach our main subnet, 196.53.96.0/22 On Fri, Jul 5, 2019, 6:59 PM Neil Hanlon wrote: > Hi Michael, > > > Wondering if you might be able to clarify a few points... I'm not from > uhaul but am a casual observer and have a couple questions. What does "not > routing ips" mean? Where is traffic stopping? > > > Can you clarify "unable to load the page"? Have any example traceroutes? > Error messages? > > > I'm also a a bit unsure what geolocolation or routing has to do with this > at all. Your message seems to go back and forth between being application > level and network level, so I think clearing up exactly the symptoms of > your issues would be helpful. > > > -Neil > > > > > On Jul 5, 2019, at 20:32, Michael Crapse wrote: >> >> Our customers are trying to access uhauldealer.com and are unable to >> load the page. Classic case of incorrect geolocation and/or up filtering. >> Our emails to their webmaster/wan team have gone unanswered or bounced >> If anyone knows how to contact them please contact me off list >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at wi-fiber.io Sat Jul 6 01:57:00 2019 From: michael at wi-fiber.io (Michael Crapse) Date: Fri, 5 Jul 2019 19:57:00 -0600 Subject: Uhaul not routing IPs In-Reply-To: <694b4496-32b3-4cf5-b205-3e2f45a6c9d1@shrug.pw> References: <597b8969-6a27-450a-af78-691ff00444d2@neilhanlon.com> <694b4496-32b3-4cf5-b205-3e2f45a6c9d1@shrug.pw> Message-ID: I do not know what this issue is, I am not uhaul. The server does not respond to pings/requests. It one way routes to their subnet via traceroute and just drops off after that. 95% of the time it is a firewall setting, the other 5% of the time it is a bgp issue on their edge routers, not being able to reply to our packets being sent(one way routing issue). We have a list of other little services that have the same problem, but because they are little, we can CGNAT all requests to their IP addresses from known good addresses. I've just got to assume that there is some common service that they all use that cause this problem. Assuming they accept BGP with proper filters and have a semi-sane firewall, there wouldn't be any issues as we don't do anything special with our BGP. On Fri, 5 Jul 2019 at 19:06, Neil Hanlon wrote: > Phone sent from the wrong email address and the list rejected it... Oops. > Sorry for the spam. > > Server does not respond on.... Port 80? Or are you not able to route there > at all. > > Seems like you need to get in touch with their team, but still a bit vague > as to exactly what issue you're having.... Eg, is it a firewall blocking > you or is there a route missing somewhere (this seems unlikely). > > Hopefully there's someone on list that can help.. Otherwise I think > wan at uhaul is your best option. > On Jul 5, 2019, at 20:59, Michael Crapse wrote: >> >> The server does not respond to our clients when they originate from a >> certain subnet, but they do with a different subnet >> >> On Fri, Jul 5, 2019, 6:57 PM Neil Hanlon < neil at neilhanlon.com> wrote: >> >>> Hi Michael, >>> >>> Wondering if you might be able to clarify a few points... I'm not from >>> uhaul but am a casual observer and have a couple questions. What does "not >>> routing ips" mean? Where is traffic stopping? >>> >>> Can you clarify "unable to load the page"? Have any example traceroutes? >>> Error messages? >>> >>> I'm also a a bit unsure what geolocolation or routing has to do with >>> this at all. Your message seems to go back and forth between being >>> application level and network level, so I think clearing up exactly the >>> symptoms of your issues would be helpful. >>> >>> -Neil >>> On Jul 5, 2019, at 20:32, Michael Crapse < michael at wi-fiber.io> wrote: >>>> >>>> Our customers are trying to access uhauldealer.com and are unable to >>>> load the page. Classic case of incorrect geolocation and/or up filtering. >>>> Our emails to their webmaster/wan team have gone unanswered or bounced >>>> If anyone knows how to contact them please contact me off list >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbf+nanog at panix.com Sat Jul 6 20:05:23 2019 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sat, 6 Jul 2019 15:05:23 -0500 Subject: CloudFlare issues? In-Reply-To: <40120735-b4f7-2e4f-6aca-d0920c461ed6@seacom.mu> References: <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> <40120735-b4f7-2e4f-6aca-d0920c461ed6@seacom.mu> Message-ID: <20190706200523.GA25692@panix.com> On Thu, Jul 04, 2019 at 11:46:05AM +0200, Mark Tinka wrote: > I finally thought about this after I got off my beer high :-). > > Some of our customers complained about losing access to Cloudflare's > resources during the Verizon debacle. Since we are doing ROV and > dropping Invalids, this should not have happened, given most of > Cloudflare's IPv4 and IPv6 routes are ROA'd. These were more-specifics, though. So if you drop all the more-specifics as failing ROV, then you end up following the valid shorter prefix to the destination. Quite possibly that points at the upstream which sent you the more-specific which you rejected, at which point your packets end up same going to the same place they would have gone if you had accepted the invalid more-specific. Two potential issues here: First, if you don't have an upstream who is also rejecting the invalid routes, then anywhere you send the packets, they're going to follow the more-specific. Second, even if you do have an upstream that is rejecting the invalid routes, ROV won't cause you to prefer the less-specific from an upstream that is rejecting the invalid routes over a less-specific from an upstream that is accepting the invalid routes. For example: if upstream A sends you: 10.0.0.0./16 valid and upstream B sends you 10.0.0.0/16 valid 10.0.0.0/17 invalid 10.0.128.0/17 invalid you want send to send the packet to A. But ROV won't cause that, and if upstream B is selected by your BGP decision criteria (path length, etc.), you're packets will ultimately follow the more-specific. (Of course, the problem is can occur more than one network away. Even if you do send to upstream A, there's no guarantee that A's less-specifics aren't pointed at another network that does have the more-specifics. But at least you give them a fighting chance by sending them to A.) -- Brett From mehmet at akcin.net Sat Jul 6 21:18:02 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 6 Jul 2019 16:18:02 -0500 Subject: Puerto Rico Internet Exchange Message-ID: Hey there, just a very brief update We are in the process of RE-launching Internet Exchange in San Juan, Puerto Rico in a few weeks. We've got multiple networks in San Juan agreed to join the IX in a common neutral point. If you are able to help with the project or interested in learning more about it, please contact me offlist. (especially if you are in Puerto rico) Once everything is operational and the website is set up, I hope to contact back and update once we've got mrtg, etc is operational. thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at as397444.net Sat Jul 6 21:44:36 2019 From: nanog at as397444.net (Matt Corallo) Date: Sat, 6 Jul 2019 17:44:36 -0400 Subject: CloudFlare issues? In-Reply-To: <20190706200523.GA25692@panix.com> References: <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> <40120735-b4f7-2e4f-6aca-d0920c461ed6@seacom.mu> <20190706200523.GA25692@panix.com> Message-ID: On my test net I take ROA_INVALIDs and convert them to unreachables with a low preference (ie so that any upstreams taking only the shorter path will be selected, but so that such packets will never be routed). Obviously this isn't a well-supported operation, but I'm curious what people think of such an approach? If you really want to treat ROA_INVALID as "this is probably a hijack", you don't really want to be sending the hijacker traffic. Of course if upstreams are rejecting ROA_INVALID you can still have the same problem one network away, but its an interesting result for testing, especially since it rejects a bunch of crap in China where CT has reassigned prefixes with covering ROAs to customers who re-announce on their own ASN (which appears to be common). Matt On 7/6/19 4:05 PM, Brett Frankenberger wrote: > On Thu, Jul 04, 2019 at 11:46:05AM +0200, Mark Tinka wrote: >> I finally thought about this after I got off my beer high :-). >> >> Some of our customers complained about losing access to Cloudflare's >> resources during the Verizon debacle. Since we are doing ROV and >> dropping Invalids, this should not have happened, given most of >> Cloudflare's IPv4 and IPv6 routes are ROA'd. > > These were more-specifics, though. So if you drop all the > more-specifics as failing ROV, then you end up following the valid > shorter prefix to the destination. Quite possibly that points at the > upstream which sent you the more-specific which you rejected, at which > point your packets end up same going to the same place they would have > gone if you had accepted the invalid more-specific. > > Two potential issues here: First, if you don't have an upstream who > is also rejecting the invalid routes, then anywhere you send the > packets, they're going to follow the more-specific. Second, even if > you do have an upstream that is rejecting the invalid routes, ROV won't > cause you to prefer the less-specific from an upstream that is > rejecting the invalid routes over a less-specific from an upstream that > is accepting the invalid routes. > > For example: > if upstream A sends you: > 10.0.0.0./16 valid > and upstream B sends you > 10.0.0.0/16 valid > 10.0.0.0/17 invalid > 10.0.128.0/17 invalid > you want send to send the packet to A. But ROV won't cause that, and if > upstream B is selected by your BGP decision criteria (path length, > etc.), you're packets will ultimately follow the more-specific. > > (Of course, the problem is can occur more than one network away. Even > if you do send to upstream A, there's no guarantee that A's > less-specifics aren't pointed at another network that does have the > more-specifics. But at least you give them a fighting chance by > sending them to A.) > > -- Brett > From nanog at as397444.net Sat Jul 6 21:49:10 2019 From: nanog at as397444.net (Matt Corallo) Date: Sat, 6 Jul 2019 17:49:10 -0400 Subject: CloudFlare issues? In-Reply-To: References: <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> <40120735-b4f7-2e4f-6aca-d0920c461ed6@seacom.mu> <20190706200523.GA25692@panix.com> Message-ID: <30facacd-4ef8-c962-5f10-4e234ce1126b@bluematt.me> Oops, I mean with a script which removes such routes if there is an encompassing route which a different upstream takes, as obviously the more-specific would otherwise still win. Matt On 7/6/19 5:44 PM, Matt Corallo wrote: > On my test net I take ROA_INVALIDs and convert them to unreachables with > a low preference (ie so that any upstreams taking only the shorter path > will be selected, but so that such packets will never be routed). > > Obviously this isn't a well-supported operation, but I'm curious what > people think of such an approach? If you really want to treat > ROA_INVALID as "this is probably a hijack", you don't really want to be > sending the hijacker traffic. > > Of course if upstreams are rejecting ROA_INVALID you can still have the > same problem one network away, but its an interesting result for > testing, especially since it rejects a bunch of crap in China where CT > has reassigned prefixes with covering ROAs to customers who re-announce > on their own ASN (which appears to be common). > > Matt > > On 7/6/19 4:05 PM, Brett Frankenberger wrote: >> On Thu, Jul 04, 2019 at 11:46:05AM +0200, Mark Tinka wrote: >>> I finally thought about this after I got off my beer high :-). >>> >>> Some of our customers complained about losing access to Cloudflare's >>> resources during the Verizon debacle. Since we are doing ROV and >>> dropping Invalids, this should not have happened, given most of >>> Cloudflare's IPv4 and IPv6 routes are ROA'd. >> >> These were more-specifics, though. So if you drop all the >> more-specifics as failing ROV, then you end up following the valid >> shorter prefix to the destination. Quite possibly that points at the >> upstream which sent you the more-specific which you rejected, at which >> point your packets end up same going to the same place they would have >> gone if you had accepted the invalid more-specific. >> >> Two potential issues here: First, if you don't have an upstream who >> is also rejecting the invalid routes, then anywhere you send the >> packets, they're going to follow the more-specific. Second, even if >> you do have an upstream that is rejecting the invalid routes, ROV won't >> cause you to prefer the less-specific from an upstream that is >> rejecting the invalid routes over a less-specific from an upstream that >> is accepting the invalid routes. >> >> For example: >> if upstream A sends you: >> 10.0.0.0./16 valid >> and upstream B sends you >> 10.0.0.0/16 valid >> 10.0.0.0/17 invalid >> 10.0.128.0/17 invalid >> you want send to send the packet to A. But ROV won't cause that, and if >> upstream B is selected by your BGP decision criteria (path length, >> etc.), you're packets will ultimately follow the more-specific. >> >> (Of course, the problem is can occur more than one network away. Even >> if you do send to upstream A, there's no guarantee that A's >> less-specifics aren't pointed at another network that does have the >> more-specifics. But at least you give them a fighting chance by >> sending them to A.) >> >> -- Brett >> From rubensk at gmail.com Sat Jul 6 22:00:34 2019 From: rubensk at gmail.com (Rubens Kuhl) Date: Sat, 6 Jul 2019 19:00:34 -0300 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: It would be interesting if ICANN, Verisign and Afilias were able to join the IX as well making the root and .com/.net/.org/.pr zones available even if the island is cut off from the globe. There is so much fixation in bits per second while IX'es are resiliency tools, more than bandwidth saving tools. Rubens On Sat, Jul 6, 2019 at 6:19 PM Mehmet Akcin wrote: > Hey there, just a very brief update > > We are in the process of RE-launching Internet Exchange in San Juan, > Puerto Rico in a few weeks. We've got multiple networks in San Juan agreed > to join the IX in a common neutral point. If you are able to help with the > project or interested in learning more about it, please contact me offlist. > (especially if you are in Puerto rico) > > Once everything is operational and the website is set up, I hope to > contact back and update once we've got mrtg, etc is operational. > > thank you > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramirezcyrus at yahoo.com Sat Jul 6 22:03:34 2019 From: ramirezcyrus at yahoo.com (cyrus ramirez) Date: Sat, 6 Jul 2019 22:03:34 +0000 (UTC) Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: <1521330364.3763598.1562450614705@mail.yahoo.com> I'm interested as well. Cyrus Ramirez Sent from Yahoo Mail on Android On Sat, Jul 6, 2019 at 6:01 PM, Rubens Kuhl wrote: It would be interesting if ICANN, Verisign and Afilias were able to join the IX as well making the root and .com/.net/.org/.pr zones available even if the island is cut off from the globe. There is so much fixation in bits per second while IX'es are resiliency tools, more than bandwidth saving tools.  Rubens On Sat, Jul 6, 2019 at 6:19 PM Mehmet Akcin wrote: Hey there, just a very brief update We are in the process of RE-launching Internet Exchange in San Juan, Puerto Rico in a few weeks. We've got multiple networks in San Juan agreed to join the IX in a common neutral point.  If you are able to help with the project or interested in learning more about it, please contact me offlist. (especially if you are in Puerto rico) Once everything is operational and the website is set up, I hope to contact back and update once we've got mrtg, etc is operational. thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Sat Jul 6 23:14:34 2019 From: woody at pch.net (Bill Woodcock) Date: Sat, 6 Jul 2019 18:14:34 -0500 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: .Org, .pr, and a couple of root letters should be on our Puerto Rico node already, along with several hundred other TLDs. -Bill > On Jul 6, 2019, at 17:00, Rubens Kuhl wrote: > > > It would be interesting if ICANN, Verisign and Afilias were able to join the IX as well making the root and .com/.net/.org/.pr zones available even if the island is cut off from the globe. There is so much fixation in bits per second while IX'es are resiliency tools, more than bandwidth saving tools. > > > Rubens > > >> On Sat, Jul 6, 2019 at 6:19 PM Mehmet Akcin wrote: >> Hey there, just a very brief update >> >> We are in the process of RE-launching Internet Exchange in San Juan, Puerto Rico in a few weeks. We've got multiple networks in San Juan agreed to join the IX in a common neutral point. If you are able to help with the project or interested in learning more about it, please contact me offlist. (especially if you are in Puerto rico) >> >> Once everything is operational and the website is set up, I hope to contact back and update once we've got mrtg, etc is operational. >> >> thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From JHathaway at howardcenter.org Sun Jul 7 01:10:20 2019 From: JHathaway at howardcenter.org (Jeffrey Hathaway) Date: Sun, 7 Jul 2019 01:10:20 +0000 Subject: CenturyLink/Level3 feedback In-Reply-To: References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> <20190705191013.GU29202@tamriel.snowman.net> Message-ID: Greetings, My personal experience, take it for what it is worth. Level 3 was extremely slow to turn up a circuit well before the merger and seems slower post the merger. I have just never seen level 3 turn up anything fast, even in a data center they already were serving other customers in. Sincerely, Jeffrey Hathaway Information Technology • Howard Center Inc. -----Original Message----- From: NANOG On Behalf Of Jared Mauch Sent: Friday, July 5, 2019 3:38 PM To: Stephen Frost Cc: nanog Subject: Re: CenturyLink/Level3 feedback ________________________________ CAUTION: This email originated from outside Howard Center. Please use caution opening attachments or clicking on web links with this email. ________________________________ > On Jul 5, 2019, at 3:10 PM, Stephen Frost wrote: > > Greetings, > > I have to admit that I was hoping to be able to report to this list > that CL was able to spin up a new 1G in fairly short order (after all, > this is what they assured me of when discussing it with them...) but > it's now been over a month, with them telling me it'll be another > couple weeks because they need to send a tech out (the wiring and all > of the equipment has been ready to go, though that also took longer > than it should have imv...). > > And this in an already lit building in northern Virginia, not some > back of the woods location, small town, or something going across an ocean. Sometimes you’d be surprised, it may not be straightforward on their end. Remember, most people here are likely experts at some part or many parts, what we do is likely wizardry to others. I have a saying you’re welcome to steal if you don’t steal it too much: “We are moving at the speed the organization is capable”. I suspect that’s the case for them in a post-acquisition world trying to sort through all the integration work. - Jared ________________________________ HowardCenter.org [http://howardcenter.org/assets/design/Facebook.jpg] [http://howardcenter.org/assets/design/Twitter.jpg] [http://howardcenter.org/assets/design/LinkedIn.jpg] CONFIDENTIALITY NOTICE: This e-mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is patient protected health information, privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. Please notify the sender by reply e-mail and delete the original message immediately, or notify Howard Center, Inc. immediately by forwarded e-mail to our Privacy Officer, DaveK at howardcenter.org. Thank you. From mark.tinka at seacom.mu Sun Jul 7 17:15:11 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 7 Jul 2019 19:15:11 +0200 Subject: CloudFlare issues? In-Reply-To: <20190706200523.GA25692@panix.com> References: <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> <40120735-b4f7-2e4f-6aca-d0920c461ed6@seacom.mu> <20190706200523.GA25692@panix.com> Message-ID: On 6/Jul/19 22:05, Brett Frankenberger wrote: > These were more-specifics, though. So if you drop all the > more-specifics as failing ROV, then you end up following the valid > shorter prefix to the destination. I can't quite recall which Cloudflare prefixes were impacted. If you have a sniff at https://bgp.he.net/AS13335#_prefixes and https://bgp.he.net/AS13335#_prefixes6 you will see that Cloudflare have a larger portion of their IPv6 prefixes ROA'd than the IPv4 ones. If you remember which Cloudflare prefixes were affected by the Verizon debacle, we can have a closer look. > Quite possibly that points at the > upstream which sent you the more-specific which you rejected, at which > point your packets end up same going to the same place they would have > gone if you had accepted the invalid more-specific. But that's my point... we did not have the chance to drop any of the affected Cloudflare prefixes because we do not use the ARIN TAL. That means that we are currently ignoring the RPKI value of Cloudflare's prefixes that are under ARIN. Also, AFAICT, none of our current upstreams are doing ROV. You can see that list here:     https://bgp.he.net/AS37100#_graph4 Mark. From mark.tinka at seacom.mu Sun Jul 7 17:18:15 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 7 Jul 2019 19:18:15 +0200 Subject: CloudFlare issues? In-Reply-To: References: <20190624141122.GC47956@vurt.meerval.net> <389YFhwUbb2N_1cJWv102KL5XhIbfXp-CbYLBAWB68wpqgMigmq7QHrUPAsOq_yNCQ3Yp5szlwkTA175wr8T5jUgYCz2rbZiGH1DXvRV3QQ=@plunin.net> <828b9483-149f-423d-b67e-54d2e888aba1@seacom.mu> <47d6284a-6a83-b207-e461-119e2196507f@meo.ws> <6dcd5d26-53d7-2fa2-bb04-d9d2e8a93938@satchell.net> <40120735-b4f7-2e4f-6aca-d0920c461ed6@seacom.mu> <20190706200523.GA25692@panix.com> Message-ID: <0d515443-42c7-9f14-133d-6ee7827fb163@seacom.mu> On 6/Jul/19 23:44, Matt Corallo wrote: > On my test net I take ROA_INVALIDs and convert them to unreachables with > a low preference (ie so that any upstreams taking only the shorter path > will be selected, but so that such packets will never be routed). > > Obviously this isn't a well-supported operation, but I'm curious what > people think of such an approach? If you really want to treat > ROA_INVALID as "this is probably a hijack", you don't really want to be > sending the hijacker traffic. If a prefixe's RPKI state is Invalid, drop it! Simple. In most cases, it's a mistake due to a mis-configuration and/or a lack of deep understanding of RPKI. In fewer cases, it's an actual hijack. Either way, dropping the Invalid routes keeps the BGP clean and quickly encourages the originating network to get things fixed. As you point out, RPKI state validation is locally-significant, with protection extending to downstream customers only. So for this to really work, it needs critical mass. One, two, three, four or five networks implementing ROV and dropping Invalids does not a secure BGP make. Mark. From mark.tinka at seacom.mu Sun Jul 7 17:19:48 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 7 Jul 2019 19:19:48 +0200 Subject: CenturyLink/Level3 feedback In-Reply-To: References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> <20190705191013.GU29202@tamriel.snowman.net> Message-ID: <3ae63f9a-6fba-a071-be3e-89c17ac355a0@seacom.mu> Prior to the acquisition, we had a reasonable experience with Level(3) orders in Europe. Since the days of CL, it hasn't been great at all! The team is the same as before for our account, so one can only assume it's acquisition pains. Mark. On 7/Jul/19 03:10, Jeffrey Hathaway via NANOG wrote: > Greetings, > > My personal experience, take it for what it is worth. > > Level 3 was extremely slow to turn up a circuit well before the merger and seems slower post the merger. I have just never seen level 3 turn up anything fast, even in a data center they already were serving other customers in. > > > Sincerely, > Jeffrey Hathaway > Information Technology • Howard Center Inc. > > > > -----Original Message----- > From: NANOG On Behalf Of Jared Mauch > Sent: Friday, July 5, 2019 3:38 PM > To: Stephen Frost > Cc: nanog > Subject: Re: CenturyLink/Level3 feedback > > ________________________________ > CAUTION: This email originated from outside Howard Center. Please use caution opening attachments or clicking on web links with this email. > ________________________________ > > > >> On Jul 5, 2019, at 3:10 PM, Stephen Frost wrote: >> >> Greetings, >> >> I have to admit that I was hoping to be able to report to this list >> that CL was able to spin up a new 1G in fairly short order (after all, >> this is what they assured me of when discussing it with them...) but >> it's now been over a month, with them telling me it'll be another >> couple weeks because they need to send a tech out (the wiring and all >> of the equipment has been ready to go, though that also took longer >> than it should have imv...). >> >> And this in an already lit building in northern Virginia, not some >> back of the woods location, small town, or something going across an ocean. > Sometimes you’d be surprised, it may not be straightforward on their end. > > Remember, most people here are likely experts at some part or many parts, what we do is likely wizardry to others. > > I have a saying you’re welcome to steal if you don’t steal it too much: > > “We are moving at the speed the organization is capable”. I suspect that’s the case for them in a post-acquisition world trying to sort through all the integration work. > > - Jared > ________________________________ > > > HowardCenter.org [http://howardcenter.org/assets/design/Facebook.jpg] [http://howardcenter.org/assets/design/Twitter.jpg] [http://howardcenter.org/assets/design/LinkedIn.jpg] > > CONFIDENTIALITY NOTICE: This e-mail is intended only for the use of the individual or entity to which it is addressed and may contain information that is patient protected health information, privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. Please notify the sender by reply e-mail and delete the original message immediately, or notify Howard Center, Inc. immediately by forwarded e-mail to our Privacy Officer, DaveK at howardcenter.org. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Mon Jul 8 00:06:41 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 7 Jul 2019 19:06:41 -0500 Subject: Must have ISP Open Source & tools Message-ID: Hey there We are a growing ISP in Colombia and Latin America. I am interested in hearing from others regarding tools and software they recommend we must have such as LibreNMS, Rancid etc. It’s greenfieldish now ;-) so feel free to recommend A-Z anything! ;-) Hope this thread is useful others too! Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels=nanog at bakker.net Mon Jul 8 00:16:06 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 8 Jul 2019 02:16:06 +0200 Subject: Must have ISP Open Source & tools In-Reply-To: References: Message-ID: <20190708001606.GA2592@jima.tpb.net> * mehmet at akcin.net (Mehmet Akcin) [Mon 08 Jul 2019, 02:07 CEST]: >We are a growing ISP in Colombia and Latin America. I am interested >in hearing from others regarding tools and software they recommend >we must have such as LibreNMS, Rancid etc. You should reach out to Euro-IX if you haven't already, every member IXP has documented what software they use in their switch database -- Niels. From Ryan.Hamel at quadranet.com Mon Jul 8 00:42:06 2019 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Mon, 8 Jul 2019 00:42:06 +0000 Subject: Must have ISP Open Source & tools In-Reply-To: <20190708001606.GA2592@jima.tpb.net> References: <20190708001606.GA2592@jima.tpb.net> Message-ID: My List: Oxidized as a replacement for RANCID Telegraf + InfluxDB = Tons of Grafana Dashboards (Open Source Slack Alternative) Ansible or Python Knowledge with Paramiko or netmiko for network automation. BGP: FRRouting - Mimics Cisco CLI BIRD - Programming style config format. Exabgp - Mostly used for API driven applications, monitoring with heartbeat scripts. (many others) DDoS detection and/or filtering: Fastnetmon - Supports many methods for packet processing. Ddosdetector (IPv4 Only) - Uses netmap for packet processing. Top Talkers + Other Creativeness (like fib compressing, or route optimization): pmacct - sflow/netflow combined with BGP, and a database backend Servers: Sensu or LibreNMS for Nagios type monitoring. Diagnostics: MTR - ...and knowing how to interpret it's output. -Ryan From ramirezcyrus at yahoo.com Mon Jul 8 00:47:27 2019 From: ramirezcyrus at yahoo.com (cyrus ramirez) Date: Mon, 8 Jul 2019 00:47:27 +0000 (UTC) Subject: Must have ISP Open Source & tools In-Reply-To: References: Message-ID: <1519333469.4043585.1562546847732@mail.yahoo.com> I don't know if the areas have been evaluated or not. I would hyperconverge and virtualize as much as possible. I would attempt MPLS with a VRF gateway. Money will probably be an issue so hosting VoIP and Content services may be good. Are you using wireless, cable, satellite as the backhaul? If this is completely Greenfield, then evaluating a location, finding relay sites and etc should be done 1st. Cyrus  Sent from Yahoo Mail on Android On Sun, Jul 7, 2019 at 8:08 PM, Mehmet Akcin wrote: Hey there We are a growing ISP in Colombia and Latin America. I am interested in hearing from others regarding tools and software they recommend we must have such as LibreNMS, Rancid etc. It’s greenfieldish now ;-) so feel free to recommend A-Z anything! ;-) Hope this thread is useful others too! Mehmet-- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Mon Jul 8 03:36:33 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 7 Jul 2019 22:36:33 -0500 Subject: Must have ISP Open Source & tools In-Reply-To: References: <20190708001606.GA2592@jima.tpb.net> Message-ID: Awesome list On Sun, Jul 7, 2019 at 19:42 Ryan Hamel wrote: > My List: > > Oxidized as a replacement for RANCID > Telegraf + InfluxDB = Tons of Grafana Dashboards > (Open Source Slack Alternative) > Ansible or Python Knowledge with Paramiko or netmiko for network > automation. > > BGP: > > FRRouting - Mimics Cisco CLI > BIRD - Programming style config format. > Exabgp - Mostly used for API driven applications, monitoring with > heartbeat scripts. > (many others) > > DDoS detection and/or filtering: > > Fastnetmon - Supports many methods for packet processing. > Ddosdetector (IPv4 Only) - Uses netmap for packet processing. > > Top Talkers + Other Creativeness (like fib compressing, or route > optimization): > > pmacct - sflow/netflow combined with BGP, and a database backend > > Servers: > > Sensu or LibreNMS for Nagios type monitoring. > > Diagnostics: > > MTR - ...and knowing how to interpret it's output. > > -Ryan > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason.w.kuehl at gmail.com Mon Jul 8 13:40:53 2019 From: jason.w.kuehl at gmail.com (Jason Kuehl) Date: Mon, 8 Jul 2019 09:40:53 -0400 Subject: Must have ISP Open Source & tools In-Reply-To: References: <20190708001606.GA2592@jima.tpb.net> Message-ID: We use https://cbackup.me/en/ over Rancid On Sun, Jul 7, 2019 at 11:38 PM Mehmet Akcin wrote: > Awesome list > > On Sun, Jul 7, 2019 at 19:42 Ryan Hamel wrote: > >> My List: >> >> Oxidized as a replacement for RANCID >> Telegraf + InfluxDB = Tons of Grafana Dashboards >> (Open Source Slack Alternative) >> Ansible or Python Knowledge with Paramiko or netmiko for network >> automation. >> >> BGP: >> >> FRRouting - Mimics Cisco CLI >> BIRD - Programming style config format. >> Exabgp - Mostly used for API driven applications, monitoring with >> heartbeat scripts. >> (many others) >> >> DDoS detection and/or filtering: >> >> Fastnetmon - Supports many methods for packet processing. >> Ddosdetector (IPv4 Only) - Uses netmap for packet processing. >> >> Top Talkers + Other Creativeness (like fib compressing, or route >> optimization): >> >> pmacct - sflow/netflow combined with BGP, and a database backend >> >> Servers: >> >> Sensu or LibreNMS for Nagios type monitoring. >> >> Diagnostics: >> >> MTR - ...and knowing how to interpret it's output. >> >> -Ryan >> >> -- > Mehmet > +1-424-298-1903 > -- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.kuehl at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Mon Jul 8 13:49:19 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Mon, 8 Jul 2019 09:49:19 -0400 Subject: Must have ISP Open Source & tools In-Reply-To: References: <20190708001606.GA2592@jima.tpb.net> Message-ID: On 7/7/19 8:42 PM, Ryan Hamel wrote: > Telegraf + InfluxDB = Tons of Grafana Dashboards This handles time-series data really, really well and also pairs quite well with the ELK stack (Elasticsearch + Logstash + Kibana) for event-oriented data. Kibana can talk to InfluxDB, and Grafana can talk to Elasticsearch to somewhat tie things together, but they each are of course focused on their own type of data. In particular, Logstash is a great place to send your syslog streams from all your gear toward. -- Brandon Martin From nicolas at ncartron.org Mon Jul 8 13:54:57 2019 From: nicolas at ncartron.org (Nico CARTRON) Date: Mon, 8 Jul 2019 15:54:57 +0200 Subject: Must have ISP Open Source & tools In-Reply-To: References: <20190708001606.GA2592@jima.tpb.net> Message-ID: <20190708135457.GC95908@Nicos-MBP.local.ncartron.org> On 08-Jul-2019 15:49 CEST, wrote: > On 7/7/19 8:42 PM, Ryan Hamel wrote: > > Telegraf + InfluxDB = Tons of Grafana Dashboards > > This handles time-series data really, really well and also pairs quite well > with the ELK stack (Elasticsearch + Logstash + Kibana) for event-oriented > data. Kibana can talk to InfluxDB, and Grafana can talk to Elasticsearch to > somewhat tie things together, but they each are of course focused on their > own type of data. > > In particular, Logstash is a great place to send your syslog streams from > all your gear toward. The Grafana guys have launched Loki (https://github.com/grafana/loki#loki-like-prometheus-but-for-logs), which is "Prometheus for logs". -- Nico From Ryan.Hamel at quadranet.com Mon Jul 8 14:27:35 2019 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Mon, 8 Jul 2019 14:27:35 +0000 Subject: Must have ISP Open Source & tools In-Reply-To: References: <20190708001606.GA2592@jima.tpb.net> Message-ID: <4cd7c7bd710f4e50803162e9fb68ea60@LAX-MBX01.quadranet.local> Java as a dependency this day and age… -Ryan From: Jason Kuehl Sent: Monday, July 08, 2019 6:41 AM To: Mehmet Akcin Cc: Ryan Hamel ; Niels Bakker ; nanog at nanog.org Subject: Re: Must have ISP Open Source & tools We use https://cbackup.me/en/ over Rancid -- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.kuehl at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From joeyabukiyin at gmail.com Tue Jul 2 21:18:28 2019 From: joeyabukiyin at gmail.com (Joe Yabuki) Date: Tue, 2 Jul 2019 23:18:28 +0200 Subject: QoS for Office365 Message-ID: Hi all, How do you deal with QoS for Office365, since the IPs are subject to changes ? How can we mark the trafic while keeping the security (I fear the marking based on TCP/UDP Ports since they are not without an additional risk coming from worms/virus using those ports for example, and doing that directly on the PCs doesn't seem to be the best solution) ? Many thanks, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From joeyabukiyin at gmail.com Wed Jul 3 08:36:31 2019 From: joeyabukiyin at gmail.com (Joe Yabuki) Date: Wed, 3 Jul 2019 10:36:31 +0200 Subject: DNSSEC implementation for Office365 Message-ID: Hi, Please is anyone aware of DNSSEC implementation for Office365 ? This information seems to be hard to get from Microsoft... and it's hard for me to think that they don't support it. Thanks, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From josephnelson at gmail.com Wed Jul 3 17:30:33 2019 From: josephnelson at gmail.com (Joe Nelson) Date: Wed, 3 Jul 2019 11:30:33 -0600 Subject: Level3/CenturyLink IRR Contact Message-ID: Does anyone know who to contact to have old information removed from Level3/CenturyLink's IRR. My ASN still shows in their registry with stale information from an old customer of theirs but I can't seem to find anyone at CenturyLink that even knows what an IRR is so I'm just going in circles. I'd like to just have the stale info removed so when I add my info to Merit, there isn't a conflict. Thanks, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.vanderwilson at gmail.com Wed Jul 3 18:50:28 2019 From: tim.vanderwilson at gmail.com (Tim Wilson) Date: Wed, 3 Jul 2019 20:50:28 +0200 Subject: CDN question Message-ID: Hi, folks, I have a question to you as experienced auditory. What is the advantages and disadvantages of building your own CDN (mainly, in USA, Brazil and Australia)? We are running a website and using CDNs for a while to delivery static content. Few guys brought this question for a tech review. And I'm curious of opinion of people who maybe did that. So far one of the bit advantages I see is distribution of authoritative DNS. But it is a bit too low for building and running CDN. Will appreciate any opinion shared privately or on this list. Thanks. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From udeme at ukutt.com Wed Jul 3 14:27:16 2019 From: udeme at ukutt.com (Udeme Ukutt) Date: Wed, 3 Jul 2019 10:27:16 -0400 Subject: [EXTERNAL] Re: Microsoft SNDS contact In-Reply-To: <908b5ee9-6c0c-5d2e-59b3-c0ce42c3dfd1@gameservers.com> References: <2cb8d125-cf3b-9cea-3f40-0d1895189932@netravnen.de> <908b5ee9-6c0c-5d2e-59b3-c0ce42c3dfd1@gameservers.com> Message-ID: Hey Brian - try msn-snds at microsoft.com. IIRC that's more geared towards JMRP, but I think there's a chance. Udeme Postmaster at Wish On Wed, Jul 3, 2019 at 10:14 AM Brian Rak wrote: > > On 7/3/2019 10:09 AM, Hansen, Christoffer wrote: > > On 03/07/2019 15:50, Hansen, Christoffer wrote: > >> https://sendersupport.olc.protection.outlook.com/snds/addnetwork.aspx > > E.g. with asn 20473. Key that in. I can select the address fetched from > > a background WHOIS lookup by MS Smart Network Data Service. For the > > confirmation email to be sent to. > > > > We've tried this approach in the past, but it ends up dragging in a lot > of IP space that we're announcing on behalf of customers. This is less > then ideal, as then we either have to go back and manually remove all > the customer owned IP space, or deal with a bunch of noise from it. > We'd be willing to accept that as a solution if it were a one-off thing, > but it's a lot of extra work to do every time we acquire more IP space. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From udeme at ukutt.com Wed Jul 3 14:50:11 2019 From: udeme at ukutt.com (Udeme Ukutt) Date: Wed, 3 Jul 2019 10:50:11 -0400 Subject: [EXTERNAL] Re: Microsoft SNDS contact In-Reply-To: <53d05b69-1497-b6d6-adeb-65165040cbeb@gameservers.com> References: <2cb8d125-cf3b-9cea-3f40-0d1895189932@netravnen.de> <908b5ee9-6c0c-5d2e-59b3-c0ce42c3dfd1@gameservers.com> <53d05b69-1497-b6d6-adeb-65165040cbeb@gameservers.com> Message-ID: Ah, oops. On Wed, Jul 3, 2019 at 10:46 AM Brian Rak wrote: > Yea, that's the email we've been using (that's trying to tell us to just > split it into /24s) > On 7/3/2019 10:27 AM, Udeme Ukutt wrote: > > Hey Brian - try msn-snds at microsoft.com. IIRC that's more geared towards > JMRP, but I think there's a chance. > > Udeme > Postmaster at Wish > > On Wed, Jul 3, 2019 at 10:14 AM Brian Rak wrote: > >> >> On 7/3/2019 10:09 AM, Hansen, Christoffer wrote: >> > On 03/07/2019 15:50, Hansen, Christoffer wrote: >> >> https://sendersupport.olc.protection.outlook.com/snds/addnetwork.aspx >> > E.g. with asn 20473. Key that in. I can select the address fetched from >> > a background WHOIS lookup by MS Smart Network Data Service. For the >> > confirmation email to be sent to. >> > >> >> We've tried this approach in the past, but it ends up dragging in a lot >> of IP space that we're announcing on behalf of customers. This is less >> then ideal, as then we either have to go back and manually remove all >> the customer owned IP space, or deal with a bunch of noise from it. >> We'd be willing to accept that as a solution if it were a one-off thing, >> but it's a lot of extra work to do every time we acquire more IP space. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Mon Jul 8 16:18:29 2019 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 8 Jul 2019 12:18:29 -0400 Subject: QoS for Office365 In-Reply-To: References: Message-ID: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> > On Jul 2, 2019, at 5:18 PM, Joe Yabuki wrote: > > Hi all, > > How do you deal with QoS for Office365, since the IPs are subject to changes ? > > How can we mark the trafic while keeping the security (I fear the marking based on TCP/UDP Ports since they are not without an additional risk coming from worms/virus using those ports for example, and doing that directly on the PCs doesn't seem to be the best solution) ? Add bandwidth? QoS is a great tool when you’re constrained and must classify your critical traffic, but it’s not a substitute of getting enough capacity to offices. I have only applied QoS to voice traffic to ensure it gets through, the rest you need to budget for the bandwidth needs of the site. The price of bandwidth likely isn’t insane in your market, but your budget may be.. I’ve found that most places won’t quote you a service for less than $1500 USD MRC. I know you can get the incumbents to often deliver 1G service for $2k/mo in the US (and possibly cheaper). I’ve found a lot of people are still stuck in TDM mentality instead of just getting a 1G/10G service. - Jared From job at ntt.net Mon Jul 8 16:21:11 2019 From: job at ntt.net (Job Snijders) Date: Mon, 8 Jul 2019 18:21:11 +0200 Subject: Level3/CenturyLink IRR Contact In-Reply-To: References: Message-ID: I will ping you off list with contact details. Kind regards, Job On Mon, Jul 8, 2019 at 6:20 PM Joe Nelson wrote: > > Does anyone know who to contact to have old information removed from Level3/CenturyLink's IRR. My ASN still shows in their registry with stale information from an old customer of theirs but I can't seem to find anyone at CenturyLink that even knows what an IRR is so I'm just going in circles. I'd like to just have the stale info removed so when I add my info to Merit, there isn't a conflict. > > Thanks, > > Joe From mark.tinka at seacom.mu Mon Jul 8 16:40:22 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 8 Jul 2019 18:40:22 +0200 Subject: QoS for Office365 In-Reply-To: References: Message-ID: <8880b0c0-1013-fda6-bd51-7be607344e0f@seacom.mu> On 2/Jul/19 23:18, Joe Yabuki wrote: > Hi all,  > > How do you deal with QoS for Office365, since the IPs are subject to > changes ? > > How can we mark the trafic while keeping the security (I fear the > marking based on TCP/UDP Ports since they are not without an > additional risk coming from worms/virus using those ports for example, > and doing that directly on the PCs doesn't seem to be the best solution) ? Funny, I was just answering an internal question about this, last week. As with all things Internet, my stance is if you don't have end-to-end control, trying to do QoS is pointless. That said, I believe it should be possible to apply some kind of meaningful, end-to-end QoS together with Microsoft if you took up one of their Express Route services, given that is considered a private, premium service. Mark. From bill at herrin.us Mon Jul 8 16:39:41 2019 From: bill at herrin.us (William Herrin) Date: Mon, 8 Jul 2019 09:39:41 -0700 Subject: CDN question In-Reply-To: References: Message-ID: On Mon, Jul 8, 2019 at 9:22 AM Tim Wilson wrote: > What is the advantages and disadvantages of building your own CDN (mainly, in USA, Brazil and Australia)? We are running a website and using CDNs for a while to delivery static content. Few guys brought this question for a tech review. And I'm curious of opinion of people who maybe did that. Hi Tim, If by some miracle you manage to hire the technical experts needed to build a CDN that works, you'll find they get frustrated and quit over the whack-a-mole system balancing activity needed to operate a CDN. Unless you want to be in the CDN business itself, your best bet is to rent space on someone else's CDN. The secondary bonus of someone else's CDN is that you don't have much of a sunk cost, so if they have trouble keeping it working you can readily switch to a different company's CDN. This allows you to keep your eyes on the prize: the business your company is actually in. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Mon Jul 8 16:42:35 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 8 Jul 2019 18:42:35 +0200 Subject: QoS for Office365 In-Reply-To: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> Message-ID: On 8/Jul/19 18:18, Jared Mauch wrote: > > Add bandwidth? > > QoS is a great tool when you’re constrained and must classify your critical traffic, but it’s not a substitute of getting enough capacity to offices. > > I have only applied QoS to voice traffic to ensure it gets through, the rest you need to budget for the bandwidth needs of the site. The price of bandwidth likely isn’t insane in your market, but your budget may be.. I’ve found that most places won’t quote you a service for less than $1500 USD MRC. I know you can get the incumbents to often deliver 1G service for $2k/mo in the US (and possibly cheaper). > > I’ve found a lot of people are still stuck in TDM mentality instead of just getting a 1G/10G service. In some cases, the motivation for these requirements is fueled by trying to outsmart your competitors. I just don't know of a reliable, contractual way that you can use QoS to say your DIA or IP Transit service is better than that of your competitor. Mark. From spoofer-info at caida.org Mon Jul 8 17:00:06 2019 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Mon, 8 Jul 2019 10:00:06 -0700 Subject: Spoofer Report for NANOG for Jun 2019 Message-ID: <201907081700.x68H06Ad083230@fro.caida.org> In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within usa, can. Inferred improvements during Jun 2019: ASN Name Fixed-By 7849 CROCKERCOM 2019-06-06 19230 NANOG 2019-06-08 11427 SCRR-11427 2019-06-26 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Jun 2019: ASN Name First-Spoofed Last-Spoofed 6939 HURRICANE 2016-02-22 2019-06-29 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2019-06-26 6128 CABLE-NET-1 2016-09-03 2019-06-06 27364 ACS-INTERNET 2016-09-27 2019-06-28 20412 CLARITY-TELECOM 2016-09-30 2019-06-24 20001 ROADRUNNER-WEST 2016-10-08 2019-06-25 6181 FUSE-NET 2016-10-10 2019-06-28 25787 ROWE-NETWORKS 2016-10-21 2019-06-29 174 COGENT-174 2016-10-21 2019-06-28 30341 SCTA-ASN 2016-10-31 2019-06-18 32440 LONI 2016-11-03 2019-06-25 12083 WOW-INTERNET 2016-11-09 2019-06-30 13427 SOFTCOM-INTERNET-COMMUNICATION 2016-11-14 2019-06-26 21832 KELLINCOM-1 2017-02-03 2019-06-26 18451 LESNET 2017-02-22 2019-06-26 6327 SHAW 2017-03-24 2019-06-16 852 ASN852 2017-04-16 2019-06-18 19624 SERVERROOM 2017-06-02 2019-06-06 701 UUNET 2017-06-14 2019-06-04 63296 AMARILLO-WIRELESS 2017-09-01 2019-06-27 546 PARSONS-PGS-1 2017-11-20 2019-06-17 4201 ORST 2018-04-19 2019-06-26 225 VIRGINIA 2018-06-18 2019-06-20 33509 CASCADE-ACCESS-LLC-CA-ESTOR1 2018-06-22 2019-06-27 33452 RW 2018-09-19 2019-06-29 20448 VPNTRANET-LLC 2018-09-20 2019-06-26 63275 RADIOWIRE 2019-02-07 2019-06-11 8047 GCI 2019-04-11 2019-06-26 10745 ARIN-ASH-CHA 2019-04-29 2019-06-25 6058 NORTHWESTEL-INC 2019-05-06 2019-06-25 138576 2019-05-21 2019-06-29 6428 CDM 2019-06-04 2019-06-04 19751 CCRTC 2019-06-06 2019-06-25 33387 DATASHACK 2019-06-06 2019-06-28 21804 ACCESS-SK 2019-06-09 2019-06-11 16787 CHARTER-16787 2019-06-17 2019-06-17 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=usa,can&no_block=1 Please send any feedback or suggestions to spoofer-info at caida.org From tristan.hoar at bgfl.org Mon Jul 8 17:01:11 2019 From: tristan.hoar at bgfl.org (Tristan Hoar) Date: Mon, 08 Jul 2019 18:01:11 +0100 Subject: DNSSEC implementation for Office365 In-Reply-To: References: Message-ID: Hi Joe, outlook.com is unsigned so I doubt they support it. [trishoar at rhel8 ~]$ delv outlook.com ; unsigned answer outlook.com. 300 IN A 40.97.161.50 outlook.com. 300 IN A 40.97.128.194 outlook.com. 300 IN A 40.97.116.82 outlook.com. 300 IN A 40.97.160.2 outlook.com. 300 IN A 40.97.148.226 outlook.com. 300 IN A 40.97.153.146 outlook.com. 300 IN A 40.97.164.146 outlook.com. 300 IN A 40.97.156.114 Tris On Wed, 2019-07-03 at 10:36 +0200, Joe Yabuki wrote: > Hi, > > Please is anyone aware of DNSSEC implementation for Office365 ? This > information seems to be hard to get from Microsoft... and it's hard > for me to think that they don't support it. > > Thanks, > Joe > ************************************************************* > This message has been checked for viruses by the > Birmingham Grid for Learning. For guidance on good > e-mail practice, e-mail viruses and hoaxes please visit: > http://www.bgfl.org/emailaup > ************************************************************* > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From matt at netfire.net Mon Jul 8 17:14:54 2019 From: matt at netfire.net (Matt Harris) Date: Mon, 8 Jul 2019 12:14:54 -0500 Subject: Level3/CenturyLink IRR Contact In-Reply-To: References: Message-ID: On Mon, Jul 8, 2019 at 11:20 AM Joe Nelson wrote: > Does anyone know who to contact to have old information removed from > Level3/CenturyLink's IRR. My ASN still shows in their registry with stale > information from an old customer of theirs but I can't seem to find anyone > at CenturyLink that even knows what an IRR is so I'm just going in > circles. I'd like to just have the stale info removed so when I add my > info to Merit, there isn't a conflict. > > Thanks, > > Joe > Same issue here. Was never able to get anyone to correct it after trying a solid handful of email contacts there. What's weird is that the entry was created while I owned the space and was created by a large enough organization that I'm not sure it's fraud (plus they've never tried announcing the space that I've seen) but I don't see how it'd have been a typo based on the space they are announcing, so I'm not sure exactly what the people involved were thinking. My IPv6 /32 is in the Level3 IRR db though, with an origin set to AS22773 which is an organization I've never had any relationship with whatsoever. Good luck! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssaner at hubris.net Mon Jul 8 17:44:52 2019 From: ssaner at hubris.net (Steve Saner) Date: Mon, 8 Jul 2019 12:44:52 -0500 Subject: Level3/CenturyLink IRR Contact In-Reply-To: References: Message-ID: On 7/8/19 12:14 PM, Matt Harris wrote: > On Mon, Jul 8, 2019 at 11:20 AM Joe Nelson > wrote: > > Does anyone know who to contact to have old information removed from > Level3/CenturyLink's IRR.  My ASN still shows in their registry with > stale information from an old customer of theirs but I can't seem to > find anyone at CenturyLink that even knows what an IRR is so I'm > just going in circles.  I'd like to just have the stale info removed > so when I add my info to Merit, there isn't a conflict. > > Thanks, > > Joe I had the same issue show up with a netblock that we used to route for a customer. That netblock has now been allocated to someone else and they contacted me to see if we could get it removed from the IRR as it was causing them some trouble. I still have a circuit with Level3/CenturyLink, so I ended up opening a trouble ticket through the customer portal on that circuit and explained my need. I got a response back that it had been removed from the BGP filters, so I had to explain that while that's find and good, I'm really needing it removed from the IRR. The response back after that was that it isn't in the IRR. I wrote back showing that it in fact was in the IRR. After a couple days of no response I commented the ticket again asking for the issue to be escalated. Finally got a response back that it had been removed. Took about a week total. Steve -- -------------------------------------------------------------------------- Steven Saner Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communications http://www.hubris.net From bensons at pc.nanog.org Mon Jul 8 18:47:21 2019 From: bensons at pc.nanog.org (Benson Schliesser) Date: Mon, 8 Jul 2019 14:47:21 -0400 Subject: NANOG 77 call for presentations is open Message-ID: NANOG Community, The NANOG Program Committee (PC) is excited to announce that we are now accepting proposals for all sessions at NANOG 77 in Austin, Texas, October 28-30, 2019. Below is a summary of key details and dates from the Call For Presentations on the NANOG website, which can be found at https://nanog.org/meetings/nanog-77/. Given by many of the industry’s top minds, presentations at NANOG meetings are meant to spark the imagination, encourage dialog, and drive new solutions to our greatest networking challenges. The PC is currently seeking proposals, and also welcomes suggestions for speakers and topics. Presentations may cover current technologies, soon-to-be deployed technologies, and industry innovation. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations should not be promotional, or discuss proprietary solutions. The primary speaker, moderator, or author should submit a presentation proposal and abstract via the PC Tool at: https://pc.nanog.org - Select “Propose Talk” from the “Talks” menu - Select NANOG 77 from the Meeting menu - Select the appropriate *Session* the talk will be presented in - General Session (30-45 minutes) - Tutorial (90-120 minutes) - Track (90-120 minutes) Timeline for submission and proposal review: - Submitter enters abstract (and draft slides if possible) in PC Tool prior to the deadline for slide submission. - PC performs initial review and assigns a “shepherd” to help develop the submission — within 2 weeks. - Submitter develops draft slides of talk if not already submitted with the initial proposal. Please submit initial draft slides early — the PC does not evaluate submissions until draft slides are available for review. NANOG Staff is available to assist with slide templates upon request from the submitter. - Panel and Track submissions should provide a topic list and intended/confirmed participants in the abstract. - PC reviews the slides and continues to work with Submitter as needed to develop the topic. - Draft presentation slides should be submitted prior to the published deadline for slides (Aug. 19, 2019). - PC evaluates submissions to determine presentations for the agenda (posted on Sep 30, 2019). - Agenda assembled and posted. - Submitters notified. - Final presentation slides must be submitted prior to the published deadline for slides (Oct. 21, 2019). If you think you have an interesting topic but want feedback or suggestions for developing an idea into a presentation, please email the PC ( nanogpc at nanog.org), and a representative will respond to you in a timely manner. Otherwise, submit your talk, keynote, track, or panel proposal to the PC Tool at your earliest convenience. We look forward to reviewing your submission! Key dates for NANOG 77: Date Event/Deadline Jul. 1, 2019 CFP Opens & Agenda Outline Posted, Early Registration Begins Jul. 22, 2019 Standard Registration Begins Aug. 19, 2019 CFP Deadline: Presentation Slides Due Sep. 23, 2019 CFP Topic List & NANOG Meeting HIghlights Page posted, Late Registration Begins Sep. 30, 2019 NANOG 77 Agenda Posted Oct. 21, 2019 Speaker FINAL presentations DUE (NO CHANGES accepted after this date) Oct. 27, 2019 Lightning Talk Submissions Open, Onsite Registration Begins Final slides must be submitted by Monday, October 21, 2019, and no changes will be accepted between that date and the conference. Materials received after that date may be updated on the website after the completion of the conference. We look forward to seeing you in October in Austin, Texas! Sincerely, Benson Schliesser On behalf of the NANOG PC -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at kumari.net Mon Jul 8 18:50:29 2019 From: warren at kumari.net (Warren Kumari) Date: Mon, 8 Jul 2019 14:50:29 -0400 Subject: QoS for Office365 In-Reply-To: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> Message-ID: On Mon, Jul 8, 2019 at 12:31 PM Jared Mauch wrote: > > > > > On Jul 2, 2019, at 5:18 PM, Joe Yabuki wrote: > > > > Hi all, > > > > How do you deal with QoS for Office365, since the IPs are subject to changes ? > > > > How can we mark the trafic while keeping the security (I fear the marking based on TCP/UDP Ports since they are not without an additional risk coming from worms/virus using those ports for example, and doing that directly on the PCs doesn't seem to be the best solution) ? > > > Add bandwidth? > > QoS is a great tool when you’re constrained and must classify your critical traffic, but it’s not a substitute of getting enough capacity to offices. Depends -- I'd note that the OP said "How can we mark the trafic while keeping the security..." -- some people use the COS / DSCP bits to annotate packets with security information, and use that to make *security decisions* instead of using it to prioritize traffic. Now, I'm not saying that this is why the OP is asking (or that I think it is a good idea, because, well, I don't think it is!), but it *is* a practice worth knowing about. One enterprise I've seen does: firewall { family inet { filter Egress { term allow { from { prefix-list { TrustedSubnets; } dscp af42; } then accept; } term default { then { encapsulate CaptiveGarden; } } } } } They have some shim thingie on corporate machines which tags "approved" traffic with AF42 (and also mark on switches from other devices which should have Internet access), and everyone else gets bumped to a captive portal / logging / scrubbing firewall thingie. This is remarkably bletcherous, but (because?) you can do 'iptables -t mangle -A FORWARD -j dscp --set-dscp-class AF42' to tag all packets... W > > I have only applied QoS to voice traffic to ensure it gets through, the rest you need to budget for the bandwidth needs of the site. The price of bandwidth likely isn’t insane in your market, but your budget may be.. I’ve found that most places won’t quote you a service for less than $1500 USD MRC. I know you can get the incumbents to often deliver 1G service for $2k/mo in the US (and possibly cheaper). > > I’ve found a lot of people are still stuck in TDM mentality instead of just getting a 1G/10G service. > > - Jared -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From mark.tinka at seacom.mu Mon Jul 8 18:59:06 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 8 Jul 2019 20:59:06 +0200 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> Message-ID: <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> On 8/Jul/19 20:50, Warren Kumari wrote: > Depends -- I'd note that the OP said "How can we mark the trafic while > keeping the security..." -- some people use the COS / DSCP bits to > annotate packets with security information, and use that to make > *security decisions* instead of using it to prioritize traffic. Now, > I'm not saying that this is why the OP is asking (or that I think it > is a good idea, because, well, I don't think it is!), but it *is* a > practice worth knowing about. Assuming we are discussing such packets traversing the public Internet, a little tricky to expect IPP/DSCP values to remain intact in the life of an Internet packet. Mark. From rwfireguru at gmail.com Mon Jul 8 19:03:18 2019 From: rwfireguru at gmail.com (Robert Webb) Date: Mon, 8 Jul 2019 15:03:18 -0400 Subject: QoS for Office365 In-Reply-To: <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> Message-ID: I took the OP's request as for doing QoS at the edge of their network and not necessarily the entire path. As another person stated, the real answer is to add more bandwidth if you are having to QoS to Office365 because it is affecting other internet based services. Robert On Mon, Jul 8, 2019 at 3:00 PM Mark Tinka wrote: > > > On 8/Jul/19 20:50, Warren Kumari wrote: > > > Depends -- I'd note that the OP said "How can we mark the trafic while > > keeping the security..." -- some people use the COS / DSCP bits to > > annotate packets with security information, and use that to make > > *security decisions* instead of using it to prioritize traffic. Now, > > I'm not saying that this is why the OP is asking (or that I think it > > is a good idea, because, well, I don't think it is!), but it *is* a > > practice worth knowing about. > > Assuming we are discussing such packets traversing the public Internet, > a little tricky to expect IPP/DSCP values to remain intact in the life > of an Internet packet. > > Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at kumari.net Mon Jul 8 19:06:13 2019 From: warren at kumari.net (Warren Kumari) Date: Mon, 8 Jul 2019 15:06:13 -0400 Subject: QoS for Office365 In-Reply-To: <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> Message-ID: On Mon, Jul 8, 2019 at 2:59 PM Mark Tinka wrote: > > > > On 8/Jul/19 20:50, Warren Kumari wrote: > > > Depends -- I'd note that the OP said "How can we mark the trafic while > > keeping the security..." -- some people use the COS / DSCP bits to > > annotate packets with security information, and use that to make > > *security decisions* instead of using it to prioritize traffic. Now, > > I'm not saying that this is why the OP is asking (or that I think it > > is a good idea, because, well, I don't think it is!), but it *is* a > > practice worth knowing about. > > Assuming we are discussing such packets traversing the public Internet, > a little tricky to expect IPP/DSCP values to remain intact in the life > of an Internet packet. Goodness no -- I've only ever seen this done within a single network (including inside some tunnels); expecting this to work across the Big I-internet is crazypants time. I personally think that the idea itself is stupid, but, well, their network, their rules, and it "works" for them. W > > Mark. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From adamv0025 at netconsultings.com Mon Jul 8 20:01:56 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Mon, 8 Jul 2019 21:01:56 +0100 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> Message-ID: <032301d535c7$feb95320$fc2bf960$@netconsultings.com> > Warren Kumari > Sent: Monday, July 8, 2019 8:06 PM > > On Mon, Jul 8, 2019 at 2:59 PM Mark Tinka wrote: > > > > > > > > On 8/Jul/19 20:50, Warren Kumari wrote: > > > > > Depends -- I'd note that the OP said "How can we mark the trafic > > > while keeping the security..." -- some people use the COS / DSCP > > > bits to annotate packets with security information, and use that to > > > make *security decisions* instead of using it to prioritize traffic. > > > Now, I'm not saying that this is why the OP is asking (or that I > > > think it is a good idea, because, well, I don't think it is!), but > > > it *is* a practice worth knowing about. > > > > Assuming we are discussing such packets traversing the public > > Internet, a little tricky to expect IPP/DSCP values to remain intact > > in the life of an Internet packet. > > Goodness no -- I've only ever seen this done within a single network > (including inside some tunnels); expecting this to work across the Big I- > internet is crazypants time. I personally think that the idea itself is stupid, > but, well, their network, their rules, and it "works" for them. > And yet the SD-WAN promising MPLS experience over the internet and other BS sells like crazy ;) adam From sean at donelan.com Mon Jul 8 20:49:07 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 8 Jul 2019 16:49:07 -0400 (EDT) Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC Message-ID: I don't think SHAKEN/STIR really addresses the root problems with spoofing phone numbers, anymore than any of the BGP proposals for spoofing IP addresses. Nevertheless, the FCC wants to be seen as doing something. So Chairman Pai is having a summit to show all the progress. On Thursday, July 11, 2019, FCC Chairman Ajit Pai will convene a summit focused on the industry’s implementation of SHAKEN/STIR, a caller ID authentication framework to combat illegal robocalls and caller ID spoofing. Chairman Pai expects major voice service providers to deploy the SHAKEN/STIR framework this year. The summit will showcase the progress that major providers have made toward reaching that goal and provide an opportunity to identify any challenges to implementation and how best to overcome them. https://www.fcc.gov/SHAKENSTIRSummit Date: Thursday, July 11, 2019 Time: Unknown, the public announcement did not include the time. Usually these summits start around 9am EDT. Location: Commission Meeting Room at FCC Headquarters, 445 12th Street, S.W. Washington, D.C. 20554. It will also be streamed at the FCC’s web page at www.fcc.gov/live. From la at qrator.net Mon Jul 8 20:54:37 2019 From: la at qrator.net (Alexander Lyamin) Date: Mon, 8 Jul 2019 22:54:37 +0200 Subject: Must have ISP Open Source & tools In-Reply-To: References: Message-ID: I would chime in with tools for network analysis and planning: http://bgp.he.net/ http://isolario.it http://radar.qrator.net last one is something we work on as a community project. On Mon, Jul 8, 2019 at 2:07 AM Mehmet Akcin wrote: > Hey there > > We are a growing ISP in Colombia and Latin America. I am interested in > hearing from others regarding tools and software they recommend we must > have such as LibreNMS, Rancid etc. > > It’s greenfieldish now ;-) so feel free to recommend A-Z anything! ;-) > > Hope this thread is useful others too! > > Mehmet > -- > Mehmet > +1-424-298-1903 > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jra at baylink.com Mon Jul 8 20:59:58 2019 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 8 Jul 2019 20:59:58 +0000 (UTC) Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: Message-ID: <1268340919.728322.1562619598838.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Sean Donelan" > I don't think SHAKEN/STIR really addresses the root problems with > spoofing phone numbers, anymore than any of the BGP proposals for spoofing > IP addresses. > > Nevertheless, the FCC wants to be seen as doing something. So Chairman > Pai is having a summit to show all the progress. > > On Thursday, July 11, 2019, FCC Chairman Ajit Pai will convene a summit > focused on the industry’s implementation of SHAKEN/STIR, a caller ID > authentication framework to combat illegal robocalls and caller ID > spoofing. Chairman Pai expects major voice service providers to deploy > the SHAKEN/STIR framework this year. The summit will showcase the > progress that major providers have made toward reaching that goal and > provide an opportunity to identify any challenges to implementation and > how best to overcome them. Well, y'know, it's been 10 years since I originated calls to LD carriers. But when I did, 3 of my carriers (VZN and 2 LDs) trapped outgoing calls that weren't for 10D calling numbers *they had assigned us* (and hence I had to work that out with them to prove that *someone* had)... nd the other 2 didn't give a crap. I could send them anything -- even calls with CNID that wasn't a valid NANP address (4th digit 1, frex). Since nearly all of this is being originated over PRIs to LD carriers, right; maybe if the FCC just threatened the LD carriers who do not do the calling number legitimacy enforcement the regs (I think) already require them to do...? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mark.tinka at seacom.mu Mon Jul 8 21:49:56 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 8 Jul 2019 23:49:56 +0200 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> Message-ID: <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> On 8/Jul/19 21:03, Robert Webb wrote: > I took the OP's request as for doing QoS at the edge of their network > and not necessarily the entire path. Indeed, but even then, you could be handing off the traffic to a downstream customer, and can't guarantee what they do to those ToS fields. > > As another person stated, the real answer is to add more bandwidth if > you are having to QoS to Office365 because it is affecting other > internet based services. Yes and no. More bandwidth never hurt anyone, but packet loss in the remote network toward the cloud will hurt you. Mark. From mark.tinka at seacom.mu Mon Jul 8 21:51:20 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Mon, 8 Jul 2019 23:51:20 +0200 Subject: QoS for Office365 In-Reply-To: <032301d535c7$feb95320$fc2bf960$@netconsultings.com> References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <032301d535c7$feb95320$fc2bf960$@netconsultings.com> Message-ID: <12628ef0-2af9-4669-4d83-b1d26806f667@seacom.mu> On 8/Jul/19 22:01, adamv0025 at netconsultings.com wrote: > And yet the SD-WAN promising MPLS experience over the internet and other BS sells like crazy ;) Where have we seen that before... Still waiting for the ATM port on my laptop :-). Mark. From beckman at angryox.com Mon Jul 8 21:53:19 2019 From: beckman at angryox.com (Peter Beckman) Date: Mon, 8 Jul 2019 17:53:19 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <1268340919.728322.1562619598838.JavaMail.zimbra@baylink.com> References: <1268340919.728322.1562619598838.JavaMail.zimbra@baylink.com> Message-ID: Summary: SHAKEN/STIR does nothing but sign a call by a carrier that can be verified by another carrier that they signed it. It does nothing to stem Robocalls. Discussion: All SHAKEN/STIR does is have the originating carrier of a call to cryptographically attest, to some degree, that the call originated from their network. One example given was that SHAKEN/STIR can verify that it is really the IRS calling. But that would require knowledge of which carrier currently serves the IRS, and that the IRS use that same carrier for both inbound AND outbound calling, and that the carrier publishes some record that it is the carrier of record for the given phone number. THIS DOES NOT EXIST in SHAKEN/STIR. If Carrier A is taking calls from a spammer and implements SHAKEN/STIR, and their termination Carrier B have also implemented SHAKEN/STIR verification and trusted Carrier A's certificate, all that occurs is that Carrier A says "this call is trustworthy" and Carrier B verifies that Carrier A said so and completes the call. Carrier A can lie all they want, as they do now, providing a false "Full Attestation" that the "service provider has authenticated the calling party and they are authorized to use the calling number." But there's no proof that they are telling the truth, and no way for any other intermediate carrier to verify anything other than the originating carrier. Now if Carrier B decides not to trust Carrier A anymore, they can stop trusting their cert and drop calls. Which Carrier B can do today by terminating the relationship with Carrier A. I still don't see how this will stop CallerID spoofing or Robocalls. Carrier B can block Carrier A at anytime. Carrier A can attest that any call originating from it is authorized to use that number. Plus then there's a ton of intermediates that aren't even addressed here. Do all the Intermediates also need to implement SHAKEN/STIR such that the SIP Identity header is passed onto the next leg? If the intermediate drops the header, does the call fail? And spammers already use real, leased phone numbers for Robocalls. We had a client come to us who wanted 5,000 new/different and not recycled phone numbers across the US each month. When prompted about how they'd be used, they just needed inbound calls and SMS messages routed to their switch hosted at a cloud provider, outbound calls would be made through another carrier. With SHAKEN/STIR, these calls would show up as "Authenticated" as the client could tell their Carrier C that these 5,000 phone numbers were theirs, and Carrier C could do a "Full Attestation" SIP Identity header and the spam calls would show up as "Verified." But still Robocalls, just Verified Robocalls. We declined to do business with this client. In summary, SHAKEN/STIR seems to do nothing but be some extra technical work. Please correct me if I'm missing a key piece of this. I'm in DC, I'm going to try to attend this summit. https://transnexus.com/whitepapers/understanding-stir-shaken/ Beckman On Mon, 8 Jul 2019, Jay R. Ashworth wrote: > ----- Original Message ----- >> From: "Sean Donelan" > >> I don't think SHAKEN/STIR really addresses the root problems with >> spoofing phone numbers, anymore than any of the BGP proposals for spoofing >> IP addresses. >> >> Nevertheless, the FCC wants to be seen as doing something. So Chairman >> Pai is having a summit to show all the progress. >> >> On Thursday, July 11, 2019, FCC Chairman Ajit Pai will convene a summit >> focused on the industry’s implementation of SHAKEN/STIR, a caller ID >> authentication framework to combat illegal robocalls and caller ID >> spoofing. Chairman Pai expects major voice service providers to deploy >> the SHAKEN/STIR framework this year. The summit will showcase the >> progress that major providers have made toward reaching that goal and >> provide an opportunity to identify any challenges to implementation and >> how best to overcome them. > > Well, y'know, it's been 10 years since I originated calls to LD carriers. > > But when I did, 3 of my carriers (VZN and 2 LDs) trapped outgoing calls > that weren't for 10D calling numbers *they had assigned us* (and hence I > had to work that out with them to prove that *someone* had)... > > nd the other 2 didn't give a crap. I could send them anything -- even calls > with CNID that wasn't a valid NANP address (4th digit 1, frex). > > Since nearly all of this is being originated over PRIs to LD carriers, right; > maybe if the FCC just threatened the LD carriers who do not do the calling > number legitimacy enforcement the regs (I think) already require them to do...? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From warren at kumari.net Mon Jul 8 22:35:58 2019 From: warren at kumari.net (Warren Kumari) Date: Mon, 8 Jul 2019 18:35:58 -0400 Subject: QoS for Office365 In-Reply-To: <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> Message-ID: On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka wrote: > > > > On 8/Jul/19 21:03, Robert Webb wrote: > > I took the OP's request as for doing QoS at the edge of their network > > and not necessarily the entire path. > > Indeed, but even then, you could be handing off the traffic to a > downstream customer, and can't guarantee what they do to those ToS fields. I disagree -- you *can* guarantee what someone else will do with your ToS fields....... they will A: ignore them and / or B: scribble all over them. At a previous employer (AOL, doing VoIP for customer service / call centers, ~2004) we had a number of contractual agreements with multiple providers to honor our QoS markings -- as far as I could tell (marking test traffic under congestion events) only one of about seven did anything at all with the marking, and that wasn't enough to make any difference... I briefly toyed with the idea of asking for some money back / trying to enforce the terms of the agreements, but figured that there wasn't much point - expecting QoS to work in someone else's network based upon your markings seems like a fool's errand. W > > > > > > As another person stated, the real answer is to add more bandwidth if > > you are having to QoS to Office365 because it is affecting other > > internet based services. > > Yes and no. > > More bandwidth never hurt anyone, but packet loss in the remote network > toward the cloud will hurt you. > > Mark. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From mark.tinka at seacom.mu Mon Jul 8 22:40:11 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 9 Jul 2019 00:40:11 +0200 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> Message-ID: On 9/Jul/19 00:35, Warren Kumari wrote: > I disagree -- you *can* guarantee what someone else will do with your > ToS fields....... they will A: ignore them and / or B: scribble all > over them. I'll rephrase... you can't guarantee that a remote network will handle your packets the way you intend. > At a previous employer (AOL, doing VoIP for customer service / call > centers, ~2004) we had a number of contractual agreements with > multiple providers to honor our QoS markings -- as far as I could tell > (marking test traffic under congestion events) only one of about seven > did anything at all with the marking, and that wasn't enough to make > any difference... I briefly toyed with the idea of asking for some > money back / trying to enforce the terms of the agreements, but > figured that there wasn't much point - expecting QoS to work in > someone else's network based upon your markings seems like a fool's > errand. Agreed. I would, though, say that I admire that you went as far as ringing up contracts on the back of this. Mark. From kmedcalf at dessus.com Mon Jul 8 23:00:57 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 08 Jul 2019 17:00:57 -0600 Subject: QoS for Office365 In-Reply-To: <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> Message-ID: <12ce59cd1001ed4fa06968d702379c0e@mail.dessus.com> Using Orifice 342 will hurt you. Packet loss (the more the better) will only help you. -- 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 Mark Tinka >Sent: Monday, 8 July, 2019 15:50 >To: Robert Webb >Cc: NANOG list >Subject: Re: QoS for Office365 > > > >On 8/Jul/19 21:03, Robert Webb wrote: >> I took the OP's request as for doing QoS at the edge of their >network >> and not necessarily the entire path. > >Indeed, but even then, you could be handing off the traffic to a >downstream customer, and can't guarantee what they do to those ToS >fields. > > >> >> As another person stated, the real answer is to add more bandwidth >if >> you are having to QoS to Office365 because it is affecting other >> internet based services. > >Yes and no. > >More bandwidth never hurt anyone, but packet loss in the remote >network >toward the cloud will hurt you. > >Mark. From mike at mtcc.com Tue Jul 9 00:08:24 2019 From: mike at mtcc.com (Michael Thomas) Date: Mon, 8 Jul 2019 17:08:24 -0700 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: <1268340919.728322.1562619598838.JavaMail.zimbra@baylink.com> Message-ID: <6fb05c87-477d-a329-ee74-dbf1ad4267fa@mtcc.com> when we did DKIM back in the day, almost nobody was requiring SMTP auth which meant the providers could say "blame me" via the DKIM signature, but couldn't really take much action since they didn't know who has doing it. we sort of took a leap of faith that that would happen.  nowadays, almost everybody requires SMTP auth (and tls, ...) afaik. i have no idea whether DKIM was in any way a motivating factor, but it did happen in the meantime. i know the parallels here are not exact (is it really PRI's that are the source of most of the spam?) , but it's maybe a little premature to completely write off the providers for doing the Right Thing. putting the "blame me" badge on might give them some incentive to clean up their act. as with email spam, there is no silver bullet of course. fwiw, the stir/shaken problem statement is a good read. https://datatracker.ietf.org/doc/rfc7340/ Mike On 7/8/19 2:53 PM, Peter Beckman wrote: > Summary: > > SHAKEN/STIR does nothing but sign a call by a carrier that can be > verified > by another carrier that they signed it. It does nothing to stem > Robocalls. > > Discussion: > > All SHAKEN/STIR does is have the originating carrier of a call to > cryptographically attest, to some degree, that the call originated from > their network. > > One example given was that SHAKEN/STIR can verify that it is really > the IRS > calling. > > But that would require knowledge of which carrier currently serves the > IRS, > and that the IRS use that same carrier for both inbound AND outbound > calling, and that the carrier publishes some record that it is the > carrier > of record for the given phone number. THIS DOES NOT EXIST in SHAKEN/STIR. > > If Carrier A is taking calls from a spammer and implements > SHAKEN/STIR, and > their termination Carrier B have also implemented SHAKEN/STIR > verification > and trusted Carrier A's certificate, all that occurs is that Carrier A > says > "this call is trustworthy" and Carrier B verifies that Carrier A said so > and completes the call. > > Carrier A can lie all they want, as they do now, providing a false "Full > Attestation" that the "service provider has authenticated the calling > party > and they are authorized to use the calling number." But there's no proof > that they are telling the truth, and no way for any other intermediate > carrier to verify anything other than the originating carrier. > > Now if Carrier B decides not to trust Carrier A anymore, they can stop > trusting their cert and drop calls. Which Carrier B can do today by > terminating the relationship with Carrier A. > > I still don't see how this will stop CallerID spoofing or Robocalls. > Carrier B can block Carrier A at anytime. Carrier A can attest that any > call originating from it is authorized to use that number. Plus then > there's a ton of intermediates that aren't even addressed here. Do all > the > Intermediates also need to implement SHAKEN/STIR such that the SIP > Identity > header is passed onto the next leg? If the intermediate drops the header, > does the call fail? > > And spammers already use real, leased phone numbers for Robocalls. We > had a client come to us who wanted 5,000 new/different and not recycled > phone numbers across the US each month. When prompted about how they'd be > used, they just needed inbound calls and SMS messages routed to their > switch hosted at a cloud provider, outbound calls would be made through > another carrier. > > With SHAKEN/STIR, these calls would show up as "Authenticated" as the > client could tell their Carrier C that these 5,000 phone numbers were > theirs, and Carrier C could do a "Full Attestation" SIP Identity > header and > the spam calls would show up as "Verified." But still Robocalls, just > Verified Robocalls. > > We declined to do business with this client. > > In summary, SHAKEN/STIR seems to do nothing but be some extra technical > work. > > Please correct me if I'm missing a key piece of this. > > I'm in DC, I'm going to try to attend this summit. > > https://transnexus.com/whitepapers/understanding-stir-shaken/ > > Beckman > > On Mon, 8 Jul 2019, Jay R. Ashworth wrote: > >> ----- Original Message ----- >>> From: "Sean Donelan" >> >>> I don't think SHAKEN/STIR really addresses the root problems with >>> spoofing phone numbers, anymore than any of the BGP proposals for >>> spoofing >>> IP addresses. >>> >>> Nevertheless, the FCC wants to be seen as doing something.  So Chairman >>> Pai is having a summit to show all the progress. >>> >>> On Thursday, July 11, 2019, FCC Chairman Ajit Pai will convene a summit >>> focused on the industry’s implementation of SHAKEN/STIR, a caller ID >>> authentication framework to combat illegal robocalls and caller ID >>> spoofing.  Chairman Pai expects major voice service providers to deploy >>> the SHAKEN/STIR framework this year.   The summit will showcase the >>> progress that major providers have made toward reaching that goal and >>> provide an opportunity to identify any challenges to implementation and >>> how best to overcome them. >> >> Well, y'know, it's been 10 years since I originated calls to LD >> carriers. >> >> But when I did, 3 of my carriers (VZN and 2 LDs) trapped outgoing calls >> that weren't for 10D calling numbers *they had assigned us* (and hence I >> had to work that out with them to prove that *someone* had)... >> >> nd the other 2 didn't give a crap.  I could send them anything -- >> even calls >> with CNID that wasn't a valid NANP address (4th digit 1, frex). >> >> Since nearly all of this is being originated over PRIs to LD >> carriers, right; >> maybe if the FCC just threatened the LD carriers who do not do the >> calling >> number legitimacy enforcement the regs (I think) already require them >> to do...? >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth                  Baylink jra at baylink.com >> Designer                     The Things I Think                       >> RFC 2100 >> Ashworth & Associates       http://www.bcp38.info 2000 Land Rover DII >> St Petersburg FL USA      BCP38: Ask For It By Name! +1 727 647 1274 >> > > --------------------------------------------------------------------------- > > Peter Beckman Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > From ramirezcyrus at yahoo.com Tue Jul 9 00:41:50 2019 From: ramirezcyrus at yahoo.com (cyrus ramirez) Date: Tue, 9 Jul 2019 00:41:50 +0000 (UTC) Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> Message-ID: <2112735119.362.1562632910837@mail.yahoo.com> Implement Quality of Service in Microsoft Teams | | | | | | | | | | | Implement Quality of Service in Microsoft Teams Prepare your organization's network for Quality of Service (QoS) in Microsoft Teams. | | | | Sent from Yahoo Mail on Android On Mon, Jul 8, 2019 at 12:47 PM, Mark Tinka wrote: On 8/Jul/19 18:18, Jared Mauch wrote: > > Add bandwidth? > > QoS is a great tool when you’re constrained and must classify your critical traffic, but it’s not a substitute of getting enough capacity to offices. > > I have only applied QoS to voice traffic to ensure it gets through, the rest you need to budget for the bandwidth needs of the site.  The price of bandwidth likely isn’t insane in your market, but your budget may be.. I’ve found that most places won’t quote you a service for less than $1500 USD MRC.  I know you can get the incumbents to often deliver 1G service for $2k/mo in the US (and possibly cheaper). > > I’ve found a lot of people are still stuck in TDM mentality instead of just getting a 1G/10G service. In some cases, the motivation for these requirements is fueled by trying to outsmart your competitors. I just don't know of a reliable, contractual way that you can use QoS to say your DIA or IP Transit service is better than that of your competitor. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Tue Jul 9 00:54:51 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 08 Jul 2019 18:54:51 -0600 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <6fb05c87-477d-a329-ee74-dbf1ad4267fa@mtcc.com> Message-ID: <3a7a0f7232773840871f3d63267435b1@mail.dessus.com> On Monday, 8 July, 2019 18:08, Michael Thomas wrote: >when we did DKIM back in the day, almost nobody was requiring SMTP >auth which meant the providers could say "blame me" via the DKIM >signature, >but couldn't really take much action since they didn't >know who has doing it. This is because DKIM was a solution to a problem that did not exist. You always know the identity of the MTA sending you a message, there never was a need for DKIM. It was a solution to a problem that does not and did not nor will ever exist. >we sort of took a leap of faith that that would happen. >nowadays, almost everybody requires SMTP auth (and tls, ...) afaik. i >have no idea whether DKIM was in any way a motivating factor, but it >did happen in the meantime. This happened long long long before DKIM was even a wet spot on the sheets. >i know the parallels here are not exact (is it really PRI's that are >the source of most of the spam?) , but it's maybe a little premature to >completely write off the providers for doing the Right Thing. putting >the "blame me" badge on might give them some incentive to clean up >their act. as with email spam, there is no silver bullet of course. The solution is to disallow spoofing. If the "pretty overlay information" does not equal the "billing information" then do not permit the call to be made. Easy Peasy. However, this will interfere with the carriers ability to make money since the ability to make money depends on being in cahoots with the fraudsters. Making it such that the Directors and Officers those carriers in cahoots suffer the death penalty (or life imprisonment) will solve the problem in an afternoon, but it will not happen because the cahooteers' (those Directors and Officers) own the slimy politicians needed to implement the cure. >fwiw, the stir/shaken problem statement is a good read. >https://datatracker.ietf.org/doc/rfc7340/ Not a bad work of complete fiction! Of course, the "root cause" can be found at the very beginning of the thing where it is pointed out that there are reasons for providing false data, and that since "the other guy" allows the presentation of false data, we should too otherwise we will go out of business. Once this "root cause" is accepted, then the inevitable ensues ... -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From mike at mtcc.com Tue Jul 9 00:58:17 2019 From: mike at mtcc.com (Michael Thomas) Date: Mon, 8 Jul 2019 17:58:17 -0700 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <3a7a0f7232773840871f3d63267435b1@mail.dessus.com> References: <3a7a0f7232773840871f3d63267435b1@mail.dessus.com> Message-ID: <80bac4e7-d504-c24f-acd3-0069b371c857@mtcc.com> On 7/8/19 5:54 PM, Keith Medcalf wrote: > On Monday, 8 July, 2019 18:08, Michael Thomas wrote: > >> when we did DKIM back in the day, almost nobody was requiring SMTP >> auth which meant the providers could say "blame me" via the DKIM >> signature, >but couldn't really take much action since they didn't >> know who has doing it. > This is because DKIM was a solution to a problem that did not exist. You always know the identity of the MTA sending you a message, there never was a need for DKIM. It was a solution to a problem that does not and did not nor will ever exist. > > ::eyeroll:: pray tell, how do you "always" know the identity of the MTA sending you a message? Mike From kmedcalf at dessus.com Tue Jul 9 01:06:34 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 08 Jul 2019 19:06:34 -0600 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <80bac4e7-d504-c24f-acd3-0069b371c857@mtcc.com> Message-ID: <53815a00d27a84409b49ee7726a2280d@mail.dessus.com> Wow! You must not know much about networking or programming if you do not know how to ask the OS to tell you the address/port associated with the "other end" of a TCP connection. Obviously you know who is sending the message since they are in bidirectional communication with you at the time you are receiving the message, and you need to know where to send the "carry on James" prompts to get them to send more data... Therefore you always know who submitted a message. -- 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: Michael Thomas [mailto:mike at fresheez.com] On Behalf Of Michael >Thomas >Sent: Monday, 8 July, 2019 18:58 >To: Keith Medcalf; nanog at nanog.org >Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC > > >On 7/8/19 5:54 PM, Keith Medcalf wrote: >> On Monday, 8 July, 2019 18:08, Michael Thomas >wrote: >> >>> when we did DKIM back in the day, almost nobody was requiring SMTP >>> auth which meant the providers could say "blame me" via the DKIM >>> signature, >but couldn't really take much action since they didn't >>> know who has doing it. >> This is because DKIM was a solution to a problem that did not >exist. You always know the identity of the MTA sending you a >message, there never was a need for DKIM. It was a solution to a >problem that does not and did not nor will ever exist. >> >> >::eyeroll:: pray tell, how do you "always" know the identity of the >MTA >sending you a message? > > >Mike From valdis.kletnieks at vt.edu Tue Jul 9 01:11:35 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Mon, 08 Jul 2019 21:11:35 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <80bac4e7-d504-c24f-acd3-0069b371c857@mtcc.com> References: <3a7a0f7232773840871f3d63267435b1@mail.dessus.com> <80bac4e7-d504-c24f-acd3-0069b371c857@mtcc.com> Message-ID: <6183.1562634695@turing-police> On Mon, 08 Jul 2019 17:58:17 -0700, Michael Thomas said: > On 7/8/19 5:54 PM, Keith Medcalf wrote: > > This is because DKIM was a solution to a problem that did not exist. > > > > > ::eyeroll:: pray tell, how do you "always" know the identity of the MTA > sending you a message? It's more subtle than that - you always know the "identity" of the purported MTA, because you know their IP address. Whether "purported" is the same as "legitimate" or "authorized" is a whole different kettle of fish.... Remember - port 25 is widely blocked precisely because there were always a plenty supply of MTAs whose identity you knew, sending you spam from consumer living rooms.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mike at mtcc.com Tue Jul 9 01:12:08 2019 From: mike at mtcc.com (Michael Thomas) Date: Mon, 8 Jul 2019 18:12:08 -0700 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <53815a00d27a84409b49ee7726a2280d@mail.dessus.com> References: <53815a00d27a84409b49ee7726a2280d@mail.dessus.com> Message-ID: <805d148d-7f5b-7449-6db9-9be987f24120@mtcc.com> Jon Callas, Eric Allman, the IETF security geek contingent and even me disagree with you. rfc 4871 disagrees with you. STD 76 disagrees with you. Trillions of signed messages disagree with you. Steve Bellovin probably disagrees with you too since you seem to be under the illusion that a reverse DNS lookup tells you anything useful. ::eyeroll:: Mike On 7/8/19 6:06 PM, Keith Medcalf wrote: > Wow! > > You must not know much about networking or programming if you do not know how to ask the OS to tell you the address/port associated with the "other end" of a TCP connection. Obviously you know who is sending the message since they are in bidirectional communication with you at the time you are receiving the message, and you need to know where to send the "carry on James" prompts to get them to send more data... > > Therefore you always know who submitted a message. > From mike at mtcc.com Tue Jul 9 01:23:46 2019 From: mike at mtcc.com (Michael Thomas) Date: Mon, 8 Jul 2019 18:23:46 -0700 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <6183.1562634695@turing-police> References: <3a7a0f7232773840871f3d63267435b1@mail.dessus.com> <80bac4e7-d504-c24f-acd3-0069b371c857@mtcc.com> <6183.1562634695@turing-police> Message-ID: <1f4c58dc-10f5-7eef-dc1b-86030f30427a@mtcc.com> On 7/8/19 6:11 PM, Valdis Klētnieks wrote: > On Mon, 08 Jul 2019 17:58:17 -0700, Michael Thomas said: >> On 7/8/19 5:54 PM, Keith Medcalf wrote: >>> This is because DKIM was a solution to a problem that did not exist. >>> >>> >> ::eyeroll:: pray tell, how do you "always" know the identity of the MTA >> sending you a message? > It's more subtle than that - you always know the "identity" of the purported > MTA, because you know their IP address. Whether "purported" is the same as > "legitimate" or "authorized" is a whole different kettle of fish.... > > Remember - port 25 is widely blocked precisely because there were always a > plenty supply of MTAs whose identity you knew, sending you spam from consumer > living rooms.... > Like I said, what DKIM brought is the ability to "blame me". knowing the IP address doesn't give you that in any useful way. Recall that trust is mainly a social construct, not a technical one. Bruce Schneier has written about that endlessly. Mike From kmedcalf at dessus.com Tue Jul 9 01:24:21 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 08 Jul 2019 19:24:21 -0600 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <805d148d-7f5b-7449-6db9-9be987f24120@mtcc.com> Message-ID: You are the only person who has mentioned reverse DNS lookups. However, it is true that you do in fact need to already know the identity of the sending MTA/MSA before you can do a "reverse DNS lookup". What does this have to do with the price of tea in China? And what value do you think a reverse DNS lookup adds to the identity information you already (obviously) have? -- 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: Michael Thomas [mailto:mike at fresheez.com] On Behalf Of Michael >Thomas >Sent: Monday, 8 July, 2019 19:12 >To: Keith Medcalf; nanog at nanog.org >Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC > >Jon Callas, Eric Allman, the IETF security geek contingent and even >me >disagree with you. rfc 4871 disagrees with you. STD 76 disagrees with >you. Trillions of signed messages disagree with you. Steve Bellovin >probably disagrees with you too since you seem to be under the >illusion >that a reverse DNS lookup tells you anything useful. > >::eyeroll:: > >Mike > >On 7/8/19 6:06 PM, Keith Medcalf wrote: >> Wow! >> >> You must not know much about networking or programming if you do >not know how to ask the OS to tell you the address/port associated >with the "other end" of a TCP connection. Obviously you know who is >sending the message since they are in bidirectional communication >with you at the time you are receiving the message, and you need to >know where to send the "carry on James" prompts to get them to send >more data... >> >> Therefore you always know who submitted a message. >> From mike at mtcc.com Tue Jul 9 01:28:24 2019 From: mike at mtcc.com (Michael Thomas) Date: Mon, 8 Jul 2019 18:28:24 -0700 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: Message-ID: On 7/8/19 6:24 PM, Keith Medcalf wrote: > You are the only person who has mentioned reverse DNS lookups. > I'm only trying to guess what enlightens your misinformed world. Mike From kmedcalf at dessus.com Tue Jul 9 01:38:03 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 08 Jul 2019 19:38:03 -0600 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <1f4c58dc-10f5-7eef-dc1b-86030f30427a@mtcc.com> Message-ID: <7412c94965f5114da0ed2915597f6ba3@mail.dessus.com> DKIM brought nothing of any value since it cannot be used to refuse messages or abort before entering the DATA phase of the SMTP conversation. You are, no matter what, committing resources to receiving the message and accepting responsibility for its delivery. All you can do is fart about AFTER THE FACT, after it is already too late to reject the message. Presently 99.999999% of the SPAM that gets through to me is DKIM signed, yet it is still spam. In fact, that DKIM signature provides absolutely nothing of value whatsoever, except to validate that the SPAM was unmolested between the sending MTA and me (which is unlikely anyway, and even more unlikely since the transport is almost always over a TLS channel which prevents tampering between the sending MTA and my MTA anyway). Like I said, DKIM does nothing of value and is directed to solve a problem that does not, never has, and never will, exist in the real world. Contrast this with SPF which does do something of value. It enables the dropping of the session BEFORE the DATA phase if the envelope-from domain is not on the list of authorized MTA to be sending messages for that domain. The only real problem with it is the allowance of prevarication in the data. -- 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: Michael Thomas [mailto:mike at fresheez.com] On Behalf Of Michael >Thomas >Sent: Monday, 8 July, 2019 19:24 >To: Valdis Klētnieks >Cc: Keith Medcalf; nanog at nanog.org >Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC > > >On 7/8/19 6:11 PM, Valdis Klētnieks wrote: >> On Mon, 08 Jul 2019 17:58:17 -0700, Michael Thomas said: >>> On 7/8/19 5:54 PM, Keith Medcalf wrote: >>>> This is because DKIM was a solution to a problem that did not >exist. >>>> >>>> >>> ::eyeroll:: pray tell, how do you "always" know the identity of >the MTA >>> sending you a message? >> It's more subtle than that - you always know the "identity" of the >purported >> MTA, because you know their IP address. Whether "purported" is the >same as >> "legitimate" or "authorized" is a whole different kettle of >fish.... >> >> Remember - port 25 is widely blocked precisely because there were >always a >> plenty supply of MTAs whose identity you knew, sending you spam >from consumer >> living rooms.... >> > >Like I said, what DKIM brought is the ability to "blame me". knowing >the >IP address doesn't give you that in any useful way. Recall that trust >is >mainly a social construct, not a technical one. Bruce Schneier has >written about that endlessly. > >Mike From kmedcalf at dessus.com Tue Jul 9 01:46:14 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 08 Jul 2019 19:46:14 -0600 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: Message-ID: On Monday, 8 July, 2019 19:28, Michael Thomas wrote: >On 7/8/19 6:24 PM, Keith Medcalf wrote: >> You are the only person who has mentioned reverse DNS lookups. >I'm only trying to guess what enlightens your misinformed world. You claimed that the "root problem" was not knowing who the originator was. I claimed that you ALWAYS must know who the originator is -- they are at the other end of the connection. You want to do a "reverse DNS lookup" for some reason. I still do not understand how doing a "reverse DNS lookup" will help with the identity at the other end of the connection, since you already have to know that identity in order to perform a reverse DNS lookup... -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From morrowc.lists at gmail.com Tue Jul 9 02:11:20 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 8 Jul 2019 22:11:20 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: Message-ID: when do we get back to stir/shaken? On Mon, Jul 8, 2019 at 9:47 PM Keith Medcalf wrote: > > > On Monday, 8 July, 2019 19:28, Michael Thomas wrote: > > >On 7/8/19 6:24 PM, Keith Medcalf wrote: > > >> You are the only person who has mentioned reverse DNS lookups. > > >I'm only trying to guess what enlightens your misinformed world. > > You claimed that the "root problem" was not knowing who the originator was. > > I claimed that you ALWAYS must know who the originator is -- they are at the other end of the connection. > > You want to do a "reverse DNS lookup" for some reason. > > I still do not understand how doing a "reverse DNS lookup" will help with the identity at the other end of the connection, since you already have to know that identity in order to perform a reverse DNS lookup... > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. > > > > From mike at mtcc.com Tue Jul 9 03:02:28 2019 From: mike at mtcc.com (Michael Thomas) Date: Mon, 8 Jul 2019 20:02:28 -0700 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: Message-ID: On 7/8/19 6:46 PM, Keith Medcalf wrote: > On Monday, 8 July, 2019 19:28, Michael Thomas wrote: > >> On 7/8/19 6:24 PM, Keith Medcalf wrote: >>> You are the only person who has mentioned reverse DNS lookups. >> I'm only trying to guess what enlightens your misinformed world. > You claimed that the "root problem" was not knowing who the originator was. > I have claimed no such thing. Mike From mike at mtcc.com Tue Jul 9 03:17:42 2019 From: mike at mtcc.com (Michael Thomas) Date: Mon, 8 Jul 2019 20:17:42 -0700 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: Message-ID: On 7/8/19 7:11 PM, Christopher Morrow wrote: > when do we get back to stir/shaken? that would be nice. i have a lot of questions about stir/shaken. attacking a problem statement rfc seems rather bizarre and unhinged to me. it outlines a lot of the objections i had to p-asserted-identity i had way back when. Mike From nanog at radu-adrian.feurdean.net Tue Jul 9 06:07:45 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Tue, 09 Jul 2019 08:07:45 +0200 Subject: QoS for Office365 In-Reply-To: References: Message-ID: <45318a2e-4991-4416-bfff-03e34b3f2aa3@www.fastmail.com> On Mon, Jul 8, 2019, at 18:15, Joe Yabuki wrote: > Hi all, > > How do you deal with QoS for Office365, since the IPs are subject to changes ? For "Classic QoS" : you don't. At best you tell the customer it's done without actually doing anything (it very often works). If it doesn't, see previous answers (those reccomending bandwidth upgrade and correct capacity provisioning a.k.a. "Modern QoS"). From mark.tinka at seacom.mu Tue Jul 9 06:25:34 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 9 Jul 2019 08:25:34 +0200 Subject: QoS for Office365 In-Reply-To: <12ce59cd1001ed4fa06968d702379c0e@mail.dessus.com> References: <12ce59cd1001ed4fa06968d702379c0e@mail.dessus.com> Message-ID: On 9/Jul/19 01:00, Keith Medcalf wrote: > Using Orifice 342 will hurt you. Can't choose what my customers like :-). Mark. From mark.tinka at seacom.mu Tue Jul 9 06:28:04 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 9 Jul 2019 08:28:04 +0200 Subject: QoS for Office365 In-Reply-To: <2112735119.362.1562632910837@mail.yahoo.com> References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <2112735119.362.1562632910837@mail.yahoo.com> Message-ID: To quote from that URL:     QoS only works as expected when implemented on all links between callers. If you use QoS     on an internal network and a user signs in from a remote location, you can only prioritize within     your internal, managed network. Mark. On 9/Jul/19 02:41, cyrus ramirez wrote: > Implement Quality of Service in Microsoft Teams > > > > > > > > > Implement Quality of Service in Microsoft Teams > > Prepare your organization's network for Quality of Service (QoS) in > Microsoft Teams. > > > > > > > > Sent from Yahoo Mail on Android > > > On Mon, Jul 8, 2019 at 12:47 PM, Mark Tinka > wrote: > > > On 8/Jul/19 18:18, Jared Mauch wrote: > > > > > Add bandwidth? > > > > QoS is a great tool when you’re constrained and must classify > your critical traffic, but it’s not a substitute of getting enough > capacity to offices. > > > > I have only applied QoS to voice traffic to ensure it gets > through, the rest you need to budget for the bandwidth needs of > the site.  The price of bandwidth likely isn’t insane in your > market, but your budget may be.. I’ve found that most places won’t > quote you a service for less than $1500 USD MRC.  I know you can > get the incumbents to often deliver 1G service for $2k/mo in the > US (and possibly cheaper). > > > > I’ve found a lot of people are still stuck in TDM mentality > instead of just getting a 1G/10G service. > > > In some cases, the motivation for these requirements is fueled by > trying > to outsmart your competitors. > > I just don't know of a reliable, contractual way that you can use > QoS to > say your DIA or IP Transit service is better than that of your > competitor. > > Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radevita at mejeticks.com Tue Jul 9 13:28:31 2019 From: radevita at mejeticks.com (Robert DeVita) Date: Tue, 9 Jul 2019 13:28:31 +0000 Subject: Google Fiber Message-ID: Does anyone have a sales contact at Google Fiber, looking for Dark fiber in Pflugerville, TX back to Datafoundry TX1 Thanks Rob [photo] [https://s3.amazonaws.com/images.wisestamp.com/symbols/frames/frame_bubble_left_top_part.png] Robert DeVita Managing Director, Mejeticks [https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/linkedin.png] [https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/twitter.png] [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/phone2.png] 214-305-2444 [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/mobile.png] 469-441-8864 [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/email1.png] radevita at mejeticks.com [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/website.png] www.mejeticks.com [https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/address1.png] 1919 McKinney Ave, Dallas, TX 75201 -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Tue Jul 9 13:43:14 2019 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 9 Jul 2019 09:43:14 -0400 Subject: Google Fiber In-Reply-To: References: Message-ID: 95% sure that Google Fiber only sells access, not point to point or wave services. On Tue, Jul 9, 2019 at 9:30 AM Robert DeVita wrote: > Does anyone have a sales contact at Google Fiber, looking for Dark fiber > in Pflugerville, TX back to Datafoundry TX1 > > > > Thanks > > > > Rob > > > > [image: photo] > > [image: > https://s3.amazonaws.com/images.wisestamp.com/symbols/frames/frame_bubble_left_top_part.png] > > Robert DeVita > Managing Director, Mejeticks > > [image: > https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/linkedin.png] > > > [image: https://dn3tzca2xtljm.cloudfront.net/social_icons/24px/twitter.png] > > > [image: > https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/phone2.png] > 214-305-2444 <214-305-2444> > > [image: > https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/mobile.png] > 469-441-8864 <469-441-8864> > > [image: > https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/email1.png] > radevita at mejeticks.com > > [image: > https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/website.png] > www.mejeticks.com > > [image: > https://s3.amazonaws.com/images.wisestamp.com/symbols/grey/small/address1.png] > 1919 McKinney Ave, Dallas, TX 75201 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Tue Jul 9 14:01:52 2019 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 9 Jul 2019 10:01:52 -0400 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> Message-ID: > > At a previous employer (AOL, doing VoIP for customer service / call > centers, ~2004) we had a number of contractual agreements with > multiple providers to honor our QoS markings -- as far as I could tell > (marking test traffic under congestion events) only one of about seven > did anything at all with the marking, and that wasn't enough to make > any difference... I briefly toyed with the idea of asking for some > money back / trying to enforce the terms of the agreements, but > figured that there wasn't much point - expecting QoS to work in > someone else's network based upon your markings seems like a fool's > errand. > Generally speaking, I agree that making QoS features work consistently on an external network you do not control is a fool's errand. But if that language was inserted into the contracts, and you can demonstrably prove it's not being done, enforcing contract terms should always be done. Depending on the strength of the remedy, could have been a lot of free service, enough financial incentive for them to MAKE it work correctly, or leverage to open renegotiations for more favorable terms for you. You know that in reverse they would have done the same to you. :) On Mon, Jul 8, 2019 at 6:38 PM Warren Kumari wrote: > On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka wrote: > > > > > > > > On 8/Jul/19 21:03, Robert Webb wrote: > > > I took the OP's request as for doing QoS at the edge of their network > > > and not necessarily the entire path. > > > > Indeed, but even then, you could be handing off the traffic to a > > downstream customer, and can't guarantee what they do to those ToS > fields. > > I disagree -- you *can* guarantee what someone else will do with your > ToS fields....... they will A: ignore them and / or B: scribble all > over them. > > At a previous employer (AOL, doing VoIP for customer service / call > centers, ~2004) we had a number of contractual agreements with > multiple providers to honor our QoS markings -- as far as I could tell > (marking test traffic under congestion events) only one of about seven > did anything at all with the marking, and that wasn't enough to make > any difference... I briefly toyed with the idea of asking for some > money back / trying to enforce the terms of the agreements, but > figured that there wasn't much point - expecting QoS to work in > someone else's network based upon your markings seems like a fool's > errand. > > W > > > > > > > > > > > As another person stated, the real answer is to add more bandwidth if > > > you are having to QoS to Office365 because it is affecting other > > > internet based services. > > > > Yes and no. > > > > More bandwidth never hurt anyone, but packet loss in the remote network > > toward the cloud will hurt you. > > > > Mark. > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Jul 9 14:05:42 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 9 Jul 2019 16:05:42 +0200 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> Message-ID: <9ef480cb-8a81-d7f3-9b1a-686730b08ec6@seacom.mu> On 9/Jul/19 16:01, Tom Beecher wrote: >   > > But if that language was inserted into the contracts, and you can > demonstrably prove it's not being done, enforcing contract terms > should always be done. Depending on the strength of the remedy, could > have been a lot of free service, enough financial incentive for them > to MAKE it work correctly, or leverage to open renegotiations for more > favorable terms for you. Perhaps plenty of service credits. Anything else would just burn too much time on either end for no practical outcome. Mark. From mark.tinka at seacom.mu Tue Jul 9 14:12:34 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 9 Jul 2019 16:12:34 +0200 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> <9ef480cb-8a81-d7f3-9b1a-686730b08ec6@seacom.mu> Message-ID: On 9/Jul/19 16:08, Joe Yabuki wrote: > Hi all, > > Thanks for your replies, > > I'll rephrase just to clarify, our aim is to do QoS within our > extended LAN (From remote sites to the Datacenter using the MPLS > provider as transit) - and we can't use DIA for a security reasons... > > So arguably, we still need to mark/queue/police packets at the Edge of > the Internet and on the remote site. For INTERNET we will throw > bandwidth so it will not be a point of congestion (hopefully once we > are in the Backbone's ISP we will go to Microsoft directly) In that case, co-ordinate the QoS profile with your MPLS provider and test both ends to make sure you receive what you send for on-net traffic. Verifying that your MPLS provider is forwarding your traffic according to the agreed-upon QoS profile is another thing. As for the off-net traffic entering your network, well, you know about that already... Mark. From saku at ytti.fi Tue Jul 9 14:16:52 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 9 Jul 2019 17:16:52 +0300 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> Message-ID: On Tue, 9 Jul 2019 at 17:05, Tom Beecher wrote: > Generally speaking, I agree that making QoS features work consistently on an external network you do not control is a fool's errand. > > But if that language was inserted into the contracts, and you can demonstrably prove it's not being done, enforcing contract terms should always be done. Depending on the strength of the remedy, could have been a lot of free service, enough financial incentive for them to MAKE it work correctly, or leverage to open renegotiations for more favorable terms for you. > > You know that in reverse they would have done the same to you. :) In previous life working with L3 MPLS VPN with deliveries far exceeding on-net size we bought access from partners and had QoS contracts in place, which were tested and enforced and they worked after some ironing during field trials. Usually contract was bidirectional, with partner also using our network for extending reach of their network, so both had incentive to offer working QoS with network-edge translation of marking. -- ++ytti From ross at tajvar.io Tue Jul 9 14:18:01 2019 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 9 Jul 2019 09:18:01 -0500 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> <9ef480cb-8a81-d7f3-9b1a-686730b08ec6@seacom.mu> Message-ID: I think the difficulty lies in appropriately marking the traffic. Like Joe said, the IPs are always changing. On Tue, Jul 9, 2019, 9:15 AM Mark Tinka wrote: > > > On 9/Jul/19 16:08, Joe Yabuki wrote: > > Hi all, > > > > Thanks for your replies, > > > > I'll rephrase just to clarify, our aim is to do QoS within our > > extended LAN (From remote sites to the Datacenter using the MPLS > > provider as transit) - and we can't use DIA for a security reasons... > > > > So arguably, we still need to mark/queue/police packets at the Edge of > > the Internet and on the remote site. For INTERNET we will throw > > bandwidth so it will not be a point of congestion (hopefully once we > > are in the Backbone's ISP we will go to Microsoft directly) > > In that case, co-ordinate the QoS profile with your MPLS provider and > test both ends to make sure you receive what you send for on-net traffic. > > Verifying that your MPLS provider is forwarding your traffic according > to the agreed-upon QoS profile is another thing. > > As for the off-net traffic entering your network, well, you know about > that already... > > Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Jul 9 14:19:48 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 9 Jul 2019 16:19:48 +0200 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> <9ef480cb-8a81-d7f3-9b1a-686730b08ec6@seacom.mu> Message-ID: On 9/Jul/19 16:18, Ross Tajvar wrote: > I think the difficulty lies in appropriately marking the traffic. Like > Joe said, the IPs are always changing. Does anyone know if they are reasonably static in an Express Route scenario? Mark. From lists.nanog at monmotha.net Tue Jul 9 14:23:05 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Tue, 9 Jul 2019 10:23:05 -0400 Subject: QoS for Office365 In-Reply-To: <032301d535c7$feb95320$fc2bf960$@netconsultings.com> References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <032301d535c7$feb95320$fc2bf960$@netconsultings.com> Message-ID: <31039610-a2e5-51df-23e9-4320bc659ff5@monmotha.net> On 7/8/19 4:01 PM, adamv0025 at netconsultings.com wrote: > And yet the SD-WAN promising MPLS experience over the internet and other BS sells like crazy;) To be fair, there are some folks who operate national or global big-I Internet IP networks that do guarantee QoS as long as you stay on their network. Most of them operate an MPLS, too, no surprise. Sprintlink is one that I know of. They tend to be on the expensive side when it comes to IP service. -- Brandon Martin From mark.tinka at seacom.mu Tue Jul 9 14:24:29 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 9 Jul 2019 16:24:29 +0200 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> Message-ID: <341d8644-580a-3fc2-dd60-60c34720fdf1@seacom.mu> On 9/Jul/19 16:16, Saku Ytti wrote: > In previous life working with L3 MPLS VPN with deliveries far > exceeding on-net size we bought access from partners and had QoS > contracts in place, which were tested and enforced and they worked > after some ironing during field trials. > Usually contract was bidirectional, with partner also using our > network for extending reach of their network, so both had incentive to > offer working QoS with network-edge translation of marking. I think when the partner participates in a private service, end-to-end, there's a higher chance things will work (which I believe is one of the components for Inter-AS l3vpn's and QoS). However, when part of the partner's offering is off-net (especially where off-net = public Internet), much less likely. Mark. From mark.tinka at seacom.mu Tue Jul 9 14:31:10 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 9 Jul 2019 16:31:10 +0200 Subject: QoS for Office365 In-Reply-To: <31039610-a2e5-51df-23e9-4320bc659ff5@monmotha.net> References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <032301d535c7$feb95320$fc2bf960$@netconsultings.com> <31039610-a2e5-51df-23e9-4320bc659ff5@monmotha.net> Message-ID: On 9/Jul/19 16:23, Brandon Martin wrote: >   > To be fair, there are some folks who operate national or global big-I > Internet IP networks that do guarantee QoS as long as you stay on > their network. Yes, which is the point... as long as the traffic is on-net, you can guarantee things. Large, global, transit-free backbones fair well in such scenarios as the majority of the traffic lives on-net as a matter of course. Mark. From valdis.kletnieks at vt.edu Tue Jul 9 14:37:50 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Tue, 09 Jul 2019 10:37:50 -0400 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> Message-ID: <17050.1562683070@turing-police> On Tue, 09 Jul 2019 17:16:52 +0300, Saku Ytti said: > In previous life working with L3 MPLS VPN with deliveries far > exceeding on-net size we bought access from partners and had QoS > contracts in place, which were tested and enforced and they worked > after some ironing during field trials. I'll bite. It's one thing to verify that no routers molested the QoS bits along the packet path. But how did you verify they "worked" as far as actually dropping packets off the correct flow (especially since if you have a high-priority QoS, the flow that loses may be some other customer's flow)? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From joeyabukiyin at gmail.com Tue Jul 9 14:08:08 2019 From: joeyabukiyin at gmail.com (Joe Yabuki) Date: Tue, 9 Jul 2019 16:08:08 +0200 Subject: QoS for Office365 In-Reply-To: <9ef480cb-8a81-d7f3-9b1a-686730b08ec6@seacom.mu> References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> <9ef480cb-8a81-d7f3-9b1a-686730b08ec6@seacom.mu> Message-ID: Hi all, Thanks for your replies, I'll rephrase just to clarify, our aim is to do QoS within our extended LAN (From remote sites to the Datacenter using the MPLS provider as transit) - and we can't use DIA for a security reasons... So arguably, we still need to mark/queue/police packets at the Edge of the Internet and on the remote site. For INTERNET we will throw bandwidth so it will not be a point of congestion (hopefully once we are in the Backbone's ISP we will go to Microsoft directly) Joe On Tue, Jul 9, 2019 at 4:06 PM Mark Tinka wrote: > > > On 9/Jul/19 16:01, Tom Beecher wrote: > > > > > > > But if that language was inserted into the contracts, and you can > > demonstrably prove it's not being done, enforcing contract terms > > should always be done. Depending on the strength of the remedy, could > > have been a lot of free service, enough financial incentive for them > > to MAKE it work correctly, or leverage to open renegotiations for more > > favorable terms for you. > > Perhaps plenty of service credits. Anything else would just burn too > much time on either end for no practical outcome. > > Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steve.Mikulasik at civeo.com Tue Jul 9 14:46:49 2019 From: Steve.Mikulasik at civeo.com (Steve Mikulasik) Date: Tue, 9 Jul 2019 14:46:49 +0000 Subject: QoS for Office365 In-Reply-To: <8880b0c0-1013-fda6-bd51-7be607344e0f@seacom.mu> References: <8880b0c0-1013-fda6-bd51-7be607344e0f@seacom.mu> Message-ID: Even if QoS on the Internet was possible it would be destroyed by everyone marking all their traffic with the highest priority to get the best performance. Tragedy of the commons. -----Original Message----- From: NANOG On Behalf Of Mark Tinka Sent: Monday, July 8, 2019 10:40 AM To: nanog at nanog.org Subject: Re: QoS for Office365 On 2/Jul/19 23:18, Joe Yabuki wrote: > Hi all, > > How do you deal with QoS for Office365, since the IPs are subject to > changes ? > > How can we mark the trafic while keeping the security (I fear the > marking based on TCP/UDP Ports since they are not without an > additional risk coming from worms/virus using those ports for example, > and doing that directly on the PCs doesn't seem to be the best solution) ? Funny, I was just answering an internal question about this, last week. As with all things Internet, my stance is if you don't have end-to-end control, trying to do QoS is pointless. That said, I believe it should be possible to apply some kind of meaningful, end-to-end QoS together with Microsoft if you took up one of their Express Route services, given that is considered a private, premium service. Mark. From mark.tinka at seacom.mu Tue Jul 9 14:48:29 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 9 Jul 2019 16:48:29 +0200 Subject: QoS for Office365 In-Reply-To: <17050.1562683070@turing-police> References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> <17050.1562683070@turing-police> Message-ID: On 9/Jul/19 16:37, Valdis Kl ē tnieks wrote: > I'll bite. > > It's one thing to verify that no routers molested the QoS bits along the > packet path. > > But how did you verify they "worked" as far as actually dropping packets off > the correct flow (especially since if you have a high-priority QoS, the flow that > loses may be some other customer's flow)? With some things, you need to have faith until you are given a reason not to. Just like when you are back in 26K and the Captain and his First Officer are up front :-). Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From mark.tinka at seacom.mu Tue Jul 9 14:50:23 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 9 Jul 2019 16:50:23 +0200 Subject: QoS for Office365 In-Reply-To: References: <8880b0c0-1013-fda6-bd51-7be607344e0f@seacom.mu> Message-ID: <6d3ea846-f39e-d51f-370f-99c46fd84324@seacom.mu> On 9/Jul/19 16:46, Steve Mikulasik wrote: > Even if QoS on the Internet was possible it would be destroyed by everyone marking all their traffic with the highest priority to get the best performance. Tragedy of the commons. I kind of like the Internet the way it is. The best-effort nature is what allows us to build it in a way that makes it a viable option for global data transport. If all paths on the Internet had to be high-priority, I doubt it'd be a viable project outside of a monopoly or duopoly. Mark. From joelja at bogus.com Tue Jul 9 15:06:38 2019 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 9 Jul 2019 08:06:38 -0700 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> <9ef480cb-8a81-d7f3-9b1a-686730b08ec6@seacom.mu> Message-ID: <434C8312-3FF0-46B1-83DC-D24A527977DE@bogus.com> > On Jul 9, 2019, at 07:19, Mark Tinka wrote: > > > > On 9/Jul/19 16:18, Ross Tajvar wrote: >> I think the difficulty lies in appropriately marking the traffic. Like >> Joe said, the IPs are always changing. > > Does anyone know if they are reasonably static in an Express Route scenario? Express route peering with 12076 gives you more specific routes then you would otherwise see from 8075 (a /13 becomes a bunch of 17s etc) . it also gives you control over what region / application is exported to you. My early experience as a customer with it was that there was on RPF check that I found to be a problem as a multihomed network. > > Mark. > From saku at ytti.fi Tue Jul 9 15:07:06 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 9 Jul 2019 18:07:06 +0300 Subject: QoS for Office365 In-Reply-To: <17050.1562683070@turing-police> References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> <17050.1562683070@turing-police> Message-ID: On Tue, 9 Jul 2019 at 17:37, Valdis Klētnieks wrote: > But how did you verify they "worked" as far as actually dropping packets off > the correct flow (especially since if you have a high-priority QoS, the flow that > loses may be some other customer's flow)? By congesting queues and verifying expectations to results. -- ++ytti From beecher at beecher.cc Tue Jul 9 15:07:28 2019 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 9 Jul 2019 11:07:28 -0400 Subject: QoS for Office365 In-Reply-To: References: <8880b0c0-1013-fda6-bd51-7be607344e0f@seacom.mu> Message-ID: That's already been happening. OpenSSH pulled that stunt in 7.8. https://www.openssh.com/txt/release-7.8 ssh(1)/sshd(8): the default IPQoS used by ssh/sshd has changed. They will now use DSCP AF21 for interactive traffic and CS1 for bulk. For a detailed rationale, please see the commit message: https://cvsweb.openbsd.org/src/usr.bin/ssh/readconf.c#rev1.284 On Tue, Jul 9, 2019 at 10:50 AM Steve Mikulasik via NANOG wrote: > Even if QoS on the Internet was possible it would be destroyed by everyone > marking all their traffic with the highest priority to get the best > performance. Tragedy of the commons. > > > > -----Original Message----- > From: NANOG On Behalf Of Mark Tinka > Sent: Monday, July 8, 2019 10:40 AM > To: nanog at nanog.org > Subject: Re: QoS for Office365 > > > > On 2/Jul/19 23:18, Joe Yabuki wrote: > > > Hi all, > > > > How do you deal with QoS for Office365, since the IPs are subject to > > changes ? > > > > How can we mark the trafic while keeping the security (I fear the > > marking based on TCP/UDP Ports since they are not without an > > additional risk coming from worms/virus using those ports for example, > > and doing that directly on the PCs doesn't seem to be the best solution) > ? > > Funny, I was just answering an internal question about this, last week. > > As with all things Internet, my stance is if you don't have end-to-end > control, trying to do QoS is pointless. > > That said, I believe it should be possible to apply some kind of > meaningful, end-to-end QoS together with Microsoft if you took up one of > their Express Route services, given that is considered a private, premium > service. > > Mark. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igoldstein at telego.net Tue Jul 9 14:51:49 2019 From: igoldstein at telego.net (Izzy Goldstein - TeleGo) Date: Tue, 9 Jul 2019 10:51:49 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: Message-ID: back on track to stir/shaken would a service provider also need to implement this? or its for the big carriers to do ? On Mon, Jul 8, 2019 at 11:17 PM Michael Thomas wrote: > > On 7/8/19 7:11 PM, Christopher Morrow wrote: > > when do we get back to stir/shaken? > > that would be nice. i have a lot of questions about stir/shaken. > attacking a problem statement rfc seems rather bizarre and unhinged to > me. it outlines a lot of the objections i had to p-asserted-identity i > had way back when. > > Mike > > -- Izzy Goldstein Chief Technology Officer Main: (212) 477-1000 x 2085 <(212)%20477-1000> Direct: (929) 477-2085 Website: www.telego.com Confidentiality Notice: This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error please notify us immediately by email reply and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of TeleGo (T). Employees of TeleGo are expressly required not to make defamatory statements and not to infringe or authorize any infringement of copyright or any other legal right by email communications. Any such communication is contrary to TeleGo policy and outside the scope of the employment of the individual concerned. TeleGo will not accept any liability in respect of such communication, and the employee responsible will be personally liable for any damages or other liability arising. TeleGo Hosted PBX -------------- next part -------------- An HTML attachment was scrubbed... URL: From saku at ytti.fi Tue Jul 9 15:22:29 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 9 Jul 2019 18:22:29 +0300 Subject: QoS for Office365 In-Reply-To: References: <8880b0c0-1013-fda6-bd51-7be607344e0f@seacom.mu> Message-ID: Hey Tom > That's already been happening. OpenSSH pulled that stunt in 7.8. OpenSSH always coloured interactive and non-interactive SSH. They just used original TOS definition, which no one has used in the field, not in the last 20 years at any rate. And which devices actually cannot even match for (They can match PREC, DSCP definition of TOS, not original). But it took some time of convincing OpenSSH people that reading original RFC isn't going to give sufficient understanding of how TOS is used in real network. I applaud this change. In home use your WIFI actually does honour QoS and many enterprise networks do. And they mostly will align with this default. So it's good default. Home user internet experience would be vastly superior if WAN would also do some rudimentary QoS, one silver bullet is to prioritise small packets during congestion. Makes so much better experience on people who regularly have their WAN uplink congested. Sadly not widely done and impossible in most cases to do for NET=>Customer direction. Would be terrific if CPE could tell far-end what QoS policy to use, so residential users could decide on their end the far end QoS config. -- ++ytti From jnford at uiowa.net Tue Jul 9 15:27:09 2019 From: jnford at uiowa.net (Jay Ford) Date: Tue, 9 Jul 2019 10:27:09 -0500 (CDT) Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> <9ef480cb-8a81-d7f3-9b1a-686730b08ec6@seacom.mu> Message-ID: On Tue, 9 Jul 2019, Mark Tinka wrote: > On 9/Jul/19 16:18, Ross Tajvar wrote: >> I think the difficulty lies in appropriately marking the traffic. Like >> Joe said, the IPs are always changing. > > Does anyone know if they are reasonably static in an Express Route scenario? At least sometimes M$ says that Express Route is just for Azure, not for Orifice 365. It's even possible that using Express Route for O365 could be worse due to undermining/bypassing some of the O365 availability mechanisms. __________________________________________________________________________ Jay Ford , Network Engineering, University of Iowa From nchabbey at n3network.ch Tue Jul 9 15:35:16 2019 From: nchabbey at n3network.ch (Nicolas Chabbey) Date: Tue, 9 Jul 2019 17:35:16 +0200 Subject: rVRRPd - A new open source VRRPv2 daemon Message-ID: <88fd842f-21a9-c894-0cdf-b6cc473535e4@n3network.ch> Hello, I released the first major version of rVRRPd, an open source and RFC3768-compliant VRRPv2 daemon. It actually only supports Linux but I will soon be adding support for additional operating systems and platforms. rVRRPd was born from my desire to develop skills in system development. I also wanted to provide another open and secure implementation of a FHRP to the network community. Here's a summary of what rVRRPd (v0.1.0) is: - Implemented almost entirely in Rust - Interoperable with RFC3768 compliant devices - Support for RFC2338 simple password authentication - Support for additional proprietary authentication methods - Easily configurable using TOML - Multithreaded operations - Fast, secure and scalable This implementation is aimed to be fast and secure, however please keep in mind, it is still in its infancy. It is not yet ready for production use but should be fairly stable. I'm the only developer at this time, and my resources are limited. However, I took the time to fuzz the latest version, and to do some interoperability testing. So far, the results have been great. Of course, I'm open to any suggestions and feedback. Anything that can improve the project constructively is more than welcome. I am also open to contributors. You can find the latest development version of rVRRPd at https://github.com/e3prom/rVRRPd Regards -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From beecher at beecher.cc Tue Jul 9 15:50:19 2019 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 9 Jul 2019 11:50:19 -0400 Subject: QoS for Office365 In-Reply-To: References: <8880b0c0-1013-fda6-bd51-7be607344e0f@seacom.mu> Message-ID: I respectfully just don't agree on that. In my view, software should default to not setting those bits to anything by default, but should have configuration options that allow them to be set if required. Every network is different, and making assumptions based on RFC SHOULD's is an unfortunate choice. On Tue, Jul 9, 2019 at 11:22 AM Saku Ytti wrote: > Hey Tom > > > That's already been happening. OpenSSH pulled that stunt in 7.8. > > OpenSSH always coloured interactive and non-interactive SSH. They just > used original TOS definition, which no one has used in the field, not > in the last 20 years at any rate. And which devices actually cannot > even match for (They can match PREC, DSCP definition of TOS, not > original). But it took some time of convincing OpenSSH people that > reading original RFC isn't going to give sufficient understanding of > how TOS is used in real network. > > I applaud this change. In home use your WIFI actually does honour QoS > and many enterprise networks do. And they mostly will align with this > default. So it's good default. > > Home user internet experience would be vastly superior if WAN would > also do some rudimentary QoS, one silver bullet is to prioritise small > packets during congestion. Makes so much better experience on people > who regularly have their WAN uplink congested. Sadly not widely done > and impossible in most cases to do for NET=>Customer direction. Would > be terrific if CPE could tell far-end what QoS policy to use, so > residential users could decide on their end the far end QoS config. > > -- > ++ytti > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at prt.org Tue Jul 9 15:53:47 2019 From: paul at prt.org (Paul Thornton) Date: Tue, 9 Jul 2019 16:53:47 +0100 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> <9ef480cb-8a81-d7f3-9b1a-686730b08ec6@seacom.mu> Message-ID: <70ef1433-d5d0-da2e-cb89-77f3d5af648e@prt.org> On 09/07/2019 16:27, Jay Ford wrote: > On Tue, 9 Jul 2019, Mark Tinka wrote: >> On 9/Jul/19 16:18, Ross Tajvar wrote: >>> I think the difficulty lies in appropriately marking the traffic. Like >>> Joe said, the IPs are always changing. >> >> Does anyone know if they are reasonably static in an Express Route >> scenario? > > At least sometimes M$ says that Express Route is just for Azure, not for > Orifice 365. It's even possible that using Express Route for O365 could > be worse due to undermining/bypassing some of the O365 availability > mechanisms. I've just been involved in turning up a new customer who ordered Express Route specifically for O365 use - they have no Azure presence. After much discussions between us, the customer and MS it transpired that they (MS) really didn't want to support using Express Routes and O365 - there had been many instances of routing problems and people not really understanding what the end result was going to look like. Apologies for being vague here, but I wasn't directly in the loop - except to say that MS dissuaded the customer from this and told them to just use their Internet connection instead. The MS techs told us that this was their preferred option now. A year or two back, they wanted everyone to access O365 via Express Route... Paul. From saku at ytti.fi Tue Jul 9 16:19:00 2019 From: saku at ytti.fi (Saku Ytti) Date: Tue, 9 Jul 2019 19:19:00 +0300 Subject: QoS for Office365 In-Reply-To: References: <8880b0c0-1013-fda6-bd51-7be607344e0f@seacom.mu> Message-ID: On Tue, 9 Jul 2019 at 18:50, Tom Beecher wrote: > I respectfully just don't agree on that. In my view, software should default to not setting those bits to anything by default, but should have configuration options that allow them to be set if required. Every network is different, and making assumptions based on RFC SHOULD's is an unfortunate choice. You are entitled to that opinion, I just wanted to correct you that this is not a change in OpenSSH behaviour from your point of view, just different bits. For you it's business as usual. I don't anticipate Internet users in general to be capable of configuring QoS and I think they deserve reasonable defaults, and those who understand what they want, can change those defaults. The WLAN AP you shop from typical provider has QoS built-in, and it works reasonably, with reasonable definition. I wish we'd take it further, and give reasonable last mile QoS to consumer, the 'small packets first in congestion' would on average increase user experience significantly. -- ++ytti From mark.tinka at seacom.mu Tue Jul 9 16:31:56 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 9 Jul 2019 18:31:56 +0200 Subject: QoS for Office365 In-Reply-To: <434C8312-3FF0-46B1-83DC-D24A527977DE@bogus.com> References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> <9ef480cb-8a81-d7f3-9b1a-686730b08ec6@seacom.mu> <434C8312-3FF0-46B1-83DC-D24A527977DE@bogus.com> Message-ID: On 9/Jul/19 17:06, Joel Jaeggli wrote: > Express route peering with 12076 gives you more specific routes then you would otherwise see from 8075 (a /13 becomes a bunch of 17s etc) . it also gives you control over what region / application is exported to you. As I had assumed. But of course, you'd pay for that private service :-). Mark. From beecher at beecher.cc Tue Jul 9 16:55:41 2019 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 9 Jul 2019 12:55:41 -0400 Subject: QoS for Office365 In-Reply-To: References: <8880b0c0-1013-fda6-bd51-7be607344e0f@seacom.mu> Message-ID: I looked back into work email from back then and I see where I made my mistake. I had misread the 7.4 change where they added the option for allow IPQoS=none , apparently my brain just skipped the word 'option', and it stuck in my brain as the default behavior being 'none'. That's embarrassing, thank you for correcting me. On Tue, Jul 9, 2019 at 12:19 PM Saku Ytti wrote: > On Tue, 9 Jul 2019 at 18:50, Tom Beecher wrote: > > > I respectfully just don't agree on that. In my view, software should > default to not setting those bits to anything by default, but should have > configuration options that allow them to be set if required. Every network > is different, and making assumptions based on RFC SHOULD's is an > unfortunate choice. > > You are entitled to that opinion, I just wanted to correct you that > this is not a change in OpenSSH behaviour from your point of view, > just different bits. For you it's business as usual. > > I don't anticipate Internet users in general to be capable of > configuring QoS and I think they deserve reasonable defaults, and > those who understand what they want, can change those defaults. The > WLAN AP you shop from typical provider has QoS built-in, and it works > reasonably, with reasonable definition. > I wish we'd take it further, and give reasonable last mile QoS to > consumer, the 'small packets first in congestion' would on average > increase user experience significantly. > > -- > ++ytti > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ed at edgeoc.net Tue Jul 9 16:27:01 2019 From: ed at edgeoc.net (Edward Salonia) Date: Tue, 9 Jul 2019 12:27:01 -0400 Subject: QoS for Office365 In-Reply-To: References: Message-ID: Have you looked into Cisco’s SD-AVC? Also with the o365 connector? https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/avc/sd-avc/2-1-0/ug/sd-avc-2-1-0-ug.pdf On Jul 2, 2019, at 17:18, Joe Yabuki wrote: Hi all, How do you deal with QoS for Office365, since the IPs are subject to changes ? How can we mark the trafic while keeping the security (I fear the marking based on TCP/UDP Ports since they are not without an additional risk coming from worms/virus using those ports for example, and doing that directly on the PCs doesn't seem to be the best solution) ? Many thanks, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Tue Jul 9 17:36:33 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 9 Jul 2019 13:36:33 -0400 (EDT) Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: Message-ID: The agenda for the SHAKEN/STIR robocall summit was published today. Date: Thursday, July 11, 2019 Time: 9:30 a.m. to 3:30 p.m. Location: Commission Meeting Room at FCC Headquarters It will also be live-streamed on the FCC web site. https://www.fcc.gov/document/chairman-pai-announces-agenda-shakenstir-robocall-summit The agenda looks like lots of happy, happy talk from industry representatives. Unfortunately, like other third-party problems, its not about the technology. Its really about changing the incentives for all the actors involved. But the first and second-party players don't want the incentives to be changed for them. From warren at kumari.net Tue Jul 9 17:48:00 2019 From: warren at kumari.net (Warren Kumari) Date: Tue, 9 Jul 2019 13:48:00 -0400 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> Message-ID: On Tue, Jul 9, 2019 at 10:02 AM Tom Beecher wrote: >> >> At a previous employer (AOL, doing VoIP for customer service / call >> centers, ~2004) we had a number of contractual agreements with >> multiple providers to honor our QoS markings -- as far as I could tell >> (marking test traffic under congestion events) only one of about seven >> did anything at all with the marking, and that wasn't enough to make >> any difference... I briefly toyed with the idea of asking for some >> money back / trying to enforce the terms of the agreements, but >> figured that there wasn't much point - expecting QoS to work in >> someone else's network based upon your markings seems like a fool's >> errand. > > > Generally speaking, I agree that making QoS features work consistently on an external network you do not control is a fool's errand. > > But if that language was inserted into the contracts, and you can demonstrably prove it's not being done, enforcing contract terms should always be done. Depending on the strength of the remedy, could have been a lot of free service, enough financial incentive for them to MAKE it work correctly, or leverage to open renegotiations for more favorable terms for you. > > You know that in reverse they would have done the same to you. :) > Yeah, at that point in AOL's trajectory there were (at least from my point of view!) much much bigger issues -- like, "Who's getting laid off this week? and how do I remove their access? and who's going to do whatever they were doing (if anything)?!" and trying to make enhanced cRTP work over GRE over yet more GRE over IPSEC (because, well, reasons). Yes, in an ideal world we would have received some sort of credits -- but then again, in an ideal world, I wouldn't have been trying to run VOIP over cRTP over GRE over GRE over IPSEC over DS3 to E3 converters to India... W > On Mon, Jul 8, 2019 at 6:38 PM Warren Kumari wrote: >> >> On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka wrote: >> > >> > >> > >> > On 8/Jul/19 21:03, Robert Webb wrote: >> > > I took the OP's request as for doing QoS at the edge of their network >> > > and not necessarily the entire path. >> > >> > Indeed, but even then, you could be handing off the traffic to a >> > downstream customer, and can't guarantee what they do to those ToS fields. >> >> I disagree -- you *can* guarantee what someone else will do with your >> ToS fields....... they will A: ignore them and / or B: scribble all >> over them. >> >> At a previous employer (AOL, doing VoIP for customer service / call >> centers, ~2004) we had a number of contractual agreements with >> multiple providers to honor our QoS markings -- as far as I could tell >> (marking test traffic under congestion events) only one of about seven >> did anything at all with the marking, and that wasn't enough to make >> any difference... I briefly toyed with the idea of asking for some >> money back / trying to enforce the terms of the agreements, but >> figured that there wasn't much point - expecting QoS to work in >> someone else's network based upon your markings seems like a fool's >> errand. >> >> W >> >> > >> > >> > > >> > > As another person stated, the real answer is to add more bandwidth if >> > > you are having to QoS to Office365 because it is affecting other >> > > internet based services. >> > >> > Yes and no. >> > >> > More bandwidth never hurt anyone, but packet loss in the remote network >> > toward the cloud will hurt you. >> > >> > Mark. >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From ml at knight-networks.com Wed Jul 10 00:58:54 2019 From: ml at knight-networks.com (Brian Knight) Date: Tue, 9 Jul 2019 19:58:54 -0500 Subject: QoS for Office365 In-Reply-To: References: <74D5E80E-6AB7-42D2-A04A-A77A2FC1BF1F@puck.nether.net> <836c4a86-df70-f2f4-9f16-f47a8f332870@seacom.mu> <148ea27d-06f0-7c56-14ba-c98ea4f3df0e@seacom.mu> <9ef480cb-8a81-d7f3-9b1a-686730b08ec6@seacom.mu> Message-ID: > On Jul 9, 2019, at 9:19 AM, Mark Tinka wrote: > > > >> On 9/Jul/19 16:18, Ross Tajvar wrote: >> I think the difficulty lies in appropriately marking the traffic. Like >> Joe said, the IPs are always changing. > > Does anyone know if they are reasonably static in an Express Route scenario? > > Mark. Yes, the IPs used on the ExpressRoute connection are whatever is chosen for the internal IP scheme of the VPC. ExpressRoute is a VPN connection into that internal side of a VPC. On our carrier (MegaPort), ExpressRoute looks similar to an Option A NNI connection. BGP is used for routing. The source IPs on packets crossing out of the VPC onto the Azure-provided Internet may or may not be static, but internally they are usually static RFC 1918 addresses. We’ve been using ExpressRoute for our own office systems and a small handful of customers for about two years now. However, we don’t use diffserv on ExpressRoute, so can’t comment on that. -Brian From dwessels at verisign.com Wed Jul 10 02:11:20 2019 From: dwessels at verisign.com (Wessels, Duane) Date: Wed, 10 Jul 2019 02:11:20 +0000 Subject: .NET Zone DNSSEC Operational Update -- ZSK length change Message-ID: <49A9FFD6-9C4B-4932-8485-52D8FA021B7F@verisign.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All, Verisign is in the process of increasing the size and strength of the DNSSEC Zone Signing Keys (ZSKs) for the top-level domains that it operates. As part of this process, the ZSK for the .NET zone will be increased in size from 1024 to 1280 bits. On July 10, 2019 the 1280 bit ZSK will be pre-published in the .NET zone. On July 15, the .NET zone will be signed with the 1280 bit ZSK. On July 20, the 1024 bit ZSK will be removed from the zone. We do not anticipate any problems from this upgrade. In accordance with our normal operating procedures we have a rollback process should it become necessary to revert to the 1024 bit ZSK. DW -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJdJQifAAoJEGyZpGmowJiNVEsH/2T8Qm/ZZiM7K1G+6XN4wMSR oqyuzY/0AiqXpw0C2aL3sE3VhYPZWTY+H5wwbvU+ZoAbiMfcOygBv/JTLizpjLLK NJD+Gh51Z6cQn5yk9cPjRtoxdQrV83T0gRQIlPeFW3sm9GrXgropfQ/Dw7O0lHkZ x2oiGwC0HF5npi6OWEHpETemtSMWl5HpFfmYZhzXoBSzEbzHgXQwr0Fie9wtNkDm qPjwaeq3drENOoum4egpAFxQZM7FclLtyqqT24h0m5GeunHIcXRRcfoOAEnEmjRJ b5ePCKxHqNY2Iz6MpiedTCpD2RIbI51wVhNGfmCiwyyl3500oqjvcmtYh00gCIU= =XP9d -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4675 bytes Desc: not available URL: From dwessels at verisign.com Wed Jul 10 02:12:51 2019 From: dwessels at verisign.com (Wessels, Duane) Date: Wed, 10 Jul 2019 02:12:51 +0000 Subject: .ARPA Zone DNSSEC Operational Update -- ZSK length change Message-ID: <2B25582F-9F1F-4359-873B-3A2C1AA3964E@verisign.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All, Verisign is in the process of increasing the size and strength of the DNSSEC Zone Signing Keys (ZSKs) for the top-level domains that it operates. As part of this process, the ZSK for the .ARPA zone will be increased in size from 1024 to 2048 bits. On July 11, 2019 the 2048 bit ZSK will be pre-published in the .ARPA zone. On July 21, the .ARPA zone will be signed with the 2048 bit ZSK. On August 10, the 1024 bit ZSK will be removed from the zone. We do not anticipate any problems from this upgrade. In accordance with our normal operating procedures we have a rollback process should it become necessary to revert to the 1024 bit ZSK. DW -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJdJQifAAoJEGyZpGmowJiNxjcH/3a+ox9KyGAT5vnrcxfEYYIQ X2iQ0dSEBCv9JPNwTnKkV2U2xzG3uZb6LHjq9tihtA4M04IaMvlLnZMUFUyGgzrl ACvn6j9qCE0q7sgDGo/RNWXBsAd58mKgBVMMRCBR6AklDHVA+grEH2CwDwP0eGYZ 8dy6Cf94jqXqiVDQIxoK31YhYFqNVRhZE4f72V+6lh1fg4GrsfXKeErYwQooxdYT 91H9TmffWmEpG+eYdgWMOPPS+nsrDr/MAuSVD0t5hT8H/HrCo45MNxxskmwLg0Ni QAHgy5Ao2jgJj6MkzZdwjldM8mn5YzMegiHUF9R5W5TRlnNm7uGTU32Irzu7b/8= =lJK6 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4675 bytes Desc: not available URL: From mjo at dojo.mi.org Tue Jul 9 23:26:35 2019 From: mjo at dojo.mi.org (Mike O'Connor) Date: Tue, 9 Jul 2019 19:26:35 -0400 Subject: QoS for Office365 In-Reply-To: References: Message-ID: <20190709232635.ns75ydl2v7czu7wv@dojo.mi.org> :How do you deal with QoS for Office365, since the IPs are subject to changes ? How often is the data in: https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-service out of date? -Mike -- Michael J. O'Connor mjo at dojo.mi.org =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "Nothing unreal exists." -Kiri-Kin-Tha's First Law Of Metaphysics -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From marka at isc.org Wed Jul 10 03:57:46 2019 From: marka at isc.org (Mark Andrews) Date: Wed, 10 Jul 2019 13:57:46 +1000 Subject: QoS for Office365 In-Reply-To: References: <8880b0c0-1013-fda6-bd51-7be607344e0f@seacom.mu> Message-ID: <2F732EC4-AF5C-448D-8E73-29D928344E74@isc.org> That’s why you do QoS between the customer’s packets not every packet. > On 10 Jul 2019, at 12:46 am, Steve Mikulasik via NANOG wrote: > > Even if QoS on the Internet was possible it would be destroyed by everyone marking all their traffic with the highest priority to get the best performance. Tragedy of the commons. > > > > -----Original Message----- > From: NANOG On Behalf Of Mark Tinka > Sent: Monday, July 8, 2019 10:40 AM > To: nanog at nanog.org > Subject: Re: QoS for Office365 > > > > On 2/Jul/19 23:18, Joe Yabuki wrote: > >> Hi all, >> >> How do you deal with QoS for Office365, since the IPs are subject to >> changes ? >> >> How can we mark the trafic while keeping the security (I fear the >> marking based on TCP/UDP Ports since they are not without an >> additional risk coming from worms/virus using those ports for example, >> and doing that directly on the PCs doesn't seem to be the best solution) ? > > Funny, I was just answering an internal question about this, last week. > > As with all things Internet, my stance is if you don't have end-to-end control, trying to do QoS is pointless. > > That said, I believe it should be possible to apply some kind of meaningful, end-to-end QoS together with Microsoft if you took up one of their Express Route services, given that is considered a private, premium service. > > Mark. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From arnold at nipper.de Wed Jul 10 09:06:14 2019 From: arnold at nipper.de (Arnold Nipper) Date: Wed, 10 Jul 2019 11:06:14 +0200 Subject: [Reminder] [FYI] Call for Presentations European Peering Forum 14 (EPF14) // NANOG In-Reply-To: References: Message-ID: Dear Community we have extended the Deadlines ========= Presentation Abstract Deadline 29/07/2019 12:00 UTC Final Selection of Speakers 09/08/2019 Presentation Slides Submission Deadline 02/09/2019 12:00 UTC Best regards Arnold On 23.04.2019 23:31, Arnold Nipper wrote: > Dear Community > > This is the Call for Presentations European Peering Forum 14 (EPF14) > > AMS-IX, DE-CIX, LINX and Netnod are happy to host the 14th European > Peering Forum (EPF) in Tallinn, Estonia from the 16th - 18th > September 2019. 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 address > * Presentation title > * Abstract > * Slides (if available) > * Time requested (max. 30 minutes incl. Q&A) > > > Deadlines > ========= > > Presentation Abstract Deadline 15/07/2019 12:00 UTC > Final Selection of Speakers 26/07/2019 > Presentation Slides Submission Deadline 02/09/2019 12:00 UTC > > > More information about the event and other activities around EPF14 > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From rsk at gsp.org Wed Jul 10 12:35:30 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 10 Jul 2019 08:35:30 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <3a7a0f7232773840871f3d63267435b1@mail.dessus.com> References: <6fb05c87-477d-a329-ee74-dbf1ad4267fa@mtcc.com> <3a7a0f7232773840871f3d63267435b1@mail.dessus.com> Message-ID: <20190710123530.GA22800@gsp.org> On Mon, Jul 08, 2019 at 06:54:51PM -0600, Keith Medcalf wrote: > This is because DKIM was a solution to a problem that did not exist. This is correct. We have always known the IP address of the connecting MTA, therefore we have always known the network it resides in, therefore we have always known who is responsible for what transits that connection. Worse, this (poorly) attempts to wallpaper over the problems of compromised systems/accounts. Do recall that not long ago we learned that EVERY Yahoo account was compromised. Anyone who thinks that Microsoft or Google or Comcast or anyone else are doing any better is naive: it's not a question of whether they've also suffered mass compromises, only a question of how many and when they'll publicly admit it. This isn't surprising. The real underlying problems here are tough and expensive, thus it's far easire to do (nearly) meaningless feel-good work, declare the problems solved, and engage in a round of self-congratulation. It *appears*, and that's a preliminary assessment on my part, that SHAKEN/STIR is following this same track. ---rsk From ecdhe at protonmail.ch Tue Jul 9 17:30:56 2019 From: ecdhe at protonmail.ch (ecdhe) Date: Tue, 09 Jul 2019 17:30:56 +0000 Subject: Looking for a knowledgeable Level3 and GTT off-list contact Message-ID: <-jg_pVlBrixfXIyHOS1_PYdHEM3iKyAzVkFTOorxNqN5_8vDZttK0n4cIaPQCH_XifzfljzzVKBOjxgD3-LbYi3Mv2vtkB3e4FOIfHHI6J4=@protonmail.ch> Some of your resources are being used for organized crime and attacks (but not originating from your network). I would appreciate an off-list contact if anyone knows of one. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikebolitho at gmail.com Wed Jul 10 14:11:00 2019 From: mikebolitho at gmail.com (Mike Bolitho) Date: Wed, 10 Jul 2019 07:11:00 -0700 Subject: Looking for a knowledgeable Level3 and GTT off-list contact In-Reply-To: <-jg_pVlBrixfXIyHOS1_PYdHEM3iKyAzVkFTOorxNqN5_8vDZttK0n4cIaPQCH_XifzfljzzVKBOjxgD3-LbYi3Mv2vtkB3e4FOIfHHI6J4=@protonmail.ch> References: <-jg_pVlBrixfXIyHOS1_PYdHEM3iKyAzVkFTOorxNqN5_8vDZttK0n4cIaPQCH_XifzfljzzVKBOjxgD3-LbYi3Mv2vtkB3e4FOIfHHI6J4=@protonmail.ch> Message-ID: They're not going to do anything unless there is a warrant, especially considering that it's not a customer of theirs. Of course "illegal" traffic is going to flow over Tier I equipment, public internet is public internet. - Mike Bolitho On Wed, Jul 10, 2019 at 6:30 AM ecdhe via NANOG wrote: > Some of your resources are being used for organized crime and attacks (but > not originating from your network). > > I would appreciate an off-list contact if anyone knows of one. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhm at ufl.edu Wed Jul 10 15:22:14 2019 From: bhm at ufl.edu (Bruce H McIntosh) Date: Wed, 10 Jul 2019 11:22:14 -0400 Subject: CenturyLink/Level3 feedback In-Reply-To: <3ae63f9a-6fba-a071-be3e-89c17ac355a0@seacom.mu> References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> <20190705191013.GU29202@tamriel.snowman.net> <3ae63f9a-6fba-a071-be3e-89c17ac355a0@seacom.mu> Message-ID: <92781b46-6e63-d650-30a4-290efed1a3ea@ufl.edu> We run a network over dark fiber originally gotten from Level3. Some of the fiber they provided us they were getting from CL (formerly Qwest). Since L3 was the CL customer, not us, we needed L3 to escort us for access to our equipment in several sites. Now that everyone's one big happy CL family, we're now CenturyLink customers. It'd be really nice if they could get their site access and security systems merged so that we don't need to call CL for a CL escort to a CL site. -- -------------------------------------------- Bruce H. McIntosh Network Engineer II University of Florida Information Technology bhm at ufl.edu 352-273-1066 From ccummings at coeur.com Wed Jul 10 15:51:22 2019 From: ccummings at coeur.com (Cummings, Chris) Date: Wed, 10 Jul 2019 15:51:22 +0000 Subject: CenturyLink/Level3 feedback In-Reply-To: <92781b46-6e63-d650-30a4-290efed1a3ea@ufl.edu> References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> <20190705191013.GU29202@tamriel.snowman.net> <3ae63f9a-6fba-a071-be3e-89c17ac355a0@seacom.mu> <92781b46-6e63-d650-30a4-290efed1a3ea@ufl.edu> Message-ID: I was always taught that “if you can't say anything nice, don't say nothing at all”—That being said, my last CenturyLink turnup was worse than my last AT&T turnup. Take that for what it is worth. /chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlm at pixelgate.net Wed Jul 10 17:37:57 2019 From: mlm at pixelgate.net (Mark Milhollan) Date: Wed, 10 Jul 2019 10:37:57 -0700 (PDT) Subject: QoS for Office365 In-Reply-To: <20190709232635.ns75ydl2v7czu7wv@dojo.mi.org> References: <20190709232635.ns75ydl2v7czu7wv@dojo.mi.org> Message-ID: On Tue, 9 Jul 2019, Mike O'Connor wrote: > :How do you deal with QoS for Office365, since the IPs are subject to changes ? > >How often is the data in: > > https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges > https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-service > >out of date? They provide a REST interface ... "Endpoints data is updated at the beginning of each month with new IP Addresses and URLs published 30 days in advance of being active." Last updated 6/28. There's also for this specific case. /mark From alan.buxey at gmail.com Wed Jul 10 17:55:21 2019 From: alan.buxey at gmail.com (Alan Buxey) Date: Wed, 10 Jul 2019 18:55:21 +0100 Subject: QoS for Office365 In-Reply-To: References: Message-ID: hi, use Direct Access PAC file for clients to get the right endpoints. Apply QoS to that traffic - and use that same PAC file to feed the IP ranges into your QoS rules on the firewall/router ? alan On Mon, 8 Jul 2019 at 17:15, Joe Yabuki wrote: > > Hi all, > > How do you deal with QoS for Office365, since the IPs are subject to changes ? > > How can we mark the trafic while keeping the security (I fear the marking based on TCP/UDP Ports since they are not without an additional risk coming from worms/virus using those ports for example, and doing that directly on the PCs doesn't seem to be the best solution) ? > > Many thanks, > Joe From agemberjacobson at colgate.edu Wed Jul 10 18:20:01 2019 From: agemberjacobson at colgate.edu (Aaron Gember-Jacobson) Date: Wed, 10 Jul 2019 14:20:01 -0400 Subject: Research survey about locating configuration errors Message-ID: Over the past decade, numerous tools have been developed to check the correctness of router configurations. However, there seems to be a gap between the information these tools provide and the information required to fix the configurations. As part of an ongoing research project at Colgate University, we seek to better understand how network engineers currently locate errors in router configurations. We would appreciate if you could take 2 minutes to complete our anonymous, 10-question survey: https://colgate.co1.qualtrics.com/jfe/form/SV_e3CQ3JMfCnLJHTL If you are willing to share more about your experience with configuration errors and/or current network analysis tools, please let us know. You can learn more about our research at: https://aaron.gember-jacobson.com/research/faultloc. Thanks, Aaron Gember-Jacobson *Assistant Professor of Computer Science, **Colgate University* -------------- next part -------------- An HTML attachment was scrubbed... URL: From beckman at angryox.com Thu Jul 11 03:05:07 2019 From: beckman at angryox.com (Peter Beckman) Date: Wed, 10 Jul 2019 23:05:07 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <3a7a0f7232773840871f3d63267435b1@mail.dessus.com> References: <3a7a0f7232773840871f3d63267435b1@mail.dessus.com> Message-ID: On Mon, 8 Jul 2019, Keith Medcalf wrote: > The solution is to disallow spoofing. If the "pretty overlay > information" does not equal the "billing information" then do not permit > the call to be made. Easy Peasy. This assumes that all calls from a phone number originate from the carrier of record for that phone number. This assumption is false. For calls made by Verizon Wireless customers that originate FROM Verizon Wireless's network, STIR/SHAKEN will enable Verizon to tag the call with a crypto sig that we can all verify came from Verizon, thus increasing the trust that the call originated from Verizon Wireless. However, Verizon not-Wireless also does other telephony business, such as termination. Verizon not-Wireless customers can and likely do terminate calls to them with CallerID of phone numbers that may or may not be registered with Level3, Onvoy, Bandwidth or another carrier. However Verizon not-Wireless has NO IDEA if their customer truly owns/leases the value in the CallerID field from another carrier. Thus Verizon not-Wireless may sign the terminating call using STIR/SHAKEN but have *NO IDEA* if their termination customer actually owns/leases/controls the CallerID value. And the absence of a STIR/SHAKEN header also means nothing. While we do LRN lookups for calls, we do not currently use that information to ensure that the originating party owns/leases that number legitimately. As a Tier 2 or 3 carrier, our carrier does not publish anywhere that we lease numbers from them, and our customers are not required to terminate calls using their phone numbers as CallerID with other carriers. The presence of STIR/SHAKEN increases the trust in the CallerID value ONLY when the phone number owner of record in the LNP database matches the signor of the call. The absence of STIR/SHAKEN is where we are already today. And small carriers can implement STIR/SHAKEN without concern for whether or not the CallerID value is their phone number or not. Though if the bad-actor does sign the call, I can distrust or block all of the bad-actor's calls. At least until they stop signing the calls, or they start a new contract with a new cert leaving all of us to play whack-a-mole some more, as we do now. DKIM-signed and SPF approved for all the good it will do, Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From sean at donelan.com Thu Jul 11 03:55:11 2019 From: sean at donelan.com (Sean Donelan) Date: Wed, 10 Jul 2019 23:55:11 -0400 (EDT) Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: Message-ID: On Tue, 9 Jul 2019, Sean Donelan wrote: > The agenda looks like lots of happy, happy talk from industry > representatives. In advance of the SHAKEN/STIR robocall summit, AT&T has issued a press release announcing plans to automatically block robocalls for its customers. https://about.att.com/story/2019/att_call_protect.html Automatic Blocking of Fraud Calls Coming to Millions of AT&T Customers AT&T* will add automatic fraud blocking and suspected spam-call alerts to millions of AT&T consumer lines at no charge. From morrowc.lists at gmail.com Thu Jul 11 04:09:57 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 11 Jul 2019 00:09:57 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: Message-ID: On Wed, Jul 10, 2019 at 11:56 PM Sean Donelan wrote: > > On Tue, 9 Jul 2019, Sean Donelan wrote: > > The agenda looks like lots of happy, happy talk from industry > > representatives. > > In advance of the SHAKEN/STIR robocall summit, AT&T has issued a press > release announcing plans to automatically block robocalls for its > customers. > > https://about.att.com/story/2019/att_call_protect.html > > Automatic Blocking of Fraud Calls Coming to Millions of AT&T Customers > AT&T* will add automatic fraud blocking and suspected spam-call alerts to > millions of AT&T consumer lines at no charge. oh goodie! So, not being a bell shaped headed person... a question: The calling path and data available inside the phone network smells (to me) like: ingress trunk + ANI + CallerID + outgoing trunk of destination ds0/handset There seem like a bunch of pretty simple 'correlations' one could make, that actually look a heck of a lot like 'netflow/log analysis for ddos detection': o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X o is this trunk sourcing calls from a low distribution of ANI but a different distribution of CallerID o is this trunk sourcing calls from unmatched (as a percent of total) ANI/CallerID I would think you could make similar correlations across the destinations on your phone-network: o Is there one ANI or CallerID talking to 'all' (a bunch, more than X of type Y customer end point) of my endpoints? o are there implausible callerid being used? (lots of 'NPA-NXX matches destination, yet from a very different geography?) I imagine that with the number of calls here, this is just a splunk correlation away from successful identification and then disabling of these nuisance calls... I imagine this doesn't need 'shaken' nor 'stir', but DOES take: "a whiff of a care" on the part of the carrier(s), right? Maybe they don't actually care about this problem until they are 'forced' to care about it by their regulating body? 'shaken' and 'stir' may not do anything at all useful for the problem, but they do make it appear that the carriers care about the problem... I'm certain that they know there are problems. The 5 items above can't be 'new and novel' concepts ... since this is basically 'logs analysis' that any security engineer worth their salt does as a matter of course daily, right? -chris From kmedcalf at dessus.com Thu Jul 11 05:12:36 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 10 Jul 2019 23:12:36 -0600 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: Message-ID: Their lawyers probably explained to them that they can "block" the call "after" accepting it and thus can get the best of both world -- the revenue from terminating the call while still preventing it from bothering their customers ... -- 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 Christopher >Morrow >Sent: Wednesday, 10 July, 2019 22:10 >To: Sean Donelan >Cc: nanog list >Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC > >On Wed, Jul 10, 2019 at 11:56 PM Sean Donelan >wrote: >> >> On Tue, 9 Jul 2019, Sean Donelan wrote: >> > The agenda looks like lots of happy, happy talk from industry >> > representatives. >> >> In advance of the SHAKEN/STIR robocall summit, AT&T has issued a >press >> release announcing plans to automatically block robocalls for its >> customers. >> >> https://about.att.com/story/2019/att_call_protect.html >> >> Automatic Blocking of Fraud Calls Coming to Millions of AT&T >Customers >> AT&T* will add automatic fraud blocking and suspected spam-call >alerts to >> millions of AT&T consumer lines at no charge. > >oh goodie! > >So, not being a bell shaped headed person... a question: > The calling path and data available inside the phone network smells >(to me) like: > ingress trunk + ANI + CallerID + outgoing trunk of destination >ds0/handset > >There seem like a bunch of pretty simple 'correlations' one could >make, that actually look a heck of a lot like 'netflow/log analysis >for ddos detection': > o is this trunk sourcing calls to 'too many' of my subs in >period-of-time-X > o is this trunk sourcing calls from a low distribution of ANI but >a different distribution of CallerID > o is this trunk sourcing calls from unmatched (as a percent of >total) ANI/CallerID > >I would think you could make similar correlations across the >destinations on your phone-network: > o Is there one ANI or CallerID talking to 'all' (a bunch, more >than X of type Y customer end point) of my endpoints? > o are there implausible callerid being used? (lots of 'NPA-NXX >matches destination, yet from a very different geography?) > >I imagine that with the number of calls here, this is just a splunk >correlation away from successful identification and then disabling of >these nuisance calls... >I imagine this doesn't need 'shaken' nor 'stir', but DOES take: "a >whiff of a care" on the part of the carrier(s), right? >Maybe they don't actually care about this problem until they are >'forced' to care about it by their regulating body? >'shaken' and 'stir' may not do anything at all useful for the >problem, >but they do make it appear that the carriers care about the >problem... >I'm certain that they know there are problems. The 5 items above >can't >be 'new and novel' concepts ... since this is basically 'logs >analysis' that any security engineer worth their salt does as a >matter >of course daily, right? > >-chris From rwfireguru at gmail.com Thu Jul 11 13:51:48 2019 From: rwfireguru at gmail.com (Robert Webb) Date: Thu, 11 Jul 2019 09:51:48 -0400 Subject: Reddit down Message-ID: Are we having yet another CDN meltdown or is it isolated to just reddit? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.d.morrison at me.com Thu Jul 11 13:55:20 2019 From: michael.d.morrison at me.com (Michael Morrison) Date: Thu, 11 Jul 2019 09:55:20 -0400 Subject: Reddit down In-Reply-To: References: Message-ID: Reddit main page loads for me in Columbus Ohio on a Level 3 loop. > On Jul 11, 2019, at 9:51 AM, Robert Webb wrote: > > Are we having yet another CDN meltdown or is it isolated to just reddit? From rwfireguru at gmail.com Thu Jul 11 13:57:16 2019 From: rwfireguru at gmail.com (Robert Webb) Date: Thu, 11 Jul 2019 09:57:16 -0400 Subject: Reddit down In-Reply-To: References: Message-ID: I am getting, "Our CDN was unable to reach our servers". Looking at down detector, there are lots of folks reporting issues and the Reddit status page has a high error rate... On Thu, Jul 11, 2019 at 9:55 AM Michael Morrison wrote: > Reddit main page loads for me in Columbus Ohio on a Level 3 loop. > > > On Jul 11, 2019, at 9:51 AM, Robert Webb wrote: > > > > Are we having yet another CDN meltdown or is it isolated to just reddit? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwfireguru at gmail.com Thu Jul 11 14:01:36 2019 From: rwfireguru at gmail.com (Robert Webb) Date: Thu, 11 Jul 2019 10:01:36 -0400 Subject: Reddit down In-Reply-To: References: Message-ID: Sorry for the noise... >From my end it appears to be browser related. Accessing from Chrome fails but works without issue on Edge.. On Thu, Jul 11, 2019 at 9:55 AM Michael Morrison wrote: > Reddit main page loads for me in Columbus Ohio on a Level 3 loop. > > > On Jul 11, 2019, at 9:51 AM, Robert Webb wrote: > > > > Are we having yet another CDN meltdown or is it isolated to just reddit? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Thu Jul 11 14:14:23 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 11 Jul 2019 16:14:23 +0200 Subject: Reddit down In-Reply-To: References: Message-ID: Good for me at my house right now - Johannesburg. Fastly are delivering... MacBook-Pro-7:~ tinka$ traceroute -I www.reddit.com traceroute to reddit.map.fastly.net (151.101.173.140), 64 hops max, 72 byte packets  1  10.0.32.1 (10.0.32.1)  6.238 ms  5.571 ms  5.425 ms  2  ae-1-4.pr-01-jnb.za.seacomnet.com (105.16.165.253)  6.902 ms  3.966 ms  5.166 ms  3  ae-4-0.pp-01-jnb.za.seacomnet.com (105.16.29.8)  5.466 ms  6.375 ms  5.811 ms  4  fastly.ixp.joburg (196.60.8.13)  4.556 ms  5.220 ms  5.085 ms  5  151.101.173.140 (151.101.173.140)  4.846 ms  4.562 ms  5.395 ms MacBook-Pro-7:~ tinka$ Mark. On 11/Jul/19 15:57, Robert Webb wrote: > I am getting, "Our CDN was unable to reach our servers". > > Looking at down detector, there are lots of folks reporting issues and > the Reddit status page has a high error rate... > > On Thu, Jul 11, 2019 at 9:55 AM Michael Morrison > > wrote: > > Reddit main page loads for me in Columbus Ohio on a Level 3 loop. > > > On Jul 11, 2019, at 9:51 AM, Robert Webb > wrote: > > > > Are we having yet another CDN meltdown or is it isolated to just > reddit? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikebolitho at gmail.com Thu Jul 11 14:25:56 2019 From: mikebolitho at gmail.com (Mike Bolitho) Date: Thu, 11 Jul 2019 07:25:56 -0700 Subject: Reddit down In-Reply-To: References: Message-ID: Working fine in Phoenix on Cox and CenturyLink. -Mike Bolitho On Thu, Jul 11, 2019, 7:16 AM Mark Tinka wrote: > Good for me at my house right now - Johannesburg. > > Fastly are delivering... > > MacBook-Pro-7:~ tinka$ traceroute -I www.reddit.com > traceroute to reddit.map.fastly.net (151.101.173.140), 64 hops max, 72 > byte packets > 1 10.0.32.1 (10.0.32.1) 6.238 ms 5.571 ms 5.425 ms > 2 ae-1-4.pr-01-jnb.za.seacomnet.com (105.16.165.253) 6.902 ms 3.966 > ms 5.166 ms > 3 ae-4-0.pp-01-jnb.za.seacomnet.com (105.16.29.8) 5.466 ms 6.375 ms > 5.811 ms > 4 fastly.ixp.joburg (196.60.8.13) 4.556 ms 5.220 ms 5.085 ms > 5 151.101.173.140 (151.101.173.140) 4.846 ms 4.562 ms 5.395 ms > MacBook-Pro-7:~ tinka$ > > Mark. > > On 11/Jul/19 15:57, Robert Webb wrote: > > I am getting, "Our CDN was unable to reach our servers". > > Looking at down detector, there are lots of folks reporting issues and the > Reddit status page has a high error rate... > > On Thu, Jul 11, 2019 at 9:55 AM Michael Morrison < > michael.d.morrison at me.com> wrote: > >> Reddit main page loads for me in Columbus Ohio on a Level 3 loop. >> >> > On Jul 11, 2019, at 9:51 AM, Robert Webb wrote: >> > >> > Are we having yet another CDN meltdown or is it isolated to just >> reddit? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Jul 11 14:29:46 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 11 Jul 2019 09:29:46 -0500 (CDT) Subject: Time and Timing Servers In-Reply-To: <279130447.155.1562855203570.JavaMail.mhammett@ThunderFuck> Message-ID: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> There were a lot of NTP threads several weeks ago, but I didn't get an answer to my question amongst all of the other chatter. I'm looking for a device that can receive GPS inside a building without the assistance of an external antenna (Frontier says they no longer allow external antenna), will provide traditional NTP services, and will provide a timing signal that my Metaswitch can work with. I know that MicroSemi via Symmetricom makes these kinds of devices, but I'm hoping to look at multiple manufacturers and compare. Thanks. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP -------------- next part -------------- An HTML attachment was scrubbed... URL: From telmnstr at 757.org Thu Jul 11 14:46:24 2019 From: telmnstr at 757.org (Ethan O'Toole) Date: Thu, 11 Jul 2019 10:46:24 -0400 (EDT) Subject: Time and Timing Servers In-Reply-To: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> References: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> Message-ID: > I'm looking for a device that can receive GPS inside a building without > the assistance of an external antenna (Frontier says they no longer > allow external antenna), will provide traditional NTP services, and will > provide a timing signal that my Metaswitch can work with. GPS inside a building probably isn't going to work unless you have the antenna up against a window. Look at CDMA NTP Servers like the EndRun Sonoma. They use the cellular network which requires accurate timing and has good building penetration. - Ethan O'Toole From nanog at ics-il.net Thu Jul 11 14:50:48 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 11 Jul 2019 09:50:48 -0500 (CDT) Subject: Time and Timing Servers In-Reply-To: References: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> Message-ID: <844197431.270.1562856643573.JavaMail.mhammett@ThunderFuck> Isn't a major problem with CDMA-based sources that the networks they depend on are getting shut down? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Ethan O'Toole" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Thursday, July 11, 2019 9:46:24 AM Subject: Re: Time and Timing Servers > I'm looking for a device that can receive GPS inside a building without > the assistance of an external antenna (Frontier says they no longer > allow external antenna), will provide traditional NTP services, and will > provide a timing signal that my Metaswitch can work with. GPS inside a building probably isn't going to work unless you have the antenna up against a window. Look at CDMA NTP Servers like the EndRun Sonoma. They use the cellular network which requires accurate timing and has good building penetration. - Ethan O'Toole -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfidelman at meetinghouse.net Thu Jul 11 14:52:14 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 11 Jul 2019 10:52:14 -0400 Subject: Reddit down In-Reply-To: References: Message-ID: <40001dcb-d7b9-ee14-100c-41a11897b9a4@meetinghouse.net> Seems to be having problems here. Was getting "CDN can't reach" messages, now getting reddit pages - but the individual lines are listing "something went wrong, don't panic" and a global pop-up "couldn't load posts for this page.  Meanwhile the phone app seems to be working just fine. Just tried using Firefox instead of Chrome, and back to "CDN can't reach." Odd...  but I'd guess it's something between their web server & database. On 7/11/19 9:51 AM, Robert Webb wrote: > Are we having yet another CDN meltdown or is it isolated to just reddit? -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown From msa at latt.net Thu Jul 11 14:54:26 2019 From: msa at latt.net (Majdi S. Abbas) Date: Thu, 11 Jul 2019 10:54:26 -0400 Subject: Time and Timing Servers In-Reply-To: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> References: <279130447.155.1562855203570.JavaMail.mhammett@ThunderFuck> <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> Message-ID: <20190711145426.GA11465@puck.nether.net> On Thu, Jul 11, 2019 at 09:29:46AM -0500, Mike Hammett wrote: > There were a lot of NTP threads several weeks ago, but I didn't get an answer to my question amongst all of the other chatter. > > I'm looking for a device that can receive GPS inside a building without the > assistance of an external antenna (Frontier says they no longer allow > external antenna), will provide traditional NTP services, and will provide > a timing signal that my Metaswitch can work with. Unfortunately, L band satellite signals are incredibly weak by the time they reach the surface. It's very unlikely this is going to work for you (unless it's a wood framed single story building.) Generally, I try to ensure that a GNSS antenna is built into the contract, to avoid games like this. You have two options: A) Find a new colocation provider. This may already be on your to-do list for other reasons. B) Rely on the Internet for timing, using NTP or PTP from another location to backfeed the site, and use a box with a good stable oscillator to keep time (this can actually be a commercial time server with decent holdover characteristics. If you're just looking for alternatives to Microsemi, I highly recommend talking to the fine folks at Meinberg. --msa From tim.h at bendtel.com Thu Jul 11 14:55:36 2019 From: tim.h at bendtel.com (Tim Howe) Date: Thu, 11 Jul 2019 07:55:36 -0700 Subject: Reddit down In-Reply-To: References: Message-ID: <20190711075536.4fcaa77c@Morty> On Thu, 11 Jul 2019 10:01:36 -0400 Robert Webb wrote: > Sorry for the noise... > > From my end it appears to be browser related. > > Accessing from Chrome fails but works without issue on Edge.. > I'm also finding that it works with Chrome but I'm getting the "Our CDN was unable to reach our servers" message when I use Firefox. --TimH From msa at latt.net Thu Jul 11 14:58:31 2019 From: msa at latt.net (Majdi S. Abbas) Date: Thu, 11 Jul 2019 10:58:31 -0400 Subject: Time and Timing Servers In-Reply-To: <844197431.270.1562856643573.JavaMail.mhammett@ThunderFuck> References: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> <844197431.270.1562856643573.JavaMail.mhammett@ThunderFuck> Message-ID: <20190711145831.GB11465@puck.nether.net> On Thu, Jul 11, 2019 at 09:50:48AM -0500, Mike Hammett wrote: > Isn't a major problem with CDMA-based sources that the networks > they depend on are getting shut down? Domestically, yes. Not only are you dependant on Sprint if you go that route (Verizon is already pulling the plug on CDMA this year.), it was never any better than +/- 10 ms or so. You can get that via NTP pointed at the Internet. At best, all you were doing with CDMA was relying on a cell site's GPS receiver and holdover characteristics -- which were totally opaque to you. At least you can monitor NTP. --msa From ryan at deadfrog.net Thu Jul 11 15:02:55 2019 From: ryan at deadfrog.net (Ryan Wilkins) Date: Thu, 11 Jul 2019 11:02:55 -0400 Subject: Time and Timing Servers In-Reply-To: <844197431.270.1562856643573.JavaMail.mhammett@ThunderFuck> References: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> <844197431.270.1562856643573.JavaMail.mhammett@ThunderFuck> Message-ID: <55BD864C-7FA1-4EAE-9EFA-291B0A429158@deadfrog.net> Yes, expect CDMA cellular to disappear before too long. Verizon is shutting down their CDMA network at the end of this year. Sprint announced in February 2019 that it is no longer activating CDMA-only devices starting May 1 2019. No sunset date has been announced yet but suffice it to say the ball is in motion to sunset their CDMA network. Any of the regional carriers that run CDMA networks are likely to follow suit in short order. Ryan Wilkins > On Jul 11, 2019, at 10:50 AM, Mike Hammett wrote: > > Isn't a major problem with CDMA-based sources that the networks they depend on are getting shut down? > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "Ethan O'Toole" > To: "Mike Hammett" > Cc: nanog at nanog.org > Sent: Thursday, July 11, 2019 9:46:24 AM > Subject: Re: Time and Timing Servers > > > I'm looking for a device that can receive GPS inside a building without > > the assistance of an external antenna (Frontier says they no longer > > allow external antenna), will provide traditional NTP services, and will > > provide a timing signal that my Metaswitch can work with. > > GPS inside a building probably isn't going to work unless you have the > antenna up against a window. > > Look at CDMA NTP Servers like the EndRun Sonoma. They use the cellular > network which requires accurate timing and has good building penetration. > > - Ethan O'Toole -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboyd at gizmopartners.com Thu Jul 11 15:03:02 2019 From: cboyd at gizmopartners.com (Chris Boyd) Date: Thu, 11 Jul 2019 11:03:02 -0400 Subject: Time and Timing Servers In-Reply-To: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> References: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> Message-ID: <406BB08A-FD69-4A4A-BCE8-6536C3F3624C@gizmopartners.com> > On Jul 11, 2019, at 10:29 AM, Mike Hammett wrote: > > I'm looking for a device that can receive GPS inside a building without the assistance of an external antenna (Frontier says they no longer allow external antenna), will provide traditional NTP services, and will provide a timing signal that my Metaswitch can work with. Since it’s a telco facility, maybe they can provide BITS service. Worth asking. —Chris From mel at beckman.org Thu Jul 11 15:03:46 2019 From: mel at beckman.org (Mel Beckman) Date: Thu, 11 Jul 2019 15:03:46 +0000 Subject: Reddit down In-Reply-To: <40001dcb-d7b9-ee14-100c-41a11897b9a4@meetinghouse.net> References: , <40001dcb-d7b9-ee14-100c-41a11897b9a4@meetinghouse.net> Message-ID: <1D4A3571-A5DA-4B97-AEF0-4A7162064088@beckman.org> Reddit down? “I sense an improvement in The Force” :) -mel > On Jul 11, 2019, at 7:54 AM, Miles Fidelman wrote: > > Seems to be having problems here. > > Was getting "CDN can't reach" messages, now getting reddit pages - but the individual lines are listing "something went wrong, don't panic" and a global pop-up "couldn't load posts for this page. Meanwhile the phone app seems to be working just fine. > > Just tried using Firefox instead of Chrome, and back to "CDN can't reach." > > Odd... but I'd guess it's something between their web server & database. > >> On 7/11/19 9:51 AM, Robert Webb wrote: >> Are we having yet another CDN meltdown or is it isolated to just reddit? > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > Theory is when you know everything but nothing works. > Practice is when everything works but no one knows why. > In our lab, theory and practice are combined: > nothing works and no one knows why. ... unknown > From warren at kumari.net Thu Jul 11 15:14:55 2019 From: warren at kumari.net (Warren Kumari) Date: Thu, 11 Jul 2019 11:14:55 -0400 Subject: Time and Timing Servers In-Reply-To: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> References: <279130447.155.1562855203570.JavaMail.mhammett@ThunderFuck> <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> Message-ID: On Thu, Jul 11, 2019 at 10:30 AM Mike Hammett wrote: > There were a lot of NTP threads several weeks ago, but I didn't get an > answer to my question amongst all of the other chatter. > > I'm looking for a device that can receive GPS inside a building without > the assistance of an external antenna (Frontier says they no longer allow > external antenna), will provide traditional NTP services, and will provide > a timing signal that my Metaswitch can work with. > > I know that MicroSemi via Symmetricom makes these kinds of devices, but > I'm hoping to look at multiple manufacturers and compare. > I have a Symmetricom S250 with the Rb option -- it has an active antenna; while it does *technically* work inside buildings it really needs to be jammed right up against a window to work. In my (top floor in my house) office it gets no reception unless against a window... W > > > Thanks. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf -------------- next part -------------- An HTML attachment was scrubbed... URL: From nchabbey at n3network.ch Thu Jul 11 14:35:19 2019 From: nchabbey at n3network.ch (Nicolas Chabbey) Date: Thu, 11 Jul 2019 16:35:19 +0200 Subject: Reddit down In-Reply-To: References: Message-ID: <6d3a783f-ea33-bea9-168f-2a14b268f520@n3network.ch> Maybe backend related? I've a 503 here: $ wget -X GET http://www.reddit.com/r/FedEx/ --2019-07-11 16:34:03-- http://www.reddit.com/r/FedEx/ Resolving www.reddit.com (www.reddit.com)... 151.101.121.140 Connecting to www.reddit.com (www.reddit.com)|151.101.121.140|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://www.reddit.com/r/FedEx/ [following] --2019-07-11 16:34:04-- https://www.reddit.com/r/FedEx/ Connecting to www.reddit.com (www.reddit.com)|151.101.121.140|:443... connected. HTTP request sent, awaiting response... 503 Service Unavailable: Back-end server is at capacity 2019-07-11 16:34:04 ERROR 503: Service Unavailable: Back-end server is at capacity. Regards On 11/07/2019 16:25, Mike Bolitho wrote: > Working fine in Phoenix on Cox and CenturyLink. > > -Mike Bolitho > > On Thu, Jul 11, 2019, 7:16 AM Mark Tinka > wrote: > > Good for me at my house right now - Johannesburg. > > Fastly are delivering... > > MacBook-Pro-7:~ tinka$ traceroute -I www.reddit.com > > traceroute to reddit.map.fastly.net > (151.101.173.140), 64 hops max, 72 byte packets >  1  10.0.32.1 (10.0.32.1)  6.238 ms  5.571 ms  5.425 ms >  2  ae-1-4.pr-01-jnb.za.seacomnet.com > (105.16.165.253)  6.902 > ms  3.966 ms  5.166 ms >  3  ae-4-0.pp-01-jnb.za.seacomnet.com > (105.16.29.8)  5.466 ms  > 6.375 ms  5.811 ms >  4  fastly.ixp.joburg (196.60.8.13)  4.556 ms  5.220 ms  5.085 ms >  5  151.101.173.140 (151.101.173.140)  4.846 ms  4.562 ms  5.395 ms > MacBook-Pro-7:~ tinka$ > > Mark. > > On 11/Jul/19 15:57, Robert Webb wrote: >> I am getting, "Our CDN was unable to reach our servers". >> >> Looking at down detector, there are lots of folks reporting issues >> and the Reddit status page has a high error rate... >> >> On Thu, Jul 11, 2019 at 9:55 AM Michael Morrison >> > wrote: >> >> Reddit main page loads for me in Columbus Ohio on a Level 3 loop. >> >> > On Jul 11, 2019, at 9:51 AM, Robert Webb >> > wrote: >> > >> > Are we having yet another CDN meltdown or is it isolated to >> just reddit? >> > From nanog at ics-il.net Thu Jul 11 15:23:41 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 11 Jul 2019 10:23:41 -0500 (CDT) Subject: Time and Timing Servers In-Reply-To: <20190711145426.GA11465@puck.nether.net> References: <279130447.155.1562855203570.JavaMail.mhammett@ThunderFuck> <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> <20190711145426.GA11465@puck.nether.net> Message-ID: <1160193036.296.1562858615650.JavaMail.mhammett@ThunderFuck> I'll look into Meinberg. I recent thread mentioned high-sensitivity receivers often allow GPS to work inside. Obviously "inside" has a lot of definitions. I will need this facility for the TDM timing signals. It's a central office, not a datacenter. I don't know that Internet-based NTP would be accurate enough for the timing signals that I need. Maybe, maybe not. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Majdi S. Abbas" To: "Mike Hammett" Cc: nanog at nanog.org Sent: Thursday, July 11, 2019 9:54:26 AM Subject: Re: Time and Timing Servers On Thu, Jul 11, 2019 at 09:29:46AM -0500, Mike Hammett wrote: > There were a lot of NTP threads several weeks ago, but I didn't get an answer to my question amongst all of the other chatter. > > I'm looking for a device that can receive GPS inside a building without the > assistance of an external antenna (Frontier says they no longer allow > external antenna), will provide traditional NTP services, and will provide > a timing signal that my Metaswitch can work with. Unfortunately, L band satellite signals are incredibly weak by the time they reach the surface. It's very unlikely this is going to work for you (unless it's a wood framed single story building.) Generally, I try to ensure that a GNSS antenna is built into the contract, to avoid games like this. You have two options: A) Find a new colocation provider. This may already be on your to-do list for other reasons. B) Rely on the Internet for timing, using NTP or PTP from another location to backfeed the site, and use a box with a good stable oscillator to keep time (this can actually be a commercial time server with decent holdover characteristics. If you're just looking for alternatives to Microsemi, I highly recommend talking to the fine folks at Meinberg. --msa -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Jul 11 15:24:56 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 11 Jul 2019 10:24:56 -0500 (CDT) Subject: Time and Timing Servers In-Reply-To: <406BB08A-FD69-4A4A-BCE8-6536C3F3624C@gizmopartners.com> References: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> <406BB08A-FD69-4A4A-BCE8-6536C3F3624C@gizmopartners.com> Message-ID: <1863090942.302.1562858689962.JavaMail.mhammett@ThunderFuck> They can do BITS, but that doesn't solve all of my problems. That said, I may have to do many things if I can't find my wonder box. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Chris Boyd" To: "NANOG" Sent: Thursday, July 11, 2019 10:03:02 AM Subject: Re: Time and Timing Servers > On Jul 11, 2019, at 10:29 AM, Mike Hammett wrote: > > I'm looking for a device that can receive GPS inside a building without the assistance of an external antenna (Frontier says they no longer allow external antenna), will provide traditional NTP services, and will provide a timing signal that my Metaswitch can work with. Since it’s a telco facility, maybe they can provide BITS service. Worth asking. —Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From telmnstr at 757.org Thu Jul 11 15:25:02 2019 From: telmnstr at 757.org (Ethan O'Toole) Date: Thu, 11 Jul 2019 11:25:02 -0400 (EDT) Subject: Time and Timing Servers In-Reply-To: <844197431.270.1562856643573.JavaMail.mhammett@ThunderFuck> References: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> <844197431.270.1562856643573.JavaMail.mhammett@ThunderFuck> Message-ID: > Isn't a major problem with CDMA-based sources that the networks they depend on are getting shut down? If so, I would imagine there will be timing servers based on the replacement cellular technology. Might ask EndRun or one of their competitors about it. - Ethan From paul at telcodata.us Thu Jul 11 15:59:33 2019 From: paul at telcodata.us (Paul Timmins) Date: Thu, 11 Jul 2019 11:59:33 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: Message-ID: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> Chris it would be trivial for this to be fixed, nearly overnight, by creating some liability on the part of carriers for illicit use of caller ID data on behalf of their customers. But the carriers don't want that, so now we have to create tons of technical half solutions to solve a problem that would be neatly solved by carriers. On 7/11/19 12:09 AM, Christopher Morrow wrote: > There seem like a bunch of pretty simple 'correlations' one could > make, that actually look a heck of a lot like 'netflow/log analysis > for ddos detection': > o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X > o is this trunk sourcing calls from a low distribution of ANI but > a different distribution of CallerID > o is this trunk sourcing calls from unmatched (as a percent of > total) ANI/CallerID > > I would think you could make similar correlations across the > destinations on your phone-network: > o Is there one ANI or CallerID talking to 'all' (a bunch, more > than X of type Y customer end point) of my endpoints? > o are there implausible callerid being used? (lots of 'NPA-NXX > matches destination, yet from a very different geography?) From brian at interlinx.bc.ca Thu Jul 11 17:02:44 2019 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Thu, 11 Jul 2019 13:02:44 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> Message-ID: <6a39daecb8c5188352e3202f25e67848303a7a0a.camel@interlinx.bc.ca> On Thu, 2019-07-11 at 11:59 -0400, Paul Timmins wrote: > Chris it would be trivial for this to be fixed, nearly overnight, by > creating some liability on the part of carriers for illicit use of > caller ID data on behalf of their customers. This 1000%. Once legal liability is in place, the carriers themselves will come up with the most effective and efficient solutions to solve the problem. > But the carriers don't want that, And the legislators are in the pockets of Corporate America so nothing will happen. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From morrowc.lists at gmail.com Thu Jul 11 17:18:12 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 11 Jul 2019 13:18:12 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> Message-ID: On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins wrote: > > Chris it would be trivial for this to be fixed, nearly overnight, by > creating some liability on the part of carriers for illicit use of > caller ID data on behalf of their customers. 'illicit use of caller id' - how is caller-id being illicitly used though? I don't think it's against the law to say a different 'callerid' in the call session, practically every actual call center does this, right? > But the carriers don't want that, so now we have to create tons of > technical half solutions to solve a problem that would be neatly solved > by carriers. logs analysis and 'netflow' (CDR trolling, really) would be nearly free for them, implementing actions based on the data / outcomes of that analysis at near-real-time would also be nearly free... but sure, we can do a bunch of this other stuff too... My sort of solution has actually got proven track record though? -chris > On 7/11/19 12:09 AM, Christopher Morrow wrote: > > There seem like a bunch of pretty simple 'correlations' one could > > make, that actually look a heck of a lot like 'netflow/log analysis > > for ddos detection': > > o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X > > o is this trunk sourcing calls from a low distribution of ANI but > > a different distribution of CallerID > > o is this trunk sourcing calls from unmatched (as a percent of > > total) ANI/CallerID > > > > I would think you could make similar correlations across the > > destinations on your phone-network: > > o Is there one ANI or CallerID talking to 'all' (a bunch, more > > than X of type Y customer end point) of my endpoints? > > o are there implausible callerid being used? (lots of 'NPA-NXX > > matches destination, yet from a very different geography?) From james.cutler at consultant.com Thu Jul 11 18:25:18 2019 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 11 Jul 2019 14:25:18 -0400 Subject: Time and Timing Servers In-Reply-To: <1160193036.296.1562858615650.JavaMail.mhammett@ThunderFuck> References: <279130447.155.1562855203570.JavaMail.mhammett@ThunderFuck> <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> <20190711145426.GA11465@puck.nether.net> <1160193036.296.1562858615650.JavaMail.mhammett@ThunderFuck> Message-ID: > On Jul 11, 2019, at 11:23 AM, Mike Hammett wrote: > > I'll look into Meinberg. > > I recent thread mentioned high-sensitivity receivers often allow GPS to work inside. Obviously "inside" has a lot of definitions. > > I will need this facility for the TDM timing signals. It's a central office, not a datacenter. > > I don't know that Internet-based NTP would be accurate enough for the timing signals that I need. Maybe, maybe not. > My experience with Dave Mills NTP algorithm is that, giving sufficient diversity in higher stratum sources, GPS versus Internet sources makes no practical difference. This assumes that you are concerned with Time for event logging and scheduling and not concerned with frequency and phase for clocking data on TDM instances. If you are worrying about backhoe fade — it’s consequences will most likely affect other things more strongly than Time differences. James R. Cutler James.cutler at consultant.com GPG keys: hkps://hkps.pool.sks-keyservers.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Thu Jul 11 18:31:16 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 11 Jul 2019 12:31:16 -0600 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: Message-ID: <7ca118406e31534bbb55e4cfa90ec544@mail.dessus.com> On Thursday, 11 July, 2019 11:18, Christopher Morrow wrote: >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins wrote: >> Chris it would be trivial for this to be fixed, nearly overnight, >> by creating some liability on the part of carriers for illicit use of >> caller ID data on behalf of their customers. >'illicit use of caller id' - how is caller-id being illicitly used >though? >I don't think it's against the law to say a different 'callerid' in >the call session, practically every actual call center does this, right? The problem is that CallerID is not really the CallerID. It is some fraudulent shit created by the caller. This is not how "CallerID" was originally sold. It was sold as being the ID of the Caller. If it is not the ID of the Caller then Fraud is being committed and the bastards should be castrated (or worse), and the CEO and Directors of the carrier responsible for fraud getting through to the end-user should face the same penalty. See then how quickly this gets fixed. You will fall off your chair and it will be a "solved problem" before your arse hits the ground! -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From mike at mtcc.com Thu Jul 11 18:33:25 2019 From: mike at mtcc.com (Michael Thomas) Date: Thu, 11 Jul 2019 11:33:25 -0700 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> Message-ID: So I have a meta-question about all of this. Why in 2019 are we still using telephone numbers as the primary identifier? It's a pretty sip-py world these days, even on mobile phones with wifi calling, I assume. It seems like this problem would be more tractable if callerid was a last resort rather than a first resort. Mike On 7/11/19 10:18 AM, Christopher Morrow wrote: > On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins wrote: >> Chris it would be trivial for this to be fixed, nearly overnight, by >> creating some liability on the part of carriers for illicit use of >> caller ID data on behalf of their customers. > 'illicit use of caller id' - how is caller-id being illicitly used though? > I don't think it's against the law to say a different 'callerid' in the call > session, practically every actual call center does this, right? > >> But the carriers don't want that, so now we have to create tons of >> technical half solutions to solve a problem that would be neatly solved >> by carriers. > logs analysis and 'netflow' (CDR trolling, really) would be nearly free for > them, implementing actions based on the data / outcomes of that > analysis at near-real-time would also be nearly free... > > but sure, we can do a bunch of this other stuff too... My sort of solution > has actually got proven track record though? > > -chris > >> On 7/11/19 12:09 AM, Christopher Morrow wrote: >>> There seem like a bunch of pretty simple 'correlations' one could >>> make, that actually look a heck of a lot like 'netflow/log analysis >>> for ddos detection': >>> o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X >>> o is this trunk sourcing calls from a low distribution of ANI but >>> a different distribution of CallerID >>> o is this trunk sourcing calls from unmatched (as a percent of >>> total) ANI/CallerID >>> >>> I would think you could make similar correlations across the >>> destinations on your phone-network: >>> o Is there one ANI or CallerID talking to 'all' (a bunch, more >>> than X of type Y customer end point) of my endpoints? >>> o are there implausible callerid being used? (lots of 'NPA-NXX >>> matches destination, yet from a very different geography?) From ross at tajvar.io Thu Jul 11 18:37:48 2019 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 11 Jul 2019 14:37:48 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <7ca118406e31534bbb55e4cfa90ec544@mail.dessus.com> References: <7ca118406e31534bbb55e4cfa90ec544@mail.dessus.com> Message-ID: What if you use different carriers for termination and origination? How does your termination carrier validate that your origination carrier has allocated certain numbers to you and that you're therefore allowed to make outbound calls with a caller ID set to those numbers? That doesn't sound to me like something that can be solved as quickly and easily as you imply. On Thu, Jul 11, 2019, 2:33 PM Keith Medcalf wrote: > > On Thursday, 11 July, 2019 11:18, Christopher Morrow < > morrowc.lists at gmail.com> wrote: > > >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins wrote: > > >> Chris it would be trivial for this to be fixed, nearly overnight, > >> by creating some liability on the part of carriers for illicit use of > >> caller ID data on behalf of their customers. > > >'illicit use of caller id' - how is caller-id being illicitly used > >though? > >I don't think it's against the law to say a different 'callerid' in > >the call session, practically every actual call center does this, right? > > The problem is that CallerID is not really the CallerID. It is some > fraudulent shit created by the caller. This is not how "CallerID" was > originally sold. It was sold as being the ID of the Caller. If it is not > the ID of the Caller then Fraud is being committed and the bastards should > be castrated (or worse), and the CEO and Directors of the carrier > responsible for fraud getting through to the end-user should face the same > penalty. > > See then how quickly this gets fixed. You will fall off your chair and it > will be a "solved problem" before your arse hits the ground! > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven says > a lot about anticipated traffic volume. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Thu Jul 11 18:46:25 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 11 Jul 2019 12:46:25 -0600 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: Message-ID: On Thursday, 11 July, 2019 12:38, Ross Tajvar wrote: >What if you use different carriers for termination and origination? >How does your termination carrier validate that your origination >carrier has allocated certain numbers to you and that you're >therefore allowed to make outbound calls with a caller ID set to >those numbers? That doesn't sound to me like something that can be >solved as quickly and easily as you imply. It does not really matter. What matters is that they bear responsibility for an act in furtherance of a conspiracy to commit fraud. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. > >On Thu, Jul 11, 2019, 2:33 PM Keith Medcalf >wrote: > > > > On Thursday, 11 July, 2019 11:18, Christopher Morrow > wrote: > > >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins > wrote: > > >> Chris it would be trivial for this to be fixed, nearly >overnight, > >> by creating some liability on the part of carriers for >illicit use of > >> caller ID data on behalf of their customers. > > >'illicit use of caller id' - how is caller-id being illicitly >used > >though? > >I don't think it's against the law to say a different >'callerid' in > >the call session, practically every actual call center does >this, right? > > The problem is that CallerID is not really the CallerID. It is >some fraudulent shit created by the caller. This is not how >"CallerID" was originally sold. It was sold as being the ID of the >Caller. If it is not the ID of the Caller then Fraud is being >committed and the bastards should be castrated (or worse), and the >CEO and Directors of the carrier responsible for fraud getting >through to the end-user should face the same penalty. > > See then how quickly this gets fixed. You will fall off your >chair and it will be a "solved problem" before your arse hits the >ground! > > -- > The fact that there's a Highway to Hell but only a Stairway to >Heaven says a lot about anticipated traffic volume. > > > > > From ross at tajvar.io Thu Jul 11 18:53:32 2019 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 11 Jul 2019 14:53:32 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: Message-ID: Well yeah, people need to take responsibility, but IMO we as engineers need to discuss the specific circumstances and methodologies that enable that to happen. It's easy to say "they should fix it", and you're not wrong that they should, but how? Do you have a validation framework in mind which carriers can implement that prevents fraudulent caller ID information from being sent without preventing legitimate use cases? On Thu, Jul 11, 2019, 2:46 PM Keith Medcalf wrote: > > On Thursday, 11 July, 2019 12:38, Ross Tajvar wrote: > > >What if you use different carriers for termination and origination? > >How does your termination carrier validate that your origination > >carrier has allocated certain numbers to you and that you're > >therefore allowed to make outbound calls with a caller ID set to > >those numbers? That doesn't sound to me like something that can be > >solved as quickly and easily as you imply. > > It does not really matter. What matters is that they bear responsibility > for an act in furtherance of a conspiracy to commit fraud. > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven says > a lot about anticipated traffic volume. > > > > > >On Thu, Jul 11, 2019, 2:33 PM Keith Medcalf > >wrote: > > > > > > > > On Thursday, 11 July, 2019 11:18, Christopher Morrow > > wrote: > > > > >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins > > wrote: > > > > >> Chris it would be trivial for this to be fixed, nearly > >overnight, > > >> by creating some liability on the part of carriers for > >illicit use of > > >> caller ID data on behalf of their customers. > > > > >'illicit use of caller id' - how is caller-id being illicitly > >used > > >though? > > >I don't think it's against the law to say a different > >'callerid' in > > >the call session, practically every actual call center does > >this, right? > > > > The problem is that CallerID is not really the CallerID. It is > >some fraudulent shit created by the caller. This is not how > >"CallerID" was originally sold. It was sold as being the ID of the > >Caller. If it is not the ID of the Caller then Fraud is being > >committed and the bastards should be castrated (or worse), and the > >CEO and Directors of the carrier responsible for fraud getting > >through to the end-user should face the same penalty. > > > > See then how quickly this gets fixed. You will fall off your > >chair and it will be a "solved problem" before your arse hits the > >ground! > > > > -- > > The fact that there's a Highway to Hell but only a Stairway to > >Heaven says a lot about anticipated traffic volume. > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beckman at angryox.com Thu Jul 11 18:57:28 2019 From: beckman at angryox.com (Peter Beckman) Date: Thu, 11 Jul 2019 14:57:28 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: <7ca118406e31534bbb55e4cfa90ec544@mail.dessus.com> Message-ID: On Thu, 11 Jul 2019, Ross Tajvar wrote: > What if you use different carriers for termination and origination? How > does your termination carrier validate that your origination carrier has > allocated certain numbers to you and that you're therefore allowed to make > outbound calls with a caller ID set to those numbers? That doesn't sound to > me like something that can be solved as quickly and easily as you imply. I attended the first panel at the FCC and Scott Mullen, CTO at Bandwidth, was the only one that brought up issues that are not addressed by implementing STIR/SHAKEN. 1. There's no delegation -- there is no standardized means of telling anyone who is the End User of a specific TN. 2. Self-signed certs are being used so far, which means that you need to establish trust in a full mesh in order for STIR/SHAKEN to be of any value. Not feasible, definitely fragile. This could be addressed using a Public Cert Authority. 3. Relies 100% in your trust of the initial carrier to properly set the Attestation level on the call. 4. Does not cover if the call is received with a STIR/SHAKEN header to a termination provider with Full Attestation that turns out to be a lie. 5. Does not actually verify that the CallerID is really the EU generating the call. For Wireless Carriers it can, since calls are both received and placed by the same carrier in most cases, but what about roaming? Is Three UK going to implement STIR/SHAKEN or will it occur at Verizon's edge? How do any of us know that the Identity: header was added at the first point of origin? All STIR/SHAKEN is doing is adding an Identity: header to the SIP payload that one can use to verify that a carrier signed the call at some point. Some carriers may be trustworthy, some may blindly add Full Attestation for a termination customer that has a nice mix legit and spoofed calls. There is still no connection between the End User of a phone number and the call itself. And there's no way for me as a carrier to check to see if a phone number should only originate from specific networks or not. Even if it is signed, I know nothing more than I do now about the legitimacy of the call. Argh. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From paul at telcodata.us Thu Jul 11 18:59:37 2019 From: paul at telcodata.us (Paul Timmins) Date: Thu, 11 Jul 2019 14:59:37 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> Message-ID: <57dbb8c2-b126-ebcf-4eea-15893dc207ab@telcodata.us> Pretty simply - Sending caller ID to commit fraud. It's literally already illegal. The legislature has already defined it for us, even. 47 USC 227 https://www.law.cornell.edu/uscode/text/47/227 (B) to initiate any telephone call to any residential telephone line using an artificial or prerecorded voice to deliver a message without the prior express consent of the called party, unless the call is initiated for emergency purposes, is made solely pursuant to the collection of a debt owed to or guaranteed by the United States , or is exempted by rule or order by theCommission under paragraph (2)(B); (e)(1)In general It shall be unlawful for any person within the United States , in connection with any telecommunications service orIP-enabled voice service, to cause anycaller identification service to knowingly transmit misleading or inaccuratecaller identification information with the intent to defraud, cause harm, or wrongfully obtain anything of value, unless such transmission is exempted pursuant to paragraph (3)(B). All I'm asking is to make the carrier liable if it should have been obvious to a carrier using basic traffic analysis that the service was a robocaller (low answer rates combined with tons of source numbers, especially situations where the source and destination number share the first 6 digits) that the carrier be liable for failing to look into it. Carriers already look at things like short duration in order to assess higher charges, and already investigate call center traffic. If they then look at the caller ID and it looks "suspect", and the customer then is contacted and barred from sending arbitrary caller ID until they can verify they own the numbers they're calling from, then they're good to go. If the carrier continues to just ensure that call center traffic is a revenue stream they can bill higher without making sure they're outpulsing valid numbers, then they should absorb the social costs of what's going on. Let's not get this confused - this isn't about customer PBXen outpulsing forwarded calls when they do it, it's about people shooting millions of calls a month, the carrier hitting them with short duration charges, making more money, and having zero incentive to question the arrangement. -Paul On 7/11/19 1:18 PM, Christopher Morrow wrote: > 'illicit use of caller id' - how is caller-id being illicitly used though? > I don't think it's against the law to say a different 'callerid' in the call > session, practically every actual call center does this, right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Thu Jul 11 18:59:53 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 11 Jul 2019 12:59:53 -0600 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: Message-ID: <8d812ece57855046a4a114b815050eb6@mail.dessus.com> Not my job. However, if you hire me I am sure that I can come up with a solution. Since retirement my rates have dropped to $1,000/hour with a 4 hour minimum. Payable in advance since you probably have no established credit with me. -- 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: Ross Tajvar [mailto:ross at tajvar.io] >Sent: Thursday, 11 July, 2019 12:54 >To: Keith Medcalf >Cc: Christopher Morrow; North American Network Operators' Group >Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC > >Well yeah, people need to take responsibility, but IMO we as >engineers need to discuss the specific circumstances and >methodologies that enable that to happen. It's easy to say "they >should fix it", and you're not wrong that they should, but how? Do >you have a validation framework in mind which carriers can implement >that prevents fraudulent caller ID information from being sent >without preventing legitimate use cases? > >On Thu, Jul 11, 2019, 2:46 PM Keith Medcalf >wrote: > > > > On Thursday, 11 July, 2019 12:38, Ross Tajvar >wrote: > > >What if you use different carriers for termination and >origination? > >How does your termination carrier validate that your >origination > >carrier has allocated certain numbers to you and that you're > >therefore allowed to make outbound calls with a caller ID set >to > >those numbers? That doesn't sound to me like something that can >be > >solved as quickly and easily as you imply. > > It does not really matter. What matters is that they bear >responsibility for an act in furtherance of a conspiracy to commit >fraud. > > -- > The fact that there's a Highway to Hell but only a Stairway to >Heaven says a lot about anticipated traffic volume. > > > > > >On Thu, Jul 11, 2019, 2:33 PM Keith Medcalf > > >wrote: > > > > > > > > On Thursday, 11 July, 2019 11:18, Christopher Morrow > > wrote: > > > > >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins > > wrote: > > > > >> Chris it would be trivial for this to be fixed, >nearly > >overnight, > > >> by creating some liability on the part of carriers >for > >illicit use of > > >> caller ID data on behalf of their customers. > > > > >'illicit use of caller id' - how is caller-id being >illicitly > >used > > >though? > > >I don't think it's against the law to say a different > >'callerid' in > > >the call session, practically every actual call center >does > >this, right? > > > > The problem is that CallerID is not really the CallerID. >It is > >some fraudulent shit created by the caller. This is not how > >"CallerID" was originally sold. It was sold as being the ID of >the > >Caller. If it is not the ID of the Caller then Fraud is being > >committed and the bastards should be castrated (or worse), and >the > >CEO and Directors of the carrier responsible for fraud getting > >through to the end-user should face the same penalty. > > > > See then how quickly this gets fixed. You will fall off >your > >chair and it will be a "solved problem" before your arse hits >the > >ground! > > > > -- > > The fact that there's a Highway to Hell but only a >Stairway to > >Heaven says a lot about anticipated traffic volume. > > > > > > > > > > > > > > > From morrowc.lists at gmail.com Thu Jul 11 19:01:07 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 11 Jul 2019 15:01:07 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <7ca118406e31534bbb55e4cfa90ec544@mail.dessus.com> References: <7ca118406e31534bbb55e4cfa90ec544@mail.dessus.com> Message-ID: On Thu, Jul 11, 2019 at 2:31 PM Keith Medcalf wrote: > > > On Thursday, 11 July, 2019 11:18, Christopher Morrow wrote: > > >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins wrote: > > >> Chris it would be trivial for this to be fixed, nearly overnight, > >> by creating some liability on the part of carriers for illicit use of > >> caller ID data on behalf of their customers. > > >'illicit use of caller id' - how is caller-id being illicitly used > >though? > >I don't think it's against the law to say a different 'callerid' in > >the call session, practically every actual call center does this, right? > > The problem is that CallerID is not really the CallerID. It is some fraudulent shit created by the caller. This is not how "CallerID" was originally sold. It was sold as being the ID of the Caller. If it is not the ID of the Caller then Fraud is being committed and the bastards should be castrated (or worse), and the CEO and Directors of the carrier responsible for fraud getting through to the end-user should face the same penalty. > This is why I said ANI in one of my messages, yes. you CAN, however, in the network see the callerid, and ANI and tell what's going on... (credit where due: a kind caller noted to me: https://www.law.cornell.edu/uscode/text/18/1028 which may make the use of 'someone elses' callerid by 'me' illegal) -chris > > See then how quickly this gets fixed. You will fall off your chair and it will be a "solved problem" before your arse hits the ground! > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. > > > > From beckman at angryox.com Thu Jul 11 19:02:51 2019 From: beckman at angryox.com (Peter Beckman) Date: Thu, 11 Jul 2019 15:02:51 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: Message-ID: On Thu, 11 Jul 2019, Keith Medcalf wrote: > On Thursday, 11 July, 2019 12:38, Ross Tajvar wrote: > >> What if you use different carriers for termination and origination? >> How does your termination carrier validate that your origination >> carrier has allocated certain numbers to you and that you're >> therefore allowed to make outbound calls with a caller ID set to >> those numbers? That doesn't sound to me like something that can be >> solved as quickly and easily as you imply. > > It does not really matter. What matters is that they bear responsibility > for an act in furtherance of a conspiracy to commit fraud. Fraud means you'll need to know the content of the call to determine if the spoofing of the CallerID value meets the bar of breaking the law. Truth in CallerID Act is only violated if there is intent to defraud when the CallerID is spoofed. If you spoof CallerID and do not know the content of the call, you cannot know if the Act was violated. And we don't want to get into the business of monitoring the content of phone calls. That opens legal floodgates. If someone complains, at least you have some recourse. But you have that today. And by the time someone complains and you trace the call back to a source in the US (if you can, a woman from AT&T said a "traceback" now takes days instead of months, still too slow to take any real action), you find out it originated outside the US and you have a dead end. Traceroute for Calls would be nice... each hop adds its own header, kind of like the "Received:" header that exists multiple times in an email. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From morrowc.lists at gmail.com Thu Jul 11 19:03:52 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 11 Jul 2019 15:03:52 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> Message-ID: On Thu, Jul 11, 2019 at 2:35 PM Michael Thomas wrote: > > So I have a meta-question about all of this. Why in 2019 are we still > using telephone numbers as the primary identifier? It's a pretty sip-py > world these days, even on mobile phones with wifi calling, I assume. It > seems like this problem would be more tractable if callerid was a last > resort rather than a first resort. yes! I bet that if you provided some form of 'identity' to the caller and permitted the callee to verify that data upon call setup... you'd get further along. there could even be an ecosystem of services which callees could subscribe to in order to report reputation and have that be used to influence call completions over time... if only there were such systems in existence already... if only some form of proof of concept existed? > Mike > > > On 7/11/19 10:18 AM, Christopher Morrow wrote: > > On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins wrote: > >> Chris it would be trivial for this to be fixed, nearly overnight, by > >> creating some liability on the part of carriers for illicit use of > >> caller ID data on behalf of their customers. > > 'illicit use of caller id' - how is caller-id being illicitly used though? > > I don't think it's against the law to say a different 'callerid' in the call > > session, practically every actual call center does this, right? > > > >> But the carriers don't want that, so now we have to create tons of > >> technical half solutions to solve a problem that would be neatly solved > >> by carriers. > > logs analysis and 'netflow' (CDR trolling, really) would be nearly free for > > them, implementing actions based on the data / outcomes of that > > analysis at near-real-time would also be nearly free... > > > > but sure, we can do a bunch of this other stuff too... My sort of solution > > has actually got proven track record though? > > > > -chris > > > >> On 7/11/19 12:09 AM, Christopher Morrow wrote: > >>> There seem like a bunch of pretty simple 'correlations' one could > >>> make, that actually look a heck of a lot like 'netflow/log analysis > >>> for ddos detection': > >>> o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X > >>> o is this trunk sourcing calls from a low distribution of ANI but > >>> a different distribution of CallerID > >>> o is this trunk sourcing calls from unmatched (as a percent of > >>> total) ANI/CallerID > >>> > >>> I would think you could make similar correlations across the > >>> destinations on your phone-network: > >>> o Is there one ANI or CallerID talking to 'all' (a bunch, more > >>> than X of type Y customer end point) of my endpoints? > >>> o are there implausible callerid being used? (lots of 'NPA-NXX > >>> matches destination, yet from a very different geography?) From beckman at angryox.com Thu Jul 11 19:04:08 2019 From: beckman at angryox.com (Peter Beckman) Date: Thu, 11 Jul 2019 15:04:08 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <57dbb8c2-b126-ebcf-4eea-15893dc207ab@telcodata.us> References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> <57dbb8c2-b126-ebcf-4eea-15893dc207ab@telcodata.us> Message-ID: "with the intent to defraud, cause harm, or wrongfully obtain anything of value" Kind of a huge hole that, unless you record all calls which opens other liability, is hard to prove. Beckman On Thu, 11 Jul 2019, Paul Timmins wrote: > Pretty simply - Sending caller ID to commit fraud. It's literally already > illegal. The legislature has already defined it for us, even. > > 47 USC 227 > > https://www.law.cornell.edu/uscode/text/47/227 > > (B) > to initiate any telephone call to any residential telephone line using an > artificial or prerecorded voice to deliver a message without the prior > express consent of the called party, unless the call is initiated for > emergency purposes, is made solely pursuant to the collection of a debt owed > to or guaranteed by the United States > , or is exempted by rule or > order by theCommission under > paragraph (2)(B); > > (e)(1)In general > > It shall be unlawful for any person > within the United States > , in connection with any > telecommunications service > orIP-enabled voice service, > to cause anycaller identification service > to knowingly transmit > misleading or inaccuratecaller identification information > with the intent to defraud, > cause harm, or wrongfully obtain anything of value, unless such transmission > is exempted pursuant to paragraph (3)(B). > > All I'm asking is to make the carrier liable if it should have been obvious > to a carrier using basic traffic analysis that the service was a robocaller > (low answer rates combined with tons of source numbers, especially situations > where the source and destination number share the first 6 digits) that the > carrier be liable for failing to look into it. > > Carriers already look at things like short duration in order to assess higher > charges, and already investigate call center traffic. If they then look at > the caller ID and it looks "suspect", and the customer then is contacted and > barred from sending arbitrary caller ID until they can verify they own the > numbers they're calling from, then they're good to go. > > If the carrier continues to just ensure that call center traffic is a revenue > stream they can bill higher without making sure they're outpulsing valid > numbers, then they should absorb the social costs of what's going on. > > Let's not get this confused - this isn't about customer PBXen outpulsing > forwarded calls when they do it, it's about people shooting millions of calls > a month, the carrier hitting them with short duration charges, making more > money, and having zero incentive to question the arrangement. > > -Paul > > On 7/11/19 1:18 PM, Christopher Morrow wrote: >> 'illicit use of caller id' - how is caller-id being illicitly used though? >> I don't think it's against the law to say a different 'callerid' in the >> call >> session, practically every actual call center does this, right? > --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From morrowc.lists at gmail.com Thu Jul 11 19:05:04 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 11 Jul 2019 15:05:04 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> <57dbb8c2-b126-ebcf-4eea-15893dc207ab@telcodata.us> Message-ID: On Thu, Jul 11, 2019 at 3:04 PM Peter Beckman wrote: > > "with the intent to defraud, cause harm, or wrongfully obtain anything of > value" > > Kind of a huge hole that, unless you record all calls which opens other > liability, is hard to prove. > I'm not sure that the cited code works for this case, agreed. I'm also not a lawyer :) I'm a chemical engineer. > Beckman > > On Thu, 11 Jul 2019, Paul Timmins wrote: > > > Pretty simply - Sending caller ID to commit fraud. It's literally already > > illegal. The legislature has already defined it for us, even. > > > > 47 USC 227 > > > > https://www.law.cornell.edu/uscode/text/47/227 > > > > (B) > > to initiate any telephone call to any residential telephone line using an > > artificial or prerecorded voice to deliver a message without the prior > > express consent of the called party, unless the call is initiated for > > emergency purposes, is made solely pursuant to the collection of a debt owed > > to or guaranteed by the United States > > , or is exempted by rule or > > order by theCommission under > > paragraph (2)(B); > > > > (e)(1)In general > > > > It shall be unlawful for any person > > within the United States > > , in connection with any > > telecommunications service > > orIP-enabled voice service, > > to cause anycaller identification service > > to knowingly transmit > > misleading or inaccuratecaller identification information > > with the intent to defraud, > > cause harm, or wrongfully obtain anything of value, unless such transmission > > is exempted pursuant to paragraph (3)(B). > > > > All I'm asking is to make the carrier liable if it should have been obvious > > to a carrier using basic traffic analysis that the service was a robocaller > > (low answer rates combined with tons of source numbers, especially situations > > where the source and destination number share the first 6 digits) that the > > carrier be liable for failing to look into it. > > > > Carriers already look at things like short duration in order to assess higher > > charges, and already investigate call center traffic. If they then look at > > the caller ID and it looks "suspect", and the customer then is contacted and > > barred from sending arbitrary caller ID until they can verify they own the > > numbers they're calling from, then they're good to go. > > > > If the carrier continues to just ensure that call center traffic is a revenue > > stream they can bill higher without making sure they're outpulsing valid > > numbers, then they should absorb the social costs of what's going on. > > > > Let's not get this confused - this isn't about customer PBXen outpulsing > > forwarded calls when they do it, it's about people shooting millions of calls > > a month, the carrier hitting them with short duration charges, making more > > money, and having zero incentive to question the arrangement. > > > > -Paul > > > > On 7/11/19 1:18 PM, Christopher Morrow wrote: > >> 'illicit use of caller id' - how is caller-id being illicitly used though? > >> I don't think it's against the law to say a different 'callerid' in the > >> call > >> session, practically every actual call center does this, right? > > > > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- From karsten.elfenbein at gmail.com Thu Jul 11 19:11:13 2019 From: karsten.elfenbein at gmail.com (Karsten Elfenbein) Date: Thu, 11 Jul 2019 21:11:13 +0200 Subject: Time and Timing Servers In-Reply-To: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> References: <279130447.155.1562855203570.JavaMail.mhammett@ThunderFuck> <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> Message-ID: I think you are referencing their chip scale atomic clocks. Which are very frequency stable. But still need phase alignment. (Mobile UPS anyone?) Maybe some peers can provide transparent or boundry clock support. Or someone close by in the DC can add an antenna splitter. Karsten Mike Hammett schrieb am Do., 11. Juli 2019, 16:31: > There were a lot of NTP threads several weeks ago, but I didn't get an > answer to my question amongst all of the other chatter. > > I'm looking for a device that can receive GPS inside a building without > the assistance of an external antenna (Frontier says they no longer allow > external antenna), will provide traditional NTP services, and will provide > a timing signal that my Metaswitch can work with. > > I know that MicroSemi via Symmetricom makes these kinds of devices, but > I'm hoping to look at multiple manufacturers and compare. > > > Thanks. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mtcc.com Thu Jul 11 19:14:26 2019 From: mike at mtcc.com (Michael Thomas) Date: Thu, 11 Jul 2019 12:14:26 -0700 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> Message-ID: <8eb204d4-3ddc-f7ac-d4fd-48f02f1eba3e@mtcc.com> On 7/11/19 12:03 PM, Christopher Morrow wrote: > On Thu, Jul 11, 2019 at 2:35 PM Michael Thomas wrote: >> So I have a meta-question about all of this. Why in 2019 are we still >> using telephone numbers as the primary identifier? It's a pretty sip-py >> world these days, even on mobile phones with wifi calling, I assume. It >> seems like this problem would be more tractable if callerid was a last >> resort rather than a first resort. > yes! I bet that if you provided some form of 'identity' to the caller > and permitted the callee to verify that data upon call setup... you'd > get further along. > there could even be an ecosystem of services which callees could > subscribe to in order to report reputation and have that be used to > influence call completions over time... > > if only there were such systems in existence already... if only some > form of proof of concept existed? > >> 15 years ago when I was working on DKIM, I added DKIM signatures to SIP messages for shits and giggles. It really wouldn't be that hard to extend DKIM for SIP. Same goes for SPF. Same goes, I assume, for DMARC. We pretty much know how to identify email providers, and the providers can pretty well identify individual accounts. Same goes for SIP, it seems to me. I assume interprovider these days is all IP for the most part. I would think that the only remaining vestiges of the PSTN is the last mile where landlines are going extinct, and most mobile minutes are done over wifi/IP. Mike From mike at mtcc.com Thu Jul 11 19:23:15 2019 From: mike at mtcc.com (Michael Thomas) Date: Thu, 11 Jul 2019 12:23:15 -0700 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> <57dbb8c2-b126-ebcf-4eea-15893dc207ab@telcodata.us> Message-ID: <6ee6c6cc-0584-ca49-8bd6-d633c5fbc429@mtcc.com> On 7/11/19 12:05 PM, Christopher Morrow wrote: > On Thu, Jul 11, 2019 at 3:04 PM Peter Beckman wrote: >> "with the intent to defraud, cause harm, or wrongfully obtain anything of >> value" >> >> Kind of a huge hole that, unless you record all calls which opens other >> liability, is hard to prove. >> > I'm not sure that the cited code works for this case, agreed. > I'm also not a lawyer :) > I'm a chemical engineer. I used to think that email spam was a law enforcement problem too, but it's become very clear that law enforcement has little to no interest in solving geeks' problems. Mike From kmedcalf at dessus.com Thu Jul 11 19:31:19 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 11 Jul 2019 13:31:19 -0600 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: Message-ID: <9babde9c23285a4d96d2d9aafcb29bd7@mail.dessus.com> -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. On Thursday, 11 July, 2019 13:03, Peter Beckman wrote: >On Thu, 11 Jul 2019, Keith Medcalf wrote: >> On Thursday, 11 July, 2019 12:38, Ross Tajvar >wrote: >> >>> What if you use different carriers for termination and >origination? >>> How does your termination carrier validate that your origination >>> carrier has allocated certain numbers to you and that you're >>> therefore allowed to make outbound calls with a caller ID set to >>> those numbers? That doesn't sound to me like something that can be >>> solved as quickly and easily as you imply. >> >> It does not really matter. What matters is that they bear >responsibility >> for an act in furtherance of a conspiracy to commit fraud. > > Fraud means you'll need to know the content of the call to >determine if > the spoofing of the CallerID value meets the bar of breaking the >law. > > Truth in CallerID Act is only violated if there is intent to >defraud when > the CallerID is spoofed. If you spoof CallerID and do not know the >content > of the call, you cannot know if the Act was violated. The "content" of the call is irrelevant. If one received identification information (the CallerID) and then passes that information on (a deliberate act) with the intent that it be acted upon as if valid (is the CallerID), and that information later turns out to be fraudulent (it does not in fact identify the caller) then the "passer on" has acted in furtherance of the conspiracy to defraud. Neither negligence nor recklessness is a defense against the conspiracy. The only essential elements that need to be proved are that (a) the callerid information was fraudulent (b) the passer-on intended that the information be taken as non-fraudulent. The fact that the passer-on also "made money from" its specific act in furtherance of the conspiracy is further proof of active participation and benefit from participation in the conspiracy. The second rule in relation to intent also applies: If one deliberately engages on a course of action in which a given result is possible outcome, and that result ensues, implies the intent to cause the result so obtained, notwithstanding that the course of action was intended to obtain a different result. If "CallerID" were in fact sold as "whatever information caller chooses to convey" rather than as the Identification of the caller, then there would be no problem in "passing on" that information. However holding out that "CallerID" is in fact the ID of the Caller, and making money by holding out that to be the case, means that the passer-on of the fraudulent information is liable for the falsity of that information notwithstanding that he cannot verify it. So in fact the whole thing is and was from the get-go a designed with the intent to convey information under fraudulent pretenses and for fraudulent purposes. From esr at thyrsus.com Thu Jul 11 20:16:55 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 11 Jul 2019 16:16:55 -0400 Subject: Time and Timing Servers In-Reply-To: References: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> Message-ID: <20190711201655.GB84939@thyrsus.com> Ethan O'Toole : > > I'm looking for a device that can receive GPS inside a building without > > the assistance of an external antenna (Frontier says they no longer > > allow external antenna), will provide traditional NTP services, and will > > provide a timing signal that my Metaswitch can work with. > > GPS inside a building probably isn't going to work unless you have the > antenna up against a window. Concur. But if you have that, my microserver build on a Raspberry Pi will do nicely. https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/ No need for expensive proprietary hardware. -- Eric S. Raymond From paul at telcodata.us Thu Jul 11 20:23:19 2019 From: paul at telcodata.us (Paul Timmins) Date: Thu, 11 Jul 2019 16:23:19 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> <57dbb8c2-b126-ebcf-4eea-15893dc207ab@telcodata.us> Message-ID: Not really. For reasons already cited by Keith Medcalf in an offshoot of the thread, and because the real world implication of that liability transfer would be telecom carriers undertaking risk management and looking at their products and pricing and deciding whether certain customers should be allowed to send arbitrary caller ID. What would likely happen is that small customers would be allowed to send whatever, like today. Call center customers (they are already identifying these because most big carriers have different rates for callcenter activity because of the network load it puts on them) would likely be restricted to a subset of numbers, and the biggest, long term call centers would probably be allowed to send whatever they want, but with a contract that compels them to indemnify the carrier against loss (which would only work if the call center was well capitalized enough to make that commitment, because the carrier would NOT want to be stuck with the bill if they couldn't pay up). It may sound burdensome, but speaking as an employee of a carrier who is in a position to see how things work on the business AND technical side (who I do not speak for, in this context) - we're already looking at what our customer's intended use is, and whether they're asking for a product they can reasonably afford, we run their business credit and if they aren't clean enough, we request prepayment for our services, or similar. This would just be one more risk we'd take into account. -Paul On 7/11/19 3:04 PM, Peter Beckman wrote: > "with the intent to defraud, cause harm, or wrongfully obtain anything of > value" > > Kind of a huge hole that, unless you record all calls which opens other > liability, is hard to prove. > > Beckman > > On Thu, 11 Jul 2019, Paul Timmins wrote: > >> Pretty simply - Sending caller ID to commit fraud. It's literally >> already illegal. The legislature has already defined it for us, even. >> >> 47 USC 227 >> >> https://www.law.cornell.edu/uscode/text/47/227 >> >> (B) >> to initiate any telephone call to any residential telephone line >> using an artificial or prerecorded voice to deliver a message without >> the prior express consent of the called party, unless the call is >> initiated for emergency purposes, is made solely pursuant to the >> collection of a debt owed to or guaranteed by the United States >> , or is exempted by >> rule or order by theCommission >> under paragraph (2)(B); >> >> (e)(1)In general >> >> It shall be unlawful for any person >> within the United >> States , in >> connection with any telecommunications service >> orIP-enabled voice >> service, to cause >> anycaller identification service >> to knowingly transmit >> misleading or inaccuratecaller identification information >> with the intent to >> defraud, cause harm, or wrongfully obtain anything of value, unless >> such transmission is exempted pursuant to paragraph (3)(B). >> >> All I'm asking is to make the carrier liable if it should have been >> obvious to a carrier using basic traffic analysis that the service >> was a robocaller (low answer rates combined with tons of source >> numbers, especially situations where the source and destination >> number share the first 6 digits) that the carrier be liable for >> failing to look into it. >> >> Carriers already look at things like short duration in order to >> assess higher charges, and already investigate call center traffic. >> If they then look at the caller ID and it looks "suspect", and the >> customer then is contacted and barred from sending arbitrary caller >> ID until they can verify they own the numbers they're calling from, >> then they're good to go. >> >> If the carrier continues to just ensure that call center traffic is a >> revenue stream they can bill higher without making sure they're >> outpulsing valid numbers, then they should absorb the social costs of >> what's going on. >> >> Let's not get this confused - this isn't about customer PBXen >> outpulsing forwarded calls when they do it, it's about people >> shooting millions of calls a month, the carrier hitting them with >> short duration charges, making more money, and having zero incentive >> to question the arrangement. >> >> -Paul >> >> On 7/11/19 1:18 PM, Christopher Morrow wrote: >>> 'illicit use of caller id' - how is caller-id being illicitly used >>> though? >>> I don't think it's against the law to say a different 'callerid' in >>> the call >>>   session, practically every actual call center does this, right? >> > > --------------------------------------------------------------------------- > > Peter Beckman Internet Guy > beckman at angryox.com http://www.angryox.com/ > --------------------------------------------------------------------------- > From esr at thyrsus.com Thu Jul 11 20:25:16 2019 From: esr at thyrsus.com (Eric S. Raymond) Date: Thu, 11 Jul 2019 16:25:16 -0400 Subject: Time and Timing Servers In-Reply-To: References: <279130447.155.1562855203570.JavaMail.mhammett@ThunderFuck> <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> <20190711145426.GA11465@puck.nether.net> <1160193036.296.1562858615650.JavaMail.mhammett@ThunderFuck> Message-ID: <20190711202516.GC84939@thyrsus.com> James R Cutler : > My experience with Dave Mills NTP algorithm is that, giving sufficient diversity in higher stratum sources, GPS versus Internet sources makes no practical difference. This assumes that you are concerned with Time for event logging and scheduling and not concerned with frequency and phase for clocking data on TDM instances. > > If you are worrying about backhoe fade — it’s consequences will most likely affect other things more strongly than Time differences. I'm a subject-matter expert in Internet time service (tech lead of NTPsec) and I concur. Local GPS sources are nice to have and fun to play with but not essential unless you have a mission requitement to run autonomous. Note by the way that you *can* run completely autonomous with NTPsec, but not with the NTF version. https://blog.ntpsec.org/2017/08/30/achieving-autonomy.html -- Eric S. Raymond From sean at donelan.com Thu Jul 11 20:47:29 2019 From: sean at donelan.com (Sean Donelan) Date: Thu, 11 Jul 2019 16:47:29 -0400 (EDT) Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: Message-ID: Chairman Pai issues statement at the conclusion of the SHAKEN/STIR robocall summit. https://docs.fcc.gov/public/attachments/DOC-358430A1.pdf WASHINGTON, July 11, 2019—Federal Communications Commission Chairman Ajit Pai issued the following statement on today’s SHAKEN/STIR Robocall Summit at the FCC: “We must move aggressively to help consumers combat scam robocalls that use and abuse caller ID spoofing, and that’s why we held today’s summit. The summit was productive, and we received generally encouraging signs that companies are headed toward full implementation of the SHAKEN/STIR caller ID authentication framework. I was pleased to hear from voice service providers, vendors, consumer advocates, and others about the successes to date and the challenges that remain. “Given what I heard today, I am optimistic that the major voice service providers will meet the end-of-2019 deadline for implementation I set for them. That said, we stand ready to take regulatory action if this deadline is not met. We have already adopted a Notice of Proposed Rulemaking and will move quickly to mandate SHAKEN/STIR if needed. “As I’ve said before and as panelists noted today, there is no silver bullet to solving the problem of unwanted robocalls. But caller ID authentication is an important part of the solution. And we will continue to execute on the rest of our multi-pronged strategy as well. We have been and will continue to do everything we can to protect American consumers from this scourge.” From keith at contoocook.net Thu Jul 11 20:49:35 2019 From: keith at contoocook.net (keith at contoocook.net) Date: Thu, 11 Jul 2019 16:49:35 -0400 Subject: Time and Timing Servers Message-ID: An HTML attachment was scrubbed... URL: From bsvec at teamonesolutions.com Thu Jul 11 17:07:34 2019 From: bsvec at teamonesolutions.com (Brandon Svec) Date: Thu, 11 Jul 2019 10:07:34 -0700 Subject: NANOG Digest, Vol 138, Issue 11 In-Reply-To: References: Message-ID: Having a somewhat bell shaped head, this sums it up pretty well, “.. Maybe they don't actually care about this problem until they are 'forced' to care about it by their regulating body?” As I understand, currently carriers are required to pass spoofed caller ID because there are many legitimate reasons to do so. There was some recent legislation loosening that requirement and there is no requirement to define what legitimate is, but still the issue is some one needs to care about the problem. That will require legislation and incentives to get to. > >-----Original Message----- > >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher > >Morrow > >Sent: Wednesday, 10 July, 2019 22:10 > >To: Sean Donelan > >Cc: nanog list > >Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC > > > >On Wed, Jul 10, 2019 at 11:56 PM Sean Donelan > >wrote: > >> > >> On Tue, 9 Jul 2019, Sean Donelan wrote: > >> > The agenda looks like lots of happy, happy talk from industry > >> > representatives. > >> > >> In advance of the SHAKEN/STIR robocall summit, AT&T has issued a > >press > >> release announcing plans to automatically block robocalls for its > >> customers. > >> > >> https://about.att.com/story/2019/att_call_protect.html > >> > >> Automatic Blocking of Fraud Calls Coming to Millions of AT&T > >Customers > >> AT&T* will add automatic fraud blocking and suspected spam-call > >alerts to > >> millions of AT&T consumer lines at no charge. > > > >oh goodie! > > > >So, not being a bell shaped headed person... a question: > > The calling path and data available inside the phone network smells > >(to me) like: > > ingress trunk + ANI + CallerID + outgoing trunk of destination > >ds0/handset > > > >There seem like a bunch of pretty simple 'correlations' one could > >make, that actually look a heck of a lot like 'netflow/log analysis > >for ddos detection': > > o is this trunk sourcing calls to 'too many' of my subs in > >period-of-time-X > > o is this trunk sourcing calls from a low distribution of ANI but > >a different distribution of CallerID > > o is this trunk sourcing calls from unmatched (as a percent of > >total) ANI/CallerID > > > >I would think you could make similar correlations across the > >destinations on your phone-network: > > o Is there one ANI or CallerID talking to 'all' (a bunch, more > >than X of type Y customer end point) of my endpoints? > > o are there implausible callerid being used? (lots of 'NPA-NXX > >matches destination, yet from a very different geography?) > > > >I imagine that with the number of calls here, this is just a splunk > >correlation away from successful identification and then disabling of > >these nuisance calls... > >I imagine this doesn't need 'shaken' nor 'stir', but DOES take: "a > >whiff of a care" on the part of the carrier(s), right? > >Maybe they don't actually care about this problem until they are > >'forced' to care about it by their regulating body? > >'shaken' and 'stir' may not do anything at all useful for the > >problem, > >but they do make it appear that the carriers care about the > >problem... > >I'm certain that they know there are problems. The 5 items above > >can't > >be 'new and novel' concepts ... since this is basically 'logs > >analysis' that any security engineer worth their salt does as a > >matter > >of course daily, right? > > > >-chris > > > > > > End of NANOG Digest, Vol 138, Issue 11 > ************************************** > -- Brandon Svec 15106862204 voice | fax | sms teamonesolutions.com 14729 Catalina St. San Leandro, CA 94577 .ılı.ılı. Cisco Meraki CMNA -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Thu Jul 11 23:01:38 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 12 Jul 2019 02:01:38 +0300 Subject: NANOG Digest, Vol 138, Issue 11 In-Reply-To: References: Message-ID: Please DO NOT reply to digests. It makes it way harder to follow discussions on the list this way. -- Töma On Fri, Jul 12, 2019, 1:42 AM Brandon Svec wrote: > Having a somewhat bell shaped head, this sums it up pretty well, “.. Maybe > they don't actually care about this problem until they are > 'forced' to care about it by their regulating body?” > > As I understand, currently carriers are required to pass spoofed caller ID > because there are many legitimate reasons to do so. There was some recent > legislation loosening that requirement and there is no requirement to > define what legitimate is, but still the issue is some one needs to care > about the problem. That will require legislation and incentives to get to. > > > >> >-----Original Message----- >> >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Christopher >> >Morrow >> >Sent: Wednesday, 10 July, 2019 22:10 >> >To: Sean Donelan >> >Cc: nanog list >> >Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC >> > >> >On Wed, Jul 10, 2019 at 11:56 PM Sean Donelan >> >wrote: >> >> >> >> On Tue, 9 Jul 2019, Sean Donelan wrote: >> >> > The agenda looks like lots of happy, happy talk from industry >> >> > representatives. >> >> >> >> In advance of the SHAKEN/STIR robocall summit, AT&T has issued a >> >press >> >> release announcing plans to automatically block robocalls for its >> >> customers. >> >> >> >> https://about.att.com/story/2019/att_call_protect.html >> >> >> >> Automatic Blocking of Fraud Calls Coming to Millions of AT&T >> >Customers >> >> AT&T* will add automatic fraud blocking and suspected spam-call >> >alerts to >> >> millions of AT&T consumer lines at no charge. >> > >> >oh goodie! >> > >> >So, not being a bell shaped headed person... a question: >> > The calling path and data available inside the phone network smells >> >(to me) like: >> > ingress trunk + ANI + CallerID + outgoing trunk of destination >> >ds0/handset >> > >> >There seem like a bunch of pretty simple 'correlations' one could >> >make, that actually look a heck of a lot like 'netflow/log analysis >> >for ddos detection': >> > o is this trunk sourcing calls to 'too many' of my subs in >> >period-of-time-X >> > o is this trunk sourcing calls from a low distribution of ANI but >> >a different distribution of CallerID >> > o is this trunk sourcing calls from unmatched (as a percent of >> >total) ANI/CallerID >> > >> >I would think you could make similar correlations across the >> >destinations on your phone-network: >> > o Is there one ANI or CallerID talking to 'all' (a bunch, more >> >than X of type Y customer end point) of my endpoints? >> > o are there implausible callerid being used? (lots of 'NPA-NXX >> >matches destination, yet from a very different geography?) >> > >> >I imagine that with the number of calls here, this is just a splunk >> >correlation away from successful identification and then disabling of >> >these nuisance calls... >> >I imagine this doesn't need 'shaken' nor 'stir', but DOES take: "a >> >whiff of a care" on the part of the carrier(s), right? >> >Maybe they don't actually care about this problem until they are >> >'forced' to care about it by their regulating body? >> >'shaken' and 'stir' may not do anything at all useful for the >> >problem, >> >but they do make it appear that the carriers care about the >> >problem... >> >I'm certain that they know there are problems. The 5 items above >> >can't >> >be 'new and novel' concepts ... since this is basically 'logs >> >analysis' that any security engineer worth their salt does as a >> >matter >> >of course daily, right? >> > >> >-chris >> >> >> >> >> >> End of NANOG Digest, Vol 138, Issue 11 >> ************************************** >> > -- > Brandon Svec > 15106862204 voice | fax | sms > > teamonesolutions.com > 14729 Catalina St. San Leandro, CA 94577 > > .ılı.ılı. Cisco Meraki CMNA > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Fri Jul 12 01:44:46 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 11 Jul 2019 20:44:46 -0500 (CDT) Subject: Time and Timing Servers In-Reply-To: References: Message-ID: <1337452689.564.1562895882412.JavaMail.mhammett@ThunderFuck> Sure. They have a BITS service. I'm just checking out all of my options. It'd be nice to have my own stuff, but that may not be feasible (or possible once CDMA goes away). Are any of you coloed with Frontier? Have you gotten them to let you install a GPS antenna? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: keith at contoocook.net To: "Karsten Elfenbein" , "Mike Hammett" Cc: "NANOG" Sent: Thursday, July 11, 2019 3:49:35 PM Subject: Re: Time and Timing Servers I know that many places hosting telecom gear provide "BITS Clock" this is a DS1 with timing. Ask about that, it's an alternative to providing your own. ----- Original Message ----- From: "Karsten Elfenbein" To: "Mike Hammett" Sent: Thursday, July 11 2019 03:22:01 PM Subject: Re: Time and Timing Servers I think you are referencing their chip scale atomic clocks. Which are very frequency stable. But still need phase alignment. (Mobile UPS anyone?) Maybe some peers can provide transparent or boundry clock support. Or someone close by in the DC can add an antenna splitter. Karsten Mike Hammett < nanog at ics-il.net > s chrieb am Do., 11. Juli 2019, 16:31: There were a lot of NTP threads several weeks ago, but I didn't get an answer to my question amongst all of the other chatter. I'm looking for a device that can receive GPS inside a building without the assistance of an external antenna (Frontier says they no longer allow external antenna), will provide traditional NTP services, and will provide a timing signal that my Metaswitch can work with. I know that MicroSemi via Symmetricom makes these kinds of devices, but I'm hoping to look at multiple manufacturers and compare. Thanks. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at packetflux.com Fri Jul 12 04:42:33 2019 From: lists at packetflux.com (Forrest Christian (List Account)) Date: Thu, 11 Jul 2019 22:42:33 -0600 Subject: Time and Timing Servers In-Reply-To: <1160193036.296.1562858615650.JavaMail.mhammett@ThunderFuck> References: <279130447.155.1562855203570.JavaMail.mhammett@ThunderFuck> <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> <20190711145426.GA11465@puck.nether.net> <1160193036.296.1562858615650.JavaMail.mhammett@ThunderFuck> Message-ID: A couple of thoughts here: 1) I know at some sites there is an external, shared, GPS antenna which is run through a distribution amplifier to clients. Worth checking into just in case it exists and they forgot to offer it to you. 2) Do you have any specs on what you need for the TDM clock? If you don't have GPS or any other reasonable way to discipline your local clock you could conceivably get an accurate freerunning clock and use that. However, if this is even possible is going to be based on the accuracy/precision needed for the clock. The spec should be something like 10E-11 or something like that, possibly with jitter or other specs specified as well. The more accurate, the fewer options you will have and the more it will cost. If you only need 10E-6, you can do this dirt cheap. If you need 10E-13, you're going to need a Cesium clock which will set you back a good five figures (and then some). 3) Do you have spare, dark fiber or perhaps even a WDM color to somewhere you can get GPS? Copper might even work depending on the needs of the switch. The thought here is if you have a stable, non-packetized link to somewhere with GPS you then have quite a few options for transferring time back to the site. I agree with you that NTP time transfer isn't probably accurate enough by itself to discipline a clock for TDM... of course depending on the exact needs. On Thu, Jul 11, 2019 at 9:25 AM Mike Hammett wrote: > I'll look into Meinberg. > > I recent thread mentioned high-sensitivity receivers often allow GPS to > work inside. Obviously "inside" has a lot of definitions. > > I will need this facility for the TDM timing signals. It's a central > office, not a datacenter. > > I don't know that Internet-based NTP would be accurate enough for the > timing signals that I need. Maybe, maybe not. > > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Majdi S. Abbas" > *To: *"Mike Hammett" > *Cc: *nanog at nanog.org > *Sent: *Thursday, July 11, 2019 9:54:26 AM > *Subject: *Re: Time and Timing Servers > > On Thu, Jul 11, 2019 at 09:29:46AM -0500, Mike Hammett wrote: > > There were a lot of NTP threads several weeks ago, but I didn't get an > answer to my question amongst all of the other chatter. > > > > I'm looking for a device that can receive GPS inside a building without > the > > assistance of an external antenna (Frontier says they no longer allow > > external antenna), will provide traditional NTP services, and will > provide > > a timing signal that my Metaswitch can work with. > > Unfortunately, L band satellite signals are incredibly weak by > the time they reach the surface. It's very unlikely this is going to > work for you (unless it's a wood framed single story building.) > > Generally, I try to ensure that a GNSS antenna is built into the > contract, to avoid games like this. > > You have two options: > > A) Find a new colocation provider. This may already be on your > to-do list for other reasons. > > B) Rely on the Internet for timing, using NTP or PTP from > another location to backfeed the site, and use a box with a good > stable oscillator to keep time (this can actually be a commercial > time server with decent holdover characteristics. > > If you're just looking for alternatives to Microsemi, I highly > recommend talking to the fine folks at Meinberg. > > --msa > > -- - Forrest -------------- next part -------------- An HTML attachment was scrubbed... URL: From mansaxel at besserwisser.org Fri Jul 12 05:10:57 2019 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Fri, 12 Jul 2019 07:10:57 +0200 Subject: Time and Timing Servers In-Reply-To: <1160193036.296.1562858615650.JavaMail.mhammett@ThunderFuck> References: <279130447.155.1562855203570.JavaMail.mhammett@ThunderFuck> <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> <20190711145426.GA11465@puck.nether.net> <1160193036.296.1562858615650.JavaMail.mhammett@ThunderFuck> Message-ID: <20190712051056.GH10950@besserwisser.org> Subject: Re: Time and Timing Servers Date: Thu, Jul 11, 2019 at 10:23:41AM -0500 Quoting Mike Hammett (nanog at ics-il.net): > I'll look into Meinberg. Meinberg are nice people with good hardware. They can do 2048KHz from GPS and other timing signals, for instance. Then again, some router vendors do that in boxes you need anyway. As long as the controlling clock is PTP. > I recent thread mentioned high-sensitivity receivers often allow GPS to work inside. Obviously "inside" has a lot of definitions. Indeed. Colo buildings rarely are on the forgiving side of "inside". In Sweden, most older central offices are built to some degree of bomb proofness (certainly not safe from direct hit) , with some 10mm of steel in shutters for all windows, etc. GPS fares not well there. > I will need this facility for the TDM timing signals. It's a central office, not a datacenter. Then you're concerned with frequency and phase to ITU-T G.812, I suspect. Unless this is your "central central" office, in which case you need G.811. > I don't know that Internet-based NTP would be accurate enough for the timing signals that I need. Maybe, maybe not. The current trend in today's large frequency/phase consumers, ie. mobile, is to run PTP over backhaul. Well behaved NTP _could_ make it, I suspect, given a good enough clock in the facility, but PTP will definitely work, assuming you have transmission and hardware capable of doing it. "Capable" here, means dark fibre or WDM is required together with routers and switches that can act as boundaries in PTP sense. If you rent MPLS or are using plain Internet infrastructure, it becomes a lot more complicated. There are frequency/phase transmission solutions (mostly broadcast related) that easily can transfer your central central cæsium clock frequency to another site using reasonable-quality IP transport, but those are neither cheap nor fire-and-forget. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 I'm gliding over a NUCLEAR WASTE DUMP near ATLANTA, Georgia!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mansaxel at besserwisser.org Fri Jul 12 05:39:47 2019 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Fri, 12 Jul 2019 07:39:47 +0200 Subject: Time and Timing Servers In-Reply-To: References: <279130447.155.1562855203570.JavaMail.mhammett@ThunderFuck> <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> Message-ID: <20190712053946.GI10950@besserwisser.org> Subject: Re: Time and Timing Servers Date: Thu, Jul 11, 2019 at 09:11:13PM +0200 Quoting Karsten Elfenbein (karsten.elfenbein at gmail.com): > I think you are referencing their chip scale atomic clocks. Which are very > frequency stable. But still need phase alignment. (Mobile UPS anyone?) This is not a new problem. http://www.leapsecond.com/hpj/v15n11/ Fascinating reading. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 YOW!! Now I understand advanced MICROBIOLOGY and th' new TAX REFORM laws!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From Francois.Lecavalier at mindgeek.com Fri Jul 12 15:22:34 2019 From: Francois.Lecavalier at mindgeek.com (Francois Lecavalier) Date: Fri, 12 Jul 2019 15:22:34 +0000 Subject: bgpview.io data source Message-ID: Anyone knows where bgpview.io gets its data from? We have a BGP session with the routeviews project and qrator but bgpview.io still doesn't get the whole picture of our network. This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier ?lectronique est confidentiel et prot?g?. L'exp?diteur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) d?sign?(s) est interdite. Si vous recevez ce courrier ?lectronique par erreur, veuillez m'en aviser imm?diatement, par retour de courrier ?lectronique ou par un autre moyen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Jul 12 18:04:02 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 13 Jul 2019 04:04:02 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190712180402.94BC0C44A1@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 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 13 Jul, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 761180 Prefixes after maximum aggregation (per Origin AS): 293683 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 366839 Total ASes present in the Internet Routing Table: 64866 Prefixes per ASN: 11.73 Origin-only ASes present in the Internet Routing Table: 55778 Origin ASes announcing only one prefix: 23989 Transit ASes present in the Internet Routing Table: 9088 Transit-only ASes present in the Internet Routing Table: 273 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 42 Max AS path prepend of ASN ( 22394) 37 Prefixes from unregistered ASNs in the Routing Table: 25 Number of instances of unregistered ASNs: 26 Number of 32-bit ASNs allocated by the RIRs: 27802 Number of 32-bit ASNs visible in the Routing Table: 22729 Prefixes from 32-bit ASNs in the Routing Table: 102887 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 240 Number of addresses announced to Internet: 2839111680 Equivalent to 169 /8s, 57 /16s and 104 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.3 Total number of prefixes smaller than registry allocations: 253134 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 205697 Total APNIC prefixes after maximum aggregation: 61433 APNIC Deaggregation factor: 3.35 Prefixes being announced from the APNIC address blocks: 201225 Unique aggregates announced from the APNIC address blocks: 84136 APNIC Region origin ASes present in the Internet Routing Table: 9904 APNIC Prefixes per ASN: 20.32 APNIC Region origin ASes announcing only one prefix: 2770 APNIC Region transit ASes present in the Internet Routing Table: 1482 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4904 Number of APNIC addresses announced to Internet: 771115264 Equivalent to 45 /8s, 246 /16s and 73 /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-141625 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: 226145 Total ARIN prefixes after maximum aggregation: 105748 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 225278 Unique aggregates announced from the ARIN address blocks: 107103 ARIN Region origin ASes present in the Internet Routing Table: 18523 ARIN Prefixes per ASN: 12.16 ARIN Region origin ASes announcing only one prefix: 6879 ARIN Region transit ASes present in the Internet Routing Table: 1908 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2799 Number of ARIN addresses announced to Internet: 1067629184 Equivalent to 63 /8s, 162 /16s and 186 /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-399260 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, 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: 210213 Total RIPE prefixes after maximum aggregation: 99783 RIPE Deaggregation factor: 2.11 Prefixes being announced from the RIPE address blocks: 206369 Unique aggregates announced from the RIPE address blocks: 123042 RIPE Region origin ASes present in the Internet Routing Table: 26224 RIPE Prefixes per ASN: 7.87 RIPE Region origin ASes announcing only one prefix: 11597 RIPE Region transit ASes present in the Internet Routing Table: 3740 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 35 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8271 Number of RIPE addresses announced to Internet: 720591744 Equivalent to 42 /8s, 243 /16s and 91 /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-210331 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: 97530 Total LACNIC prefixes after maximum aggregation: 22349 LACNIC Deaggregation factor: 4.36 Prefixes being announced from the LACNIC address blocks: 98815 Unique aggregates announced from the LACNIC address blocks: 43026 LACNIC Region origin ASes present in the Internet Routing Table: 8624 LACNIC Prefixes per ASN: 11.46 LACNIC Region origin ASes announcing only one prefix: 2287 LACNIC Region transit ASes present in the Internet Routing Table: 1580 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 39 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 6175 Number of LACNIC addresses announced to Internet: 173755392 Equivalent to 10 /8s, 91 /16s and 76 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 21569 Total AfriNIC prefixes after maximum aggregation: 4349 AfriNIC Deaggregation factor: 4.96 Prefixes being announced from the AfriNIC address blocks: 29253 Unique aggregates announced from the AfriNIC address blocks: 9320 AfriNIC Region origin ASes present in the Internet Routing Table: 1301 AfriNIC Prefixes per ASN: 22.49 AfriNIC Region origin ASes announcing only one prefix: 456 AfriNIC Region transit ASes present in the Internet Routing Table: 253 Average AfriNIC Region AS path length visible: 5.0 Max AfriNIC Region AS path length visible: 27 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 580 Number of AfriNIC addresses announced to Internet: 105781248 Equivalent to 6 /8s, 78 /16s and 24 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 45/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 7545 4821 574 554 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3188 1459 31 VIETEL-AS-AP Viettel Group, VN 45899 3052 1765 114 VNPT-AS-VN VNPT Corp, VN 9808 2765 9043 63 CMNET-GD Guangdong Mobile Communication 9829 2696 1489 562 BSNL-NIB National Internet Backbone, IN 4766 2507 11118 759 KIXS-AS-KR Korea Telecom, KR 4755 2143 427 182 TATACOMM-AS TATA Communications formerl 9498 2117 430 198 BBIL-AP BHARTI Airtel Ltd., IN 9394 2080 4898 27 CTTNET China TieTong Telecommunications 7713 2058 608 612 TELKOMNET-AS-AP PT Telekomunikasi Indon 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 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3677 240 616 CABLEONE - CABLE ONE, INC., US 6327 3563 1324 90 SHAW - Shaw Communications Inc., CA 22773 3435 2974 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 3023 6386 1415 AMAZON-02 - Amazon.com, Inc., US 16625 2627 1377 1906 AKAMAI-AS - Akamai Technologies, Inc., 30036 2156 347 259 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2151 2762 524 CHARTER-20115 - Charter Communications, 18566 2096 405 107 MEGAPATH5-US - MegaPath Corporation, US 5650 2084 3074 1459 FRONTIER-FRTR - Frontier Communications 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 5455 1629 141 UNI2-AS, ES 39891 3778 203 20 ALJAWWALSTC-AS, SA 8551 3314 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2700 514 1929 AKAMAI-ASN1, US 12389 2339 2226 658 ROSTELECOM-AS, RU 34984 2096 344 547 TELLCOM-AS, TR 9009 1631 176 879 M247, GB 9121 1616 1692 19 TTNET, TR 13188 1604 100 47 TRIOLAN, UA 61317 1469 154 516 ASDETUK http://www.heficed.com, GB 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 6236 3367 599 Uninet S.A. de C.V., MX 10620 3407 535 435 Telmex Colombia S.A., CO 11830 2695 370 54 Instituto Costarricense de Electricidad 7303 1475 1021 274 Telecom Argentina S.A., AR 6503 1216 425 54 Axtel, S.A.B. de C.V., MX 28573 1164 2225 207 CLARO S.A., BR 6147 1096 377 31 Telefonica del Peru S.A.A., PE 3816 1044 525 115 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 976 470 242 Mega Cable, S.A. de C.V., MX 11172 935 112 60 Alestra, S. de R.L. de C.V., MX 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 1187 393 22 LINKdotNET-AS, EG 37611 970 107 9 Afrihost, ZA 24835 885 634 22 RAYA-AS, EG 36903 842 423 114 MT-MPLS, MA 36992 815 1531 88 ETISALAT-MISR, EG 8452 660 1859 20 TE-AS TE-AS, EG 29571 516 68 11 ORANGE-COTE-IVOIRE, CI 37492 482 470 57 ORANGE-, TN 37342 405 32 1 MOVITEL, MZ 15399 386 45 11 WANANCHI-, KE 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 8151 6236 3367 599 Uninet S.A. de C.V., MX 12479 5455 1629 141 UNI2-AS, ES 7545 4821 574 554 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 203 20 ALJAWWALSTC-AS, SA 11492 3677 240 616 CABLEONE - CABLE ONE, INC., US 6327 3563 1324 90 SHAW - Shaw Communications Inc., CA 22773 3435 2974 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3407 535 435 Telmex Colombia S.A., CO 8551 3314 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5455 5314 UNI2-AS, ES 7545 4821 4267 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 4039 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3778 3758 ALJAWWALSTC-AS, SA 6327 3563 3473 SHAW - Shaw Communications Inc., CA 22773 3435 3277 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3314 3268 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3188 3157 VIETEL-AS-AP Viettel Group, VN 11492 3677 3061 CABLEONE - CABLE ONE, INC., US 10620 3407 2972 Telmex Colombia S.A., CO 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 260984 UNALLOCATED 45.175.186.0/23 16735 ALGAR TELECOM S/A, BR 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US 64355 UNALLOCATED 156.40.196.0/24 30387 NIH-NET-NCCS - National Instit 64011 UNALLOCATED 166.133.128.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& 64011 UNALLOCATED 166.133.192.0/18 20057 ATT-MOBILITY-LLC-AS20057 - AT& Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 36.255.24.0/24 40676 AS40676 - Psychz Networks, US 36.255.25.0/24 40676 AS40676 - Psychz Networks, US 36.255.26.0/24 40676 AS40676 - Psychz Networks, US 36.255.27.0/24 40676 AS40676 - Psychz Networks, US 41.76.136.0/22 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:10 /9:11 /10:37 /11:100 /12:294 /13:569 /14:1134 /15:1907 /16:13270 /17:8021 /18:13945 /19:25842 /20:40342 /21:47223 /22:95223 /23:77058 /24:435307 /25:887 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4406 5455 UNI2-AS, ES 6327 3352 3563 SHAW - Shaw Communications Inc., CA 7155 3156 4064 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 3778 ALJAWWALSTC-AS, SA 11492 2880 3677 CABLEONE - CABLE ONE, INC., US 8551 2767 3314 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2668 3435 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2043 2695 Instituto Costarricense de Electricidad y Telec 18566 1991 2096 MEGAPATH5-US - MegaPath Corporation, US 30036 1907 2156 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1709 2:1072 3:6 4:20 5:3084 6:46 7:2 8:1341 9:1 12:1802 13:378 14:2067 15:38 16:7 17:259 18:79 20:56 23:2821 24:2578 25:4 27:2432 31:2012 32:101 35:37 36:885 37:3072 38:1772 39:293 40:121 41:3195 42:828 43:2094 44:153 45:8799 46:3366 47:263 49:1350 50:1110 51:337 52:1011 54:279 55:678 56:6 57:46 58:1763 59:1095 60:547 61:2177 62:1960 63:1864 64:4989 65:2215 66:4830 67:2774 68:1177 69:3553 70:1397 71:656 72:2637 74:2723 75:1294 76:570 77:1799 78:1866 79:2355 80:1837 81:1495 82:1135 83:945 84:1128 85:2301 86:556 87:1548 88:1048 89:2573 90:213 91:6612 92:1444 93:2479 94:2474 95:3330 96:946 97:340 98:961 99:793 100:88 101:1185 102:655 103:21702 104:3634 105:267 106:810 107:1767 108:690 109:3785 110:1720 111:2015 112:1529 113:1389 114:1240 115:1730 116:1760 117:1937 118:2178 119:1644 120:1056 121:1053 122:2269 123:1793 124:1505 125:2023 128:1360 129:830 130:552 131:1815 132:765 133:222 134:1090 135:250 136:589 137:790 138:2100 139:904 140:609 141:892 142:770 143:1057 144:880 145:276 146:1306 147:840 148:1718 149:1001 150:784 151:1015 152:1095 153:338 154:4412 155:884 156:1653 157:1045 158:662 159:1948 160:1606 161:936 162:2960 163:830 164:1250 165:1496 166:478 167:1411 168:3447 169:898 170:4152 171:613 172:1665 173:2219 174:1039 175:981 176:2382 177:4050 178:2565 179:1385 180:2136 181:2354 182:2725 183:1101 184:2278 185:15335 186:3625 187:2506 188:2951 189:1996 190:8221 191:1438 192:10080 193:6753 194:5507 195:4161 196:3008 197:1729 198:5936 199:5974 200:7096 201:5114 202:10406 203:10186 204:4555 205:3062 206:3263 207:3244 208:3940 209:4287 210:3929 211:2022 212:3119 213:2977 214:1119 215:55 216:5901 217:2231 218:884 219:609 220:1901 221:975 222:979 223:1391 End of report From list-nanog at beufa.net Fri Jul 12 19:59:18 2019 From: list-nanog at beufa.net (Fabien VINCENT (NaNOG)) Date: Fri, 12 Jul 2019 21:59:18 +0200 Subject: bgpview.io data source In-Reply-To: References: Message-ID: <0d5e2eb1a459e0cb93ed323d4e5cec03@beufa.net> Le 2019-07-12 17:22, Francois Lecavalier a écrit : > Anyone knows where bgpview.io gets its data from? > > We have a BGP session with the routeviews project and qrator but bgpview.io still doesn't get the whole picture of our network. > > This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen. Did you look if there's any difference between API and WebGui ? I saw in the past some difference due to some sort of WebCache -- FABIEN VINCENT _ at beufanet_ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Jul 15 15:18:44 2019 From: jcurran at arin.net (John Curran) Date: Mon, 15 Jul 2019 15:18:44 +0000 Subject: Interested in helping to lead ARIN? (was: [arin-announce] 2019 Call for ARIN Board of Trustees, ARIN Advisory Council, and NRO Number Council Nominations) References: <45ed2c3e-6b73-fab8-78d5-9472f9fef88f@arin.net> Message-ID: NANOGers - ARIN’s Nomination Committee is seeking suitable individuals to run for the ARIN Board of Trustees, ARIN Advisory Council, and NRO Number Council. If you have any interest in doing so, or are aware of others who might wish to, there is additional information on the requirements and application process below. Thanks! /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN > Subject: [arin-announce] 2019 Call for ARIN Board of Trustees, ARIN Advisory Council, and NRO Number Council Nominations Date: 15 July 2019 at 11:06:12 AM EDT To: > Nominations are being accepted now through 5:00 PM ET, Thursday, 22 August 2019, to fill two seats on the ARIN Board of Trustees, five seats on the ARIN Advisory Council, and one seat on the Number Resource Organization Number Council (NRO NC). Candidates are expected to serve three-year terms effective 1 January 2020 and incumbents may be re-elected for consecutive terms. ARIN Trustees and representatives from ARIN’s General Members in Good Standing are welcome and strongly encouraged to nominate candidates for seats on the ARIN Board of Trustees and Advisory Council. A nominator may nominate themselves, a representative from an ARIN Member organization, or from non-member organizations consistent with ARIN election processes and may make up to three nominations per open seat. Any individual, regardless of ARIN Member affiliation, may self-nominate or nominate one or more candidates to fill one seat on the NRO Number Council. Nominees for the NRO Number Council, however, must reside within the ARIN region. Individuals whose terms will conclude on 31 December 2019 are: • ARIN Board of Trustees: Patrick Gilmore and Bill Sandiford • ARIN Advisory Council: Owen DeLong, Alyssa Moore, Tina Morris, Joe Provo, and Alison Wood • NRO Number Council: Jason Schiller To submit a nomination now, please visit: https://www.surveymonkey.com/r/ARIN2019Nominations To review initial requirements, qualifications, and/or responsibilities of the ARIN Board of Trustees, the ARIN Advisory Council, or the NRO NC, please visit the respective page below: ARIN Board of Trustees: https://www.arin.net/about/welcome/board/requirements/ ARIN Advisory Council: https://www.arin.net/about/welcome/ac/requirements/ NRO Number Council: https://www.arin.net/participate/oversight/elections/nronc/#nominee-eligibility-requirements-responsibilities-upon-election All nominees must confirm that they qualify and are willing to serve if elected and that they do not violate the Nomination and Appointment Conflict of Interest List found at: https://www.arin.net/participate/oversight/elections/conflicts/ For detailed information on the ARIN Board of Trustees and Advisory Council nomination processes, please visit: https://www.arin.net/participate/oversight/elections/processes/#nominations For detailed information on the NRO NC nomination processes, please visit: https://www.arin.net/participate/oversight/elections/nronc/#nomination-process The ARIN Board of Trustees and Advisory Council elections have a Nomination Committee (NomCom) that is responsible for identifying, recruiting, and assessing candidates standing for election to the ARIN Board of Trustees and ARIN Advisory Council, in accordance with ARIN Bylaws and the ARIN Election Processes. This year’s NomCom members are: • ARIN Board of Trustees Members o Dan Alexander (NomCom Chair) o Nancy Carter • General Member Volunteers o Kevin Blumberg o Andrew Dul o Andrew Gallo o Byron Holland o David Huberman For more information on ARIN’s NomCom, please visit: https://www.arin.net/about/welcome/board/committees/#2019-nomination-committee-nomcom 2019 ARIN Elections will take place online from 31 October through 8 November. To vote in this year’s elections, an ARIN Member organization must be a General Member in Good Standing and have a Voting Contact with an ARIN Online account on file by Monday, 16 September 2019, the published voter eligibility deadline. For step-by-step instructions on how to designate a Voting Contact, please visit: https://www.arin.net/participate/oversight/membership/voting/#designating-a-voting-contact For questions, to confirm your organization’s voting eligibility, or for additional information or assistance, please email the ARIN Member Services team at members at arin.net. Regards, Wendy Leedy Member Engagement Specialist American Registry for Internet Numbers (ARIN) Key Election Date Reminders: 15 July – 22 August: Call for ARIN Board of Trustees, ARIN Advisory Council, and NRO NC Nominations 16 September: Deadline to Establish Voter Eligibility 31 October – 8 November: ARIN Elections Open _______________________________________________ ARIN-Announce -------------- next part -------------- An HTML attachment was scrubbed... URL: From jra at baylink.com Mon Jul 15 19:02:39 2019 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 15 Jul 2019 19:02:39 +0000 (UTC) Subject: Time and Timing Servers In-Reply-To: <20190711145831.GB11465@puck.nether.net> References: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> <844197431.270.1562856643573.JavaMail.mhammett@ThunderFuck> <20190711145831.GB11465@puck.nether.net> Message-ID: <284087122.764449.1563217359505.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Majdi S. Abbas" > Not only are you dependant on Sprint if you go that route > (Verizon is already pulling the plug on CDMA this year.), it was never > any better than +/- 10 ms or so. You can get that via NTP pointed at > the Internet. Oh, is *that* why Tracfone's telling it's customers to get new phones by December... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Mon Jul 15 19:07:12 2019 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 15 Jul 2019 19:07:12 +0000 (UTC) Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> Message-ID: <1394695366.764492.1563217632200.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Christopher Morrow" > On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins wrote: >> >> Chris it would be trivial for this to be fixed, nearly overnight, by >> creating some liability on the part of carriers for illicit use of >> caller ID data on behalf of their customers. > > 'illicit use of caller id' - how is caller-id being illicitly used though? > I don't think it's against the law to say a different 'callerid' in the call > session, practically every actual call center does this, right? I can speak to that, having originated calls from a call center. Yes, of course we sent out calls with "spoofed" CNID. But, even though only 2 or 3 or our 5 carriers* held *our* feet to the fire, we held the clients' feet to the fire, requiring them to prove to our satisfaction that they had adminstrative control over the numbers in question. But it's the carrier's responsibility, properly, to do that work. [ It was, IIRC, Verizon, Qwest and maybe Sprint that forced the issue with us; at least two carriers did not. No longer recalll which ones. ] Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Mon Jul 15 19:10:23 2019 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 15 Jul 2019 19:10:23 +0000 (UTC) Subject: Time and Timing Servers In-Reply-To: References: <279130447.155.1562855203570.JavaMail.mhammett@ThunderFuck> <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> <20190711145426.GA11465@puck.nether.net> <1160193036.296.1562858615650.JavaMail.mhammett@ThunderFuck> Message-ID: <827163535.764547.1563217823663.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Forrest Christian (List Account)" > A couple of thoughts here: > > 1) I know at some sites there is an external, shared, GPS antenna which is > run through a distribution amplifier to clients. Worth checking into just > in case it exists and they forgot to offer it to you. Or, there may be someone else in the facility who *is* "important" enough to justify being permitted a roof antenna, who could put in a DA and share it with you... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From jra at baylink.com Mon Jul 15 20:41:54 2019 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 15 Jul 2019 20:41:54 +0000 (UTC) Subject: Spam Message-ID: <1986194041.765231.1563223314578.JavaMail.zimbra@baylink.com> Someone tell Trevor Walford at ECG in Valdosta that scraping the list for addresses to spam is a suboptimal approach? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From bruns at 2mbit.com Mon Jul 15 21:28:36 2019 From: bruns at 2mbit.com (Brielle Bruns) Date: Mon, 15 Jul 2019 15:28:36 -0600 Subject: Time and Timing Servers In-Reply-To: <284087122.764449.1563217359505.JavaMail.zimbra@baylink.com> References: <1438219743.162.1562855381650.JavaMail.mhammett@ThunderFuck> <844197431.270.1562856643573.JavaMail.mhammett@ThunderFuck> <20190711145831.GB11465@puck.nether.net> <284087122.764449.1563217359505.JavaMail.zimbra@baylink.com> Message-ID: On 7/15/2019 1:02 PM, Jay R. Ashworth wrote: > ----- Original Message ----- >> From: "Majdi S. Abbas" > >> Not only are you dependant on Sprint if you go that route >> (Verizon is already pulling the plug on CDMA this year.), it was never >> any better than +/- 10 ms or so. You can get that via NTP pointed at >> the Internet. > > Oh, is *that* why Tracfone's telling it's customers to get new phones by > December... > Wonder if that means VZW is planning on increasing coverage, because there are large enough areas of Idaho where I have to turn off LTE on my phone in order to get reliable service (or even functional data service). It gets really old really quick. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From oof1 at students.waikato.ac.nz Mon Jul 15 21:29:53 2019 From: oof1 at students.waikato.ac.nz (Dimeji Fayomi) Date: Tue, 16 Jul 2019 09:29:53 +1200 Subject: Performance metrics used in commercial BGP route optimizers Message-ID: Hi, I'm doing a research on BGP route optimisation and the performance metrics used by commercial route optimizer appliances to select better path to a prefix. I would appreciate any information about the performance metrics used in commercial BGP route optimizers, white papers or any other document that describes how these metrics are measured and collected by commercial route optimizers. Thanks -- Dimeji Fayomi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ryan.Hamel at quadranet.com Tue Jul 16 13:19:10 2019 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Tue, 16 Jul 2019 13:19:10 +0000 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: Message-ID: <76043D9819086BEE.7cd4a211-e067-4734-98f9-ab3a842ca43d@mail.outlook.com> The answers which you seek would be considered secret sauce to these vendors. But you can start at running MTRs through a VRF per carrier only containing a default route, and looking at the results. Ryan On Tue, Jul 16, 2019 at 6:11 AM -0700, "Dimeji Fayomi" > wrote: Hi, I'm doing a research on BGP route optimisation and the performance metrics used by commercial route optimizer appliances to select better path to a prefix. I would appreciate any information about the performance metrics used in commercial BGP route optimizers, white papers or any other document that describes how these metrics are measured and collected by commercial route optimizers. Thanks -- Dimeji Fayomi -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Tue Jul 16 13:23:11 2019 From: beecher at beecher.cc (Tom Beecher) Date: Tue, 16 Jul 2019 09:23:11 -0400 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: <76043D9819086BEE.7cd4a211-e067-4734-98f9-ab3a842ca43d@mail.outlook.com> References: <76043D9819086BEE.7cd4a211-e067-4734-98f9-ab3a842ca43d@mail.outlook.com> Message-ID: The most important metric for a BGP optimizer is how much it physically weighs. That way you'll know if you can carry it to the trash pile yourself, or need to get help so you don't hurt your back. :) On Tue, Jul 16, 2019 at 9:21 AM Ryan Hamel wrote: > The answers which you seek would be considered secret sauce to these > vendors. > > But you can start at running MTRs through a VRF per carrier only > containing a default route, and looking at the results. > > Ryan > > > > On Tue, Jul 16, 2019 at 6:11 AM -0700, "Dimeji Fayomi" < > oof1 at students.waikato.ac.nz> wrote: > > Hi, >> I'm doing a research on BGP route optimisation and the performance >> metrics used by commercial route optimizer appliances to select better path >> to a prefix. >> >> I would appreciate any information about the performance metrics used in >> commercial BGP route optimizers, white papers or any other document that >> describes how these metrics are measured and collected by commercial route >> optimizers. >> >> Thanks >> -- >> Dimeji Fayomi >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Tue Jul 16 13:30:37 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Tue, 16 Jul 2019 16:30:37 +0300 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: Message-ID: On Tue, Jul 16, 2019, 4:11 PM Dimeji Fayomi wrote: > I'm doing a research on BGP route optimisation and the performance metrics > used by commercial route optimizer appliances to select better path to a > prefix. > You may have discovered that already during your research, but just in case: basically, using those optimizers at full throttle is a bad practice and is generally discouraged. A research into the deep-juju of BGP optimization is roughly equivalent to a research about how alcohol may make you a faster driver. I.e. it's fine in academy but you certainly may want to emphasize security considerations in your paper. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.gilmour at gmail.com Tue Jul 16 14:33:00 2019 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 16 Jul 2019 08:33:00 -0600 Subject: Colo in Africa Message-ID: Hi Folks, I work for a Security Analytics org and we're looking to build a small POP in Africa. I am pretty clueless about the region so I was wondering if you could help guide me in the right direction for research? The challenges: 1. Network needs to be able to receive millions of small PPS (as opposed to serving smaller numbers of larger files). 2. Can't be cloud (need bare metal servers / colo). We use the full capacity of each server, all the time. 3. Must have good connectivity to most of the rest of Africa 4. We can initially only have one POP This is not like a normal website that we can just host on "any old provider", the requirements are very different. Is there a good location where we could either rent bare metal servers (something like Internap - preferred) or colocate servers within Africa that can serve most of the region? "Good" is defined as an area with stable connectivity and power, no legal restrictions on things like encryption, and good latency (sub 100ms) to the rest of Africa. Our two closest POPs are in Singapore and The Netherlands, so I'd like something closer to the middle that can serve the rest of Africa. Middle East will be deployed after Africa. I hope this is the right place to ask. Thanks! Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Tue Jul 16 14:49:37 2019 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 16 Jul 2019 09:49:37 -0500 (CDT) Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: Message-ID: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> Most of which are bunk if you and your upstream have appropriate filters. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Töma Gavrichenkov" To: "Dimeji Fayomi" Cc: "NANOG" Sent: Tuesday, July 16, 2019 8:30:37 AM Subject: Re: Performance metrics used in commercial BGP route optimizers On Tue, Jul 16, 2019, 4:11 PM Dimeji Fayomi < oof1 at students.waikato.ac.nz > wrote: I'm doing a research on BGP route optimisation and the performance metrics used by commercial route optimizer appliances to select better path to a prefix. You may have discovered that already during your research, but just in case: basically, using those optimizers at full throttle is a bad practice and is generally discouraged. A research into the deep-juju of BGP optimization is roughly equivalent to a research about how alcohol may make you a faster driver. I.e. it's fine in academy but you certainly may want to emphasize security considerations in your paper. -- Töma
-------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Tue Jul 16 14:53:46 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Tue, 16 Jul 2019 17:53:46 +0300 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> Message-ID: On Tue, Jul 16, 2019, 5:49 PM Mike Hammett wrote: > Most of which are bunk if you and your upstream have appropriate filters. > True, and, while we're at it, it's okay to drink and drive a car if the manufacturer has built enough driver assistance systems in it. -- Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From akshay at mongodb.com Tue Jul 16 14:55:12 2019 From: akshay at mongodb.com (Akshay Kumar) Date: Tue, 16 Jul 2019 15:55:12 +0100 Subject: Colo in Africa In-Reply-To: References: Message-ID: The 2nd requirement seems artificial. The new hypervisors have come a long way and the overhead is minimal. Also you can run bare metal instances in AWS if you really need them with 100Gbps. Just just use the South Africa AWS region. On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour wrote: > Hi Folks, > > I work for a Security Analytics org and we're looking to build a small POP > in Africa. I am pretty clueless about the region so I was wondering if you > could help guide me in the right direction for research? > > The challenges: > > 1. Network needs to be able to receive millions of small PPS (as > opposed to serving smaller numbers of larger files). > 2. Can't be cloud (need bare metal servers / colo). We use the full > capacity of each server, all the time. > 3. Must have good connectivity to most of the rest of Africa > 4. We can initially only have one POP > > This is not like a normal website that we can just host on "any old > provider", the requirements are very different. > > Is there a good location where we could either rent bare metal servers > (something like Internap - preferred) or colocate servers within Africa > that can serve most of the region? > > "Good" is defined as an area with stable connectivity and power, no legal > restrictions on things like encryption, and good latency (sub 100ms) to the > rest of Africa. > > Our two closest POPs are in Singapore and The Netherlands, so I'd like > something closer to the middle that can serve the rest of Africa. Middle > East will be deployed after Africa. > > I hope this is the right place to ask. > > Thanks! > > Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: From savage at savage.za.org Tue Jul 16 15:00:13 2019 From: savage at savage.za.org (Chris Knipe) Date: Tue, 16 Jul 2019 17:00:13 +0200 Subject: Colo in Africa In-Reply-To: References: Message-ID: On Tue, Jul 16, 2019 at 4:57 PM Akshay Kumar via NANOG wrote: > The 2nd requirement seems artificial. The new hypervisors have come a long > way and the overhead is minimal. Also you can run bare metal instances in > AWS if you really need them with 100Gbps. > > Just just use the South Africa AWS region. > > ^^ You had me for a second there. AWS ain't operational yet in South Africa. Sometime 2020/2021 only. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil.lavin at cloudcall.com Tue Jul 16 15:01:13 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Tue, 16 Jul 2019 15:01:13 +0000 Subject: Colo in Africa In-Reply-To: References: Message-ID: > just use the South Africa AWS region They don't have a Region there at present - only an Edge location. I believe one is in the works for launch next year. From Bryan at bryanfields.net Tue Jul 16 15:08:32 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Tue, 16 Jul 2019 11:08:32 -0400 Subject: Colo in Africa In-Reply-To: References: Message-ID: <9a3d89c0-05f1-5673-2e3a-780dcb71e3df@bryanfields.net> On 7/16/19 10:55 AM, Akshay Kumar via NANOG wrote: > The 2nd requirement seems artificial. The new hypervisors have come a long > way and the overhead is minimal. Also you can run bare metal instances in > AWS if you really need them with 100Gbps. Well the man wants bare metal, and while there's arguments for and against it, it's what he wants to buy :) That said, I'm one of those guys that likes owing my own hypervisor, don't need to worry about the side channel/memory/OOO execution attacks from rogue VM's if it's only my VM's on it. Plus AWS ain't cheap either. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From akshay at mongodb.com Tue Jul 16 15:08:58 2019 From: akshay at mongodb.com (Akshay Kumar) Date: Tue, 16 Jul 2019 16:08:58 +0100 Subject: Colo in Africa In-Reply-To: References: Message-ID: My bad. They announced that Oct 2018 so I figured they'd be close to it now. Yeah turns out it's mid 2020 :-( https://aws.amazon.com/blogs/aws/in-the-works-aws-region-in-south-africa/ On Tue, Jul 16, 2019 at 4:02 PM Chris Knipe wrote: > > > On Tue, Jul 16, 2019 at 4:57 PM Akshay Kumar via NANOG > wrote: > >> The 2nd requirement seems artificial. The new hypervisors have come a >> long way and the overhead is minimal. Also you can run bare metal instances >> in AWS if you really need them with 100Gbps. >> >> Just just use the South Africa AWS region. >> >> > ^^ You had me for a second there. AWS ain't operational yet in South > Africa. Sometime 2020/2021 only. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akshay at mongodb.com Tue Jul 16 15:25:46 2019 From: akshay at mongodb.com (Akshay Kumar) Date: Tue, 16 Jul 2019 16:25:46 +0100 Subject: Colo in Africa In-Reply-To: <9a3d89c0-05f1-5673-2e3a-780dcb71e3df@bryanfields.net> References: <9a3d89c0-05f1-5673-2e3a-780dcb71e3df@bryanfields.net> Message-ID: Thanks for chiming in but his reason for can't be cloud was, "We use the full capacity of each server, all the time." That ain't good reason. They do have baremetal servers like I pointed out. We use them when for cases where we need access to perf counters. On Tue, Jul 16, 2019 at 4:10 PM Bryan Fields wrote: > On 7/16/19 10:55 AM, Akshay Kumar via NANOG wrote: > > The 2nd requirement seems artificial. The new hypervisors have come a > long > > way and the overhead is minimal. Also you can run bare metal instances in > > AWS if you really need them with 100Gbps. > > Well the man wants bare metal, and while there's arguments for and against > it, > it's what he wants to buy :) > > That said, I'm one of those guys that likes owing my own hypervisor, don't > need to worry about the side channel/memory/OOO execution attacks from > rogue > VM's if it's only my VM's on it. Plus AWS ain't cheap either. > > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Tue Jul 16 15:28:30 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 16 Jul 2019 11:28:30 -0400 Subject: Colo in Africa In-Reply-To: References: Message-ID: Isn't the OP really asking here (not to have their selection of platform wrangled..): "Where should I target my search: ZA only? is there anywhere else worth dropping my request?" and: "Are there likely providers of solid colo aside from seacom/tinka-net or workonline/ben-net ?" On Tue, Jul 16, 2019 at 11:12 AM Akshay Kumar via NANOG wrote: > > My bad. They announced that Oct 2018 so I figured they'd be close to it now. Yeah turns out it's mid 2020 :-( > > https://aws.amazon.com/blogs/aws/in-the-works-aws-region-in-south-africa/ > > On Tue, Jul 16, 2019 at 4:02 PM Chris Knipe wrote: >> >> >> >> On Tue, Jul 16, 2019 at 4:57 PM Akshay Kumar via NANOG wrote: >>> >>> The 2nd requirement seems artificial. The new hypervisors have come a long way and the overhead is minimal. Also you can run bare metal instances in AWS if you really need them with 100Gbps. >>> >>> Just just use the South Africa AWS region. >>> >> >> ^^ You had me for a second there. AWS ain't operational yet in South Africa. Sometime 2020/2021 only. >> From nanog at ics-il.net Tue Jul 16 15:29:41 2019 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 16 Jul 2019 10:29:41 -0500 (CDT) Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> Message-ID: <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> More like do whatever you want in your own house as long as you don't infringe upon others. The argument against route optimizers (assuming appropriate ingress\egress filters) is a religious one and should be treated as such. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Töma Gavrichenkov" To: "Mike Hammett" Cc: "NANOG" , "Dimeji Fayomi" Sent: Tuesday, July 16, 2019 9:53:46 AM Subject: Re: Performance metrics used in commercial BGP route optimizers On Tue, Jul 16, 2019, 5:49 PM Mike Hammett < nanog at ics-il.net > wrote: Most of which are bunk if you and your upstream have appropriate filters. True, and, while we're at it, it's okay to drink and drive a car if the manufacturer has built enough driver assistance systems in it. -- Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Tue Jul 16 15:30:51 2019 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 16 Jul 2019 10:30:51 -0500 (CDT) Subject: Colo in Africa In-Reply-To: References: Message-ID: <2070661021.3907.1563291046440.JavaMail.mhammett@ThunderFuck> The cloud isn't always the right decision for the end customer. In many cases, it's the worst decision. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Akshay Kumar via NANOG" To: "Ken Gilmour" Cc: "North Group" Sent: Tuesday, July 16, 2019 9:55:12 AM Subject: Re: Colo in Africa The 2nd requirement seems artificial. The new hypervisors have come a long way and the overhead is minimal. Also you can run bare metal instances in AWS if you really need them with 100Gbps. Just just use the South Africa AWS region. On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour < ken.gilmour at gmail.com > wrote: Hi Folks, I work for a Security Analytics org and we're looking to build a small POP in Africa. I am pretty clueless about the region so I was wondering if you could help guide me in the right direction for research? The challenges: 1. Network needs to be able to receive millions of small PPS (as opposed to serving smaller numbers of larger files). 2. Can't be cloud (need bare metal servers / colo). We use the full capacity of each server, all the time. 3. Must have good connectivity to most of the rest of Africa 4. We can initially only have one POP This is not like a normal website that we can just host on "any old provider", the requirements are very different. Is there a good location where we could either rent bare metal servers (something like Internap - preferred) or colocate servers within Africa that can serve most of the region? "Good" is defined as an area with stable connectivity and power, no legal restrictions on things like encryption, and good latency (sub 100ms) to the rest of Africa. Our two closest POPs are in Singapore and The Netherlands, so I'd like something closer to the middle that can serve the rest of Africa. Middle East will be deployed after Africa. I hope this is the right place to ask. Thanks! Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.gilmour at gmail.com Tue Jul 16 15:43:26 2019 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 16 Jul 2019 09:43:26 -0600 Subject: Colo in Africa In-Reply-To: <9a3d89c0-05f1-5673-2e3a-780dcb71e3df@bryanfields.net> References: <9a3d89c0-05f1-5673-2e3a-780dcb71e3df@bryanfields.net> Message-ID: Thanks for all the replies! (really fast!) The requirement for Bare Metal is very specific. Dealing with high speed large files is very different to dealing with high volume small files. We regularly encounter bottlenecks at the FSB and at the IO level. Even things like RAID slows us down, so we have to squeeze every iota of power out of the servers that we can. Plus, most of our customers in Africa use our free version so cost savings are also important, and so is accessibility. On Tue, 16 Jul 2019 at 09:10, Bryan Fields wrote: > On 7/16/19 10:55 AM, Akshay Kumar via NANOG wrote: > > The 2nd requirement seems artificial. The new hypervisors have come a > long > > way and the overhead is minimal. Also you can run bare metal instances in > > AWS if you really need them with 100Gbps. > > Well the man wants bare metal, and while there's arguments for and against > it, > it's what he wants to buy :) > > That said, I'm one of those guys that likes owing my own hypervisor, don't > need to worry about the side channel/memory/OOO execution attacks from > rogue > VM's if it's only my VM's on it. Plus AWS ain't cheap either. > > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.gilmour at gmail.com Tue Jul 16 15:46:06 2019 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 16 Jul 2019 09:46:06 -0600 Subject: Colo in Africa In-Reply-To: References: Message-ID: Bingo On Tue, 16 Jul 2019 at 09:30, Christopher Morrow wrote: > Isn't the OP really asking here (not to have their selection of > platform wrangled..): > "Where should I target my search: ZA only? is there anywhere else > worth dropping my request?" > > and: > "Are there likely providers of solid colo aside from > seacom/tinka-net or workonline/ben-net ?" > > On Tue, Jul 16, 2019 at 11:12 AM Akshay Kumar via NANOG > wrote: > > > > My bad. They announced that Oct 2018 so I figured they'd be close to it > now. Yeah turns out it's mid 2020 :-( > > > > > https://aws.amazon.com/blogs/aws/in-the-works-aws-region-in-south-africa/ > > > > On Tue, Jul 16, 2019 at 4:02 PM Chris Knipe > wrote: > >> > >> > >> > >> On Tue, Jul 16, 2019 at 4:57 PM Akshay Kumar via NANOG > wrote: > >>> > >>> The 2nd requirement seems artificial. The new hypervisors have come a > long way and the overhead is minimal. Also you can run bare metal instances > in AWS if you really need them with 100Gbps. > >>> > >>> Just just use the South Africa AWS region. > >>> > >> > >> ^^ You had me for a second there. AWS ain't operational yet in South > Africa. Sometime 2020/2021 only. > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.gilmour at gmail.com Tue Jul 16 16:11:48 2019 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 16 Jul 2019 10:11:48 -0600 Subject: Colo in Africa In-Reply-To: References: Message-ID: Speed is not the issue, it's IO. Also streaming 100Gbps of video is very different to streaming 100Gbps of files smaller than 100kb (average of about 30kb) the issue on the network level is the number of connections and CPU, on the server side it's IO and FSB On Tue, 16 Jul 2019 at 08:55, Akshay Kumar wrote: > The 2nd requirement seems artificial. The new hypervisors have come a long > way and the overhead is minimal. Also you can run bare metal instances in > AWS if you really need them with 100Gbps. > > Just just use the South Africa AWS region. > > On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour wrote: > >> Hi Folks, >> >> I work for a Security Analytics org and we're looking to build a small >> POP in Africa. I am pretty clueless about the region so I was wondering if >> you could help guide me in the right direction for research? >> >> The challenges: >> >> 1. Network needs to be able to receive millions of small PPS (as >> opposed to serving smaller numbers of larger files). >> 2. Can't be cloud (need bare metal servers / colo). We use the full >> capacity of each server, all the time. >> 3. Must have good connectivity to most of the rest of Africa >> 4. We can initially only have one POP >> >> This is not like a normal website that we can just host on "any old >> provider", the requirements are very different. >> >> Is there a good location where we could either rent bare metal servers >> (something like Internap - preferred) or colocate servers within Africa >> that can serve most of the region? >> >> "Good" is defined as an area with stable connectivity and power, no legal >> restrictions on things like encryption, and good latency (sub 100ms) to the >> rest of Africa. >> >> Our two closest POPs are in Singapore and The Netherlands, so I'd like >> something closer to the middle that can serve the rest of Africa. Middle >> East will be deployed after Africa. >> >> I hope this is the right place to ask. >> >> Thanks! >> >> Ken >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joelja at bogus.com Tue Jul 16 16:23:02 2019 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 16 Jul 2019 09:23:02 -0700 Subject: Colo in Africa In-Reply-To: References: Message-ID: <0B1FB931-4A97-4AE2-AFBD-06829BFA7315@bogus.com> > On Jul 16, 2019, at 07:33, Ken Gilmour wrote: > > Hi Folks, > > I work for a Security Analytics org and we're looking to build a small POP in Africa. I am pretty clueless about the region so I was wondering if you could help guide me in the right direction for research? > > The challenges: > Network needs to be able to receive millions of small PPS (as opposed to serving smaller numbers of larger files). > Can't be cloud (need bare metal servers / colo). We use the full capacity of each server, all the time. > Must have good connectivity to most of the rest of Africa > We can initially only have one POP > This is not like a normal website that we can just host on "any old provider", the requirements are very different. > > Is there a good location where we could either rent bare metal servers (something like Internap - preferred) or colocate servers within Africa that can serve most of the region? > > "Good" is defined as an area with stable connectivity and power, no legal restrictions on things like encryption, and good latency (sub 100ms) to the rest of Africa. 100ms from most of the rest of Africa is going to be a bit dubious. If you draw a line horizontally through Senegal the costal stuff north of it can mostly be served in under 100ms from Europe. While cross border terrestrial fiber exists most networks I’ve been exposed to have east west and north south connectivity Via submarine connected networks. This make it hard to locate one low latency spot in the middle. NSRC has a project that can provide some background on terrestrial fiber. https://afterfibre.nsrc.org/ The next best place to my mind for reach east and west is South Africa where you can pick up something of a diversity of transit find decent colo and pick up a few out of region peers if you locate near jinx or cinx which are both multi building connected exchanges. > Our two closest POPs are in Singapore and The Netherlands, so I'd like something closer to the middle that can serve the rest of Africa. Middle East will be deployed after Africa. > > I hope this is the right place to ask. > > Thanks! > > Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From gr at ham.ie Tue Jul 16 15:17:18 2019 From: gr at ham.ie (Graham Hayes) Date: Tue, 16 Jul 2019 16:17:18 +0100 Subject: Colo in Africa In-Reply-To: References: Message-ID: On 16/07/2019 16:08, Akshay Kumar via NANOG wrote: > My bad. They announced that Oct 2018 so I figured they'd be close to it > now. Yeah turns out it's mid 2020 :-( > > https://aws.amazon.com/blogs/aws/in-the-works-aws-region-in-south-africa/ > Azure does have regions in operation in South Africa [1] 1 - https://azure.microsoft.com/en-in/global-infrastructure/services/?products=kubernetes-service,virtual-machines > On Tue, Jul 16, 2019 at 4:02 PM Chris Knipe > wrote: > > > > On Tue, Jul 16, 2019 at 4:57 PM Akshay Kumar via NANOG > > wrote: > > The 2nd requirement seems artificial. The new hypervisors have > come a long way and the overhead is minimal. Also you can run > bare metal instances in AWS if you really need them with 100Gbps. > > Just just use the South Africa AWS region. > > > ^^ You had me for a second there.  AWS ain't operational yet in > South Africa.  Sometime 2020/2021 only. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From akshay at mongodb.com Tue Jul 16 16:33:42 2019 From: akshay at mongodb.com (Akshay Kumar) Date: Tue, 16 Jul 2019 17:33:42 +0100 Subject: Colo in Africa In-Reply-To: References: Message-ID: Go look at the actual specifications for one of the metal boxes - you are not going to come close to maxing anything out with the workload you describe. FSB hasn't been a thing in over a decade. If you really wanted to go crazy you could do some build a custom solution in FPGA on the F1s. It's a moot point since none of this is going to be available in time but perf is a bogus reason and a lot of the times price is too. On Tue, Jul 16, 2019 at 5:12 PM Ken Gilmour wrote: > Speed is not the issue, it's IO. Also streaming 100Gbps of video is very > different to streaming 100Gbps of files smaller than 100kb (average of > about 30kb) the issue on the network level is the number of connections and > CPU, on the server side it's IO and FSB > > On Tue, 16 Jul 2019 at 08:55, Akshay Kumar wrote: > >> The 2nd requirement seems artificial. The new hypervisors have come a >> long way and the overhead is minimal. Also you can run bare metal instances >> in AWS if you really need them with 100Gbps. >> >> Just just use the South Africa AWS region. >> >> On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour >> wrote: >> >>> Hi Folks, >>> >>> I work for a Security Analytics org and we're looking to build a small >>> POP in Africa. I am pretty clueless about the region so I was wondering if >>> you could help guide me in the right direction for research? >>> >>> The challenges: >>> >>> 1. Network needs to be able to receive millions of small PPS (as >>> opposed to serving smaller numbers of larger files). >>> 2. Can't be cloud (need bare metal servers / colo). We use the full >>> capacity of each server, all the time. >>> 3. Must have good connectivity to most of the rest of Africa >>> 4. We can initially only have one POP >>> >>> This is not like a normal website that we can just host on "any old >>> provider", the requirements are very different. >>> >>> Is there a good location where we could either rent bare metal servers >>> (something like Internap - preferred) or colocate servers within Africa >>> that can serve most of the region? >>> >>> "Good" is defined as an area with stable connectivity and power, no >>> legal restrictions on things like encryption, and good latency (sub 100ms) >>> to the rest of Africa. >>> >>> Our two closest POPs are in Singapore and The Netherlands, so I'd like >>> something closer to the middle that can serve the rest of Africa. Middle >>> East will be deployed after Africa. >>> >>> I hope this is the right place to ask. >>> >>> Thanks! >>> >>> Ken >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at 6by7.net Tue Jul 16 16:35:26 2019 From: ben at 6by7.net (Ben Cannon) Date: Tue, 16 Jul 2019 09:35:26 -0700 Subject: Colo in Africa In-Reply-To: References: Message-ID: Have you priced F1 solutions? -Ben Cannon CEO 6x7 Networks & 6x7 Telecom, LLC ben at 6by7.net > On Jul 16, 2019, at 9:33 AM, Akshay Kumar via NANOG wrote: > > Go look at the actual specifications for one of the metal boxes - you are not going to come close to maxing anything out with the workload you describe. FSB hasn't been a thing in over a decade. If you really wanted to go crazy you could do some build a custom solution in FPGA on the F1s. > > It's a moot point since none of this is going to be available in time but perf is a bogus reason and a lot of the times price is too. > > On Tue, Jul 16, 2019 at 5:12 PM Ken Gilmour > wrote: > Speed is not the issue, it's IO. Also streaming 100Gbps of video is very different to streaming 100Gbps of files smaller than 100kb (average of about 30kb) the issue on the network level is the number of connections and CPU, on the server side it's IO and FSB > > On Tue, 16 Jul 2019 at 08:55, Akshay Kumar > wrote: > The 2nd requirement seems artificial. The new hypervisors have come a long way and the overhead is minimal. Also you can run bare metal instances in AWS if you really need them with 100Gbps. > > Just just use the South Africa AWS region. > > On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour > wrote: > Hi Folks, > > I work for a Security Analytics org and we're looking to build a small POP in Africa. I am pretty clueless about the region so I was wondering if you could help guide me in the right direction for research? > > The challenges: > Network needs to be able to receive millions of small PPS (as opposed to serving smaller numbers of larger files). > Can't be cloud (need bare metal servers / colo). We use the full capacity of each server, all the time. > Must have good connectivity to most of the rest of Africa > We can initially only have one POP > This is not like a normal website that we can just host on "any old provider", the requirements are very different. > > Is there a good location where we could either rent bare metal servers (something like Internap - preferred) or colocate servers within Africa that can serve most of the region? > > "Good" is defined as an area with stable connectivity and power, no legal restrictions on things like encryption, and good latency (sub 100ms) to the rest of Africa. > > Our two closest POPs are in Singapore and The Netherlands, so I'd like something closer to the middle that can serve the rest of Africa. Middle East will be deployed after Africa. > > I hope this is the right place to ask. > > Thanks! > > Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.gilmour at gmail.com Tue Jul 16 16:39:59 2019 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 16 Jul 2019 10:39:59 -0600 Subject: Colo in Africa In-Reply-To: References: Message-ID: These are actual real problems we face. thousands of customers load and reload TBs of data every few seconds on their dashboards. We have busy servers. We tried cloud. I passionately hate it. We choose to use Bare Metal. On Tue, 16 Jul 2019 at 10:34, Akshay Kumar wrote: > Go look at the actual specifications for one of the metal boxes - you are > not going to come close to maxing anything out with the workload you > describe. FSB hasn't been a thing in over a decade. If you really wanted to > go crazy you could do some build a custom solution in FPGA on the F1s. > > It's a moot point since none of this is going to be available in time but > perf is a bogus reason and a lot of the times price is too. > > On Tue, Jul 16, 2019 at 5:12 PM Ken Gilmour wrote: > >> Speed is not the issue, it's IO. Also streaming 100Gbps of video is very >> different to streaming 100Gbps of files smaller than 100kb (average of >> about 30kb) the issue on the network level is the number of connections and >> CPU, on the server side it's IO and FSB >> >> On Tue, 16 Jul 2019 at 08:55, Akshay Kumar wrote: >> >>> The 2nd requirement seems artificial. The new hypervisors have come a >>> long way and the overhead is minimal. Also you can run bare metal instances >>> in AWS if you really need them with 100Gbps. >>> >>> Just just use the South Africa AWS region. >>> >>> On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour >>> wrote: >>> >>>> Hi Folks, >>>> >>>> I work for a Security Analytics org and we're looking to build a small >>>> POP in Africa. I am pretty clueless about the region so I was wondering if >>>> you could help guide me in the right direction for research? >>>> >>>> The challenges: >>>> >>>> 1. Network needs to be able to receive millions of small PPS (as >>>> opposed to serving smaller numbers of larger files). >>>> 2. Can't be cloud (need bare metal servers / colo). We use the full >>>> capacity of each server, all the time. >>>> 3. Must have good connectivity to most of the rest of Africa >>>> 4. We can initially only have one POP >>>> >>>> This is not like a normal website that we can just host on "any old >>>> provider", the requirements are very different. >>>> >>>> Is there a good location where we could either rent bare metal servers >>>> (something like Internap - preferred) or colocate servers within Africa >>>> that can serve most of the region? >>>> >>>> "Good" is defined as an area with stable connectivity and power, no >>>> legal restrictions on things like encryption, and good latency (sub 100ms) >>>> to the rest of Africa. >>>> >>>> Our two closest POPs are in Singapore and The Netherlands, so I'd like >>>> something closer to the middle that can serve the rest of Africa. Middle >>>> East will be deployed after Africa. >>>> >>>> I hope this is the right place to ask. >>>> >>>> Thanks! >>>> >>>> Ken >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Jul 16 16:51:17 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 16 Jul 2019 18:51:17 +0200 Subject: Colo in Africa In-Reply-To: References: Message-ID: On 16/Jul/19 16:33, Ken Gilmour wrote: > Hi Folks, > > I work for a Security Analytics org and we're looking to build a small > POP in Africa. Where, in Africa? It's not a small place... > 1. Network needs to be able to receive millions of small PPS (as > opposed to serving smaller numbers of larger files). > Depending on where in Africa you want to deploy, there will be a choice of service providers. > 1. Can't be cloud (need bare metal servers / colo). We use the full > capacity of each server, all the time. > This is possible, but will depend on where, in Africa, you want to deploy. > 1. Must have good connectivity to most of the rest of Africa > This is a tricky one, but if you know where you want to be, it will help to give you options. > 1. We can initially only have one POP > Not a problem, but where? > This is not like a normal website that we can just host on "any old > provider", the requirements are very different. > > Is there a good location where we could either rent bare metal servers > (something like Internap - preferred) or colocate servers within > Africa that can serve most of the region? Africa is huge, with varying levels of quality of connectivity. The 3 main regions are East Africa (Kenya leading), Southern Africa (South Africa leading) and West Africa (Nigeria and Ghana leading). For North Africa, your options can swing between Egypt and Morocco. But stringing all of these locations together, particularly West and North to East and South, will not be straight forward. > > "Good" is defined as an area with stable connectivity and power, no > legal restrictions on things like encryption, and good latency (sub > 100ms) to the rest of Africa. Yes, all 5 will be difficult at this point in time. For most of that, hosting within Eastern and Southern Africa will be your best bets. West Africa ticks a lot of the boxes, but it's not very straight forward when it comes to co-lo. > > Our two closest POPs are in Singapore and The Netherlands, so I'd like > something closer to the middle that can serve the rest of Africa. > Middle East will be deployed after Africa. Singapore is closer to Eastern & Southern Africa. Will be too far to West Africa unless you want to switch in Europe. The Netherlands is okay for all of Africa. The Middle East is closer to Eastern Africa. Too far for West Africa unless you want to switch in Europe. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Jul 16 16:52:14 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 16 Jul 2019 18:52:14 +0200 Subject: Colo in Africa In-Reply-To: References: Message-ID: On 16/Jul/19 17:01, Phil Lavin wrote: > > They don't have a Region there at present - only an Edge location. I believe one is in the works for launch next year. You're right (as of my updates from last November). Mark. From mark.tinka at seacom.mu Tue Jul 16 16:53:06 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 16 Jul 2019 18:53:06 +0200 Subject: Colo in Africa In-Reply-To: References: Message-ID: <6ff22b87-7cd0-cc43-8518-df3ace158240@seacom.mu> On 16/Jul/19 16:55, Akshay Kumar via NANOG wrote: > The 2nd requirement seems artificial. The new hypervisors have come a > long way and the overhead is minimal. Also you can run bare metal > instances in AWS if you really need them with 100Gbps. That said, there are various providers who can give you bare metal. > > Just just use the South Africa AWS region. There are other local providers that can offer this. They just don't carry the badge. Mark. From mark.tinka at seacom.mu Tue Jul 16 16:54:51 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 16 Jul 2019 18:54:51 +0200 Subject: Colo in Africa In-Reply-To: References: Message-ID: <09af2c69-a7c5-6101-a1dd-9ea81ae6b18e@seacom.mu> On 16/Jul/19 17:08, Akshay Kumar via NANOG wrote: > My bad. They announced that Oct 2018 so I figured they'd be close to > it now. Yeah turns out it's mid 2020 :-( I'd take all targets with a very large grain of salt. Experience has shown that these things always take longer than planned... and then take longer again, after that. There other folk offering servers (bare and virtual) in the region. So if you're not gung-ho on a name brand, you're in luck. Mark. From eric-list at truenet.com Tue Jul 16 16:57:36 2019 From: eric-list at truenet.com (Eric Tykwinski) Date: Tue, 16 Jul 2019 12:57:36 -0400 Subject: Colo in Africa In-Reply-To: References: Message-ID: <040301d53bf7$91ee1d80$b5ca5880$@truenet.com> One of my favorite sites to give people: https://thetruesize.com/ Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300 _____________________________________ From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mark Tinka Sent: Tuesday, July 16, 2019 12:51 PM To: nanog at nanog.org Subject: Re: Colo in Africa Where, in Africa? It's not a small place... From ken.gilmour at gmail.com Tue Jul 16 17:00:49 2019 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 16 Jul 2019 11:00:49 -0600 Subject: Colo in Africa In-Reply-To: References: Message-ID: Hi Mark, Our "market" is actually the US - but we're experiencing unexpected success across the world. A lot of our customers have selected "Africa" as their region when signing up and they are in various countries around Africa, they deserve to be served better within their continent at least. We can't actually build POPs fast enough, so I want to throw as broad a net as possible with our first POP in Africa and then branch out from there. We have customers in South Africa, Tanzania, Nigeria, Egypt, Morocco and Ghana for instance. I have resources for only one POP in Africa currently, need to decide where to best serve as many as possible. We could serve Northern Africa from EU and Southern Africa from Singapore, but having something within the continent would be preferable. Thanks! Ken On Tue, 16 Jul 2019 at 10:52, Mark Tinka wrote: > > > On 16/Jul/19 16:33, Ken Gilmour wrote: > > Hi Folks, > > I work for a Security Analytics org and we're looking to build a small POP > in Africa. > > > Where, in Africa? It's not a small place... > > > > 1. Network needs to be able to receive millions of small PPS (as > opposed to serving smaller numbers of larger files). > > > Depending on where in Africa you want to deploy, there will be a choice of > service providers. > > > > 1. Can't be cloud (need bare metal servers / colo). We use the full > capacity of each server, all the time. > > > This is possible, but will depend on where, in Africa, you want to deploy. > > > > 1. Must have good connectivity to most of the rest of Africa > > > This is a tricky one, but if you know where you want to be, it will help > to give you options. > > > > 1. We can initially only have one POP > > > Not a problem, but where? > > > This is not like a normal website that we can just host on "any old > provider", the requirements are very different. > > Is there a good location where we could either rent bare metal servers > (something like Internap - preferred) or colocate servers within Africa > that can serve most of the region? > > > Africa is huge, with varying levels of quality of connectivity. The 3 main > regions are East Africa (Kenya leading), Southern Africa (South Africa > leading) and West Africa (Nigeria and Ghana leading). > > For North Africa, your options can swing between Egypt and Morocco. > > But stringing all of these locations together, particularly West and North > to East and South, will not be straight forward. > > > > > "Good" is defined as an area with stable connectivity and power, no legal > restrictions on things like encryption, and good latency (sub 100ms) to the > rest of Africa. > > > Yes, all 5 will be difficult at this point in time. > > For most of that, hosting within Eastern and Southern Africa will be your > best bets. > > West Africa ticks a lot of the boxes, but it's not very straight forward > when it comes to co-lo. > > > > > Our two closest POPs are in Singapore and The Netherlands, so I'd like > something closer to the middle that can serve the rest of Africa. Middle > East will be deployed after Africa. > > > Singapore is closer to Eastern & Southern Africa. Will be too far to West > Africa unless you want to switch in Europe. > > The Netherlands is okay for all of Africa. > > The Middle East is closer to Eastern Africa. Too far for West Africa > unless you want to switch in Europe. > > Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Jul 16 17:05:00 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 16 Jul 2019 19:05:00 +0200 Subject: Colo in Africa In-Reply-To: References: Message-ID: <0b2d321f-5af2-0f39-8aaa-e86983bc3ffe@seacom.mu> On 16/Jul/19 17:28, Christopher Morrow wrote: > Isn't the OP really asking here (not to have their selection of > platform wrangled..): > "Where should I target my search: ZA only? is there anywhere else > worth dropping my request?" The easiest regions will be East (Kenya) and South (South Africa). > and: > "Are there likely providers of solid colo aside from > seacom/tinka-net or workonline/ben-net ?" SEACOM and Workonline just do network. For co-lo, we have solid operators in East and South: * Teraco - https://www.teraco.co.za/ - who will give you excellent co-lo in Johannesburg, Cape Town and Durban. * iColo - https://www.icolo.io/ - who will give you excellent co-lo in Mombasa. Nairobi is due to open by September this year. * Raxio - https://www.raxio.co.ug/ - who will give you excellent co-lo in Kampala. Door open in December this year. Teraco run NAPAfrica, which is Africa's largest exchange point by traffic switched - https://www.napafrica.net/. They also have instances of the INX-ZA exchange points, which are JINX (Johannesburg), DINX (Durban) and CINX (Cape Town). iColo will be deploying an instance of KIXP (Kenya IXP) - https://www.tespok.co.ke/?page_id=11648 - and Asteroid - https://www.asteroidhq.com/. Raxio will also host an instance of the UIXP - https://www.uixp.co.ug/. From a network standpoint, you have a few options: * SEACOM - AS37100 * Workonline - AS37271 * Liquid - AS30844 * WIOCC - AS37662 These are the main network operators that run a good deal of network between Europe, Eastern Africa, Southern Africa and parts of Asia-Pac. Hope this helps. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Tue Jul 16 17:10:59 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 16 Jul 2019 19:10:59 +0200 Subject: Colo in Africa In-Reply-To: <0B1FB931-4A97-4AE2-AFBD-06829BFA7315@bogus.com> References: <0B1FB931-4A97-4AE2-AFBD-06829BFA7315@bogus.com> Message-ID: <0de521b7-1823-a114-e4c2-9a2018cc1d48@seacom.mu> On 16/Jul/19 18:23, Joel Jaeggli wrote: > > > 100ms from most of the rest of Africa is going to be a bit dubious. If > you draw a line horizontally through Senegal the costal stuff north of > it can mostly be served in under 100ms from Europe. > > While cross border terrestrial fiber exists most networks I’ve been > exposed to have east west and north south connectivity Via submarine > connected networks.  This make it hard to locate one low latency spot > in the middle. Terrestrial capacity between most countries in Africa is too expensive, not terribly good quality and not always the shortest path. As Joel mentions, for the Eastern & Southern African coast, those countries are connected by marine festoons, i.e., South Africa, Mozambique, Tanzania, Kenya, Somalia, Djibouti and Egypt. You then get terrestrial options running deeper into the hinterlands, and depending on the region, the quality and price will vary. On the west side, you can get marine festoons to South Africa, Namibia, Angola, Nigeria, Ghana and Senegal. Pricing on that side will be a lot higher because those have generally been club cables, unlike on the East side where you have both club and private cables. Just to give an idea about latency between some of the cities we operate in Africa, have a look here:     http://as37100.net/latencymatrix/ This should give you some idea of the problem. Mark. From mark.tinka at seacom.mu Tue Jul 16 17:16:48 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 16 Jul 2019 19:16:48 +0200 Subject: Colo in Africa In-Reply-To: References: Message-ID: <570fa34c-75b2-e2bf-97e0-f8225a7f2595@seacom.mu> On 16/Jul/19 19:00, Ken Gilmour wrote: > > Our "market" is actually the US - but we're experiencing unexpected > success across the world. A lot of our customers have selected > "Africa" as their region when signing up and they are in various > countries around Africa, they deserve to be served better within their > continent at least. Makes sense. > > We can't actually build POPs fast enough, so I want to throw as broad > a net as possible with our first POP in Africa and then branch out > from there. We have customers in South Africa, Tanzania, Nigeria, > Egypt, Morocco and Ghana for instance. I have resources for only one > POP in Africa currently, need to decide where to best serve as many as > possible. We could serve Northern Africa from EU and Southern Africa > from Singapore, but having something within the continent would be > preferable. If you had to go with one PoP in Africa to start, then I'd suggest Johannesburg. The data on your side should indicate that this is where you have the majority of the targets. From here, you can get reasonably well to all neighboring countries, i.e., Mozambique, Swaziland, Lesotho, Botswana, Malawi, Zambia, Zimbabwe, Namibia and Angola. Farther afield, you will have reasonable latency to East Africa as well, which will get you Kenya, Uganda, Tanzania, Rwanda and Burundi. Phase 2, I'd say deploy in Nairobi, which will lower your latency for your targets there, and reduce your load in Johannesburg. Phase 3, I'd say Accra or Lagos, but that won't be as straight forward. If you're serious about this, I'd say come down to AfPIF (https://www.afpif.org/) and SAFNOG (http://www.safnog.org/), both of which will be happening 20th - 22nd and 26th - 28th, August, respectively. You will learn a lot by attending both meetings, and since they are back-to-back, between Mauritius and Johannesburg, it is easy to do travel-wise. Otherwise, happy to offline a discussion with you if you want some mail-time with our Sales droids :-). Mark. From valdis.kletnieks at vt.edu Tue Jul 16 17:18:48 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Tue, 16 Jul 2019 13:18:48 -0400 Subject: Colo in Africa In-Reply-To: References: Message-ID: <25659.1563297528@turing-police> On Tue, 16 Jul 2019 10:11:48 -0600, Ken Gilmour said: > Speed is not the issue, it's IO. Also streaming 100Gbps of video is very > different to streaming 100Gbps of files smaller than 100kb (average of > about 30kb) the issue on the network level is the number of connections and > CPU, on the server side it's IO and FSB The trick is to realize that 100Gbps of files smaller than 100kb can be remodeled as 12 Gigabytes/sec of random 128K writes into large files. Which isn't even that hard with modern gear, especially if you have the budget for SSDs. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Tue Jul 16 17:23:24 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Tue, 16 Jul 2019 13:23:24 -0400 Subject: Colo in Africa In-Reply-To: References: Message-ID: <25853.1563297804@turing-police> On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said: > These are actual real problems we face. thousands of customers load and > reload TBs of data every few seconds on their dashboards. If they're reloading TBs of data every few seconds, you really should have been doing summaries during data ingestion and only reloading the summaries. (Overlooking the fact that for dashboards, refreshing every few seconds is usually pointless because you end up looking at short-term statistical spikes rather than anything that you can react to at human speeds. If you *care* in real time that the number of probes on a port spiked to 457% of average for 2 seconds you need to be doing automated responses.... Custom queries are more painful - but those don't happen "every few seconds". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mark.tinka at seacom.mu Tue Jul 16 17:24:39 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 16 Jul 2019 19:24:39 +0200 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> Message-ID: <0060175a-b57f-af8c-bd32-3ed5981671a9@seacom.mu> So I got this from BGPmon, earlier today: ***** You received this email because you are subscribed to BGPmon.net. For more details about these updates please visit: https://portal.bgpmon.net/myalerts.php ==================================================================== RPKI Validation Failed (Code: 9) ==================================================================== Your prefix:          105.16.0.0/12: Prefix Description:   In case of abuse, please contact abuse at seacom.mu Update time:          2019-07-16 15:45 (UTC) Detected by #peers:   1 Detected prefix:      105.26.205.62/32 Announced by:         AS65075 (-Private Use AS-) Upstream AS:          AS53089 (IDC TELECOM LTDA EPP, BR) ASpath:               53089 65075 Alert details:        https://portal.bgpmon.net/alerts.php?details&alert_id=89182454 Mark as false alert:  https://portal.bgpmon.net/fp.php?aid=89182454 RPKI Status:          ROA validation failed: Invalid Prefix-Length + Invalid Origin ASN, expected 37100   --------------------------------------------------------------  *for questions regarding the change code or other question, please see: https://portal.bgpmon.net/faq.php Latest BGPmon news: http://bgpmon.net/blog/   * Popular Destinations rerouted to Russia   * Today’s BGP leak in Brazil   * BGP leak causing Internet outages in Japan and beyond. . ***** See why we like (not!) BGP optimizers so much? Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Jul 16 17:37:03 2019 From: randy at psg.com (Randy Bush) Date: Tue, 16 Jul 2019 10:37:03 -0700 Subject: Colo in Africa In-Reply-To: References: Message-ID: [ there is an afnog mailing list which you might find useful ] > 3. Must have good connectivity to most of the rest of Africa unfortunately, for common values of 'most' this is a long sad tragedy. mark's excellent reccos can get you the fancy bits. inter-connectivity with africa is sad. randy From job at instituut.net Tue Jul 16 17:41:13 2019 From: job at instituut.net (Job Snijders) Date: Tue, 16 Jul 2019 17:41:13 +0000 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> Message-ID: On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett wrote: > More like do whatever you want in your own house as long as you don't > infringe upon others. > That's where the rub is; when using "BGP optimisers" to influence public Internet routing, you cannot guarantee you won't infringe upon others. > The argument against route optimizers (assuming appropriate ingress\egress > filters) is a religious one and should be treated as such. > The argument against "BGP optimizers" is that we *cannot* assume appropriate ingress or egress filters. It appears to me like fallacy to suggest a line of reasoning ala "if you do things correctly, things won't go wrong". Clearly we've observed many times over that things *do* go wrong. Some examples: almost every year one of the major BGP vendors has a serious bug related to the functionality to NO_EXPORT in some release. Also, routinely we observe there are software defects that cause a device to behave different (read 'leak') than how the operator had explicitly configured the device. These are facts, not religious statements. Perhaps in a bug-free world there is room for dangerous activities, but there is no such thing as bug-free. And I haven't even covered the human error angle. We must robustly architect our networks to mitigate or dampen the negative effects of issues at all layers of the stack. I consider it wholly inappropriate to write-off the countless hours spend dealing with fallout from "BGP optimizers" and the significant financial damages we've sustained as "religious arguments". Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.py at tsisemi.com Tue Jul 16 17:42:57 2019 From: michel.py at tsisemi.com (Michel Py) Date: Tue, 16 Jul 2019 17:42:57 +0000 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: <76043D9819086BEE.7cd4a211-e067-4734-98f9-ab3a842ca43d@mail.outlook.com> Message-ID: <4bbbb07bd3cc4acb87b6750b086468a4@CRA114.am.necel.com> > Tom Beecher wrote : > The most important metric for a BGP optimizer is how much it physically weighs. That way you'll know > if you can carry it to the trash pile yourself, or need to get help so you don't hurt your back. Please dispose of it in an environment friendly way. In the city I live and many other ones we have programs to get rid of such garbage in a proper way. https://www.roseville.ca.us/residents/utility_exploration_center/e-waste Stop the pollution of the routing table and the planet ! > Mark Tinka wrote : > So I got this from BGPmon, earlier today: Oh yeah, a /32 sourced from a private ASN without no-export. Michel TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From akshay at mongodb.com Tue Jul 16 17:53:44 2019 From: akshay at mongodb.com (Akshay Kumar) Date: Tue, 16 Jul 2019 18:53:44 +0100 Subject: Colo in Africa In-Reply-To: References: Message-ID: Then you are "doing it wrong(tm). Good luck. On Tue, Jul 16, 2019 at 5:40 PM Ken Gilmour wrote: > These are actual real problems we face. thousands of customers load and > reload TBs of data every few seconds on their dashboards. We have busy > servers. We tried cloud. I passionately hate it. We choose to use Bare > Metal. > > On Tue, 16 Jul 2019 at 10:34, Akshay Kumar wrote: > >> Go look at the actual specifications for one of the metal boxes - you are >> not going to come close to maxing anything out with the workload you >> describe. FSB hasn't been a thing in over a decade. If you really wanted to >> go crazy you could do some build a custom solution in FPGA on the F1s. >> >> It's a moot point since none of this is going to be available in time but >> perf is a bogus reason and a lot of the times price is too. >> >> On Tue, Jul 16, 2019 at 5:12 PM Ken Gilmour >> wrote: >> >>> Speed is not the issue, it's IO. Also streaming 100Gbps of video is very >>> different to streaming 100Gbps of files smaller than 100kb (average of >>> about 30kb) the issue on the network level is the number of connections and >>> CPU, on the server side it's IO and FSB >>> >>> On Tue, 16 Jul 2019 at 08:55, Akshay Kumar wrote: >>> >>>> The 2nd requirement seems artificial. The new hypervisors have come a >>>> long way and the overhead is minimal. Also you can run bare metal instances >>>> in AWS if you really need them with 100Gbps. >>>> >>>> Just just use the South Africa AWS region. >>>> >>>> On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour >>>> wrote: >>>> >>>>> Hi Folks, >>>>> >>>>> I work for a Security Analytics org and we're looking to build a small >>>>> POP in Africa. I am pretty clueless about the region so I was wondering if >>>>> you could help guide me in the right direction for research? >>>>> >>>>> The challenges: >>>>> >>>>> 1. Network needs to be able to receive millions of small PPS (as >>>>> opposed to serving smaller numbers of larger files). >>>>> 2. Can't be cloud (need bare metal servers / colo). We use the >>>>> full capacity of each server, all the time. >>>>> 3. Must have good connectivity to most of the rest of Africa >>>>> 4. We can initially only have one POP >>>>> >>>>> This is not like a normal website that we can just host on "any old >>>>> provider", the requirements are very different. >>>>> >>>>> Is there a good location where we could either rent bare metal servers >>>>> (something like Internap - preferred) or colocate servers within Africa >>>>> that can serve most of the region? >>>>> >>>>> "Good" is defined as an area with stable connectivity and power, no >>>>> legal restrictions on things like encryption, and good latency (sub 100ms) >>>>> to the rest of Africa. >>>>> >>>>> Our two closest POPs are in Singapore and The Netherlands, so I'd like >>>>> something closer to the middle that can serve the rest of Africa. Middle >>>>> East will be deployed after Africa. >>>>> >>>>> I hope this is the right place to ask. >>>>> >>>>> Thanks! >>>>> >>>>> Ken >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Tue Jul 16 18:04:01 2019 From: nick at foobar.org (Nick Hilliard) Date: Tue, 16 Jul 2019 19:04:01 +0100 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> Message-ID: <1b2df92e-cb33-5d11-779e-2299b7829696@foobar.org> Job Snijders wrote on 16/07/2019 18:41: > I consider it wholly inappropriate to write-off the countless hours > spend dealing with fallout from "BGP optimizers" and the significant > financial damages we've sustained as "religious arguments". it would be interesting to see research into the financial losses experienced by people and organisations across the internet caused by routing outages relating to bgp optimisers. Nick From Ryan.Hamel at quadranet.com Tue Jul 16 18:10:37 2019 From: Ryan.Hamel at quadranet.com (Ryan Hamel) Date: Tue, 16 Jul 2019 18:10:37 +0000 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: <1b2df92e-cb33-5d11-779e-2299b7829696@foobar.org> References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> <1b2df92e-cb33-5d11-779e-2299b7829696@foobar.org> Message-ID: Nowhere near the number as an engineer fat fingering a route. There are ISPs that accept routes all the way to /32 or /128, for traffic engineering with ease, and/or RTBH. Ryan -----Original Message----- From: NANOG On Behalf Of Nick Hilliard Sent: Tuesday, July 16, 2019 11:04 AM To: Job Snijders Cc: NANOG Subject: Re: Performance metrics used in commercial BGP route optimizers Job Snijders wrote on 16/07/2019 18:41: > I consider it wholly inappropriate to write-off the countless hours > spend dealing with fallout from "BGP optimizers" and the significant > financial damages we've sustained as "religious arguments". it would be interesting to see research into the financial losses experienced by people and organisations across the internet caused by routing outages relating to bgp optimisers. Nick From sethm at rollernet.us Tue Jul 16 18:13:45 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 16 Jul 2019 11:13:45 -0700 Subject: Colo in Africa In-Reply-To: References: Message-ID: <0fc88b2c-6943-faa0-0d85-7ca2109708d4@rollernet.us> On 7/16/19 10:53 AM, Akshay Kumar via NANOG wrote: > Then you are "doing it wrong(tm). Good luck. Are you saying that anyone choosing not to use "the cloud" is simply wrong because "cloud" is always right? From ximaera at gmail.com Tue Jul 16 18:13:00 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Tue, 16 Jul 2019 21:13:00 +0300 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> Message-ID: On Tue, Jul 16, 2019, 6:29 PM Mike Hammett wrote: > assuming appropriate ingress\egress filters > This assumption itself is a good start for the aforementioned "security considerations" chapter, b/c this is the assumption most of us make but only few routinely check. -- Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at instituut.net Tue Jul 16 18:18:24 2019 From: job at instituut.net (Job Snijders) Date: Tue, 16 Jul 2019 18:18:24 +0000 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> <1b2df92e-cb33-5d11-779e-2299b7829696@foobar.org> Message-ID: On Tue, Jul 16, 2019 at 6:10 PM Ryan Hamel wrote: > > Nowhere near the number as an engineer fat fingering a route. How are you able to make that assertion? > There are ISPs that accept routes all the way to /32 or /128, for traffic engineering with ease, and/or RTBH. This strikes me as a bit of a red herring. Aren't the damaging effects of "BGP optimisers" *amplified* (not caused!) by ISPs who accept "all routes"? An ISP accepting incorrect routing information still is a step below entities actively generating and distributing incorrect routing information. Kind regards, Job From nanog at ics-il.net Tue Jul 16 18:24:11 2019 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 16 Jul 2019 13:24:11 -0500 (CDT) Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> Message-ID: <238492739.4267.1563301451244.JavaMail.mhammett@ThunderFuck> All of the same tragedy can happen without BGP optimizers, and does. BGP optimizers only harm the global Internet when route filters don't do their job. (Un)Fortunately, many other things also harm the global Internet when route filters don't do their job. Things other than BGP optimizers harm the global Internet more frequently via the same vector (lack of proper route filters). A given set of bugs are unlikely to affect both Optimizer edge egress filters and upstream ingress filters. If so, the Internet as a whole has much graver things to worry about. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Job Snijders" To: "Mike Hammett" Cc: "Töma Gavrichenkov" , "NANOG" Sent: Tuesday, July 16, 2019 12:41:13 PM Subject: Re: Performance metrics used in commercial BGP route optimizers On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett < nanog at ics-il.net > wrote: More like do whatever you want in your own house as long as you don't infringe upon others. That's where the rub is; when using "BGP optimisers" to influence public Internet routing, you cannot guarantee you won't infringe upon others.
The argument against route optimizers (assuming appropriate ingress\egress filters) is a religious one and should be treated as such.
The argument against "BGP optimizers" is that we *cannot* assume appropriate ingress or egress filters. It appears to me like fallacy to suggest a line of reasoning ala "if you do things correctly, things won't go wrong". Clearly we've observed many times over that things *do* go wrong. Some examples: almost every year one of the major BGP vendors has a serious bug related to the functionality to NO_EXPORT in some release. Also, routinely we observe there are software defects that cause a device to behave different (read 'leak') than how the operator had explicitly configured the device. These are facts, not religious statements. Perhaps in a bug-free world there is room for dangerous activities, but there is no such thing as bug-free. And I haven't even covered the human error angle. We must robustly architect our networks to mitigate or dampen the negative effects of issues at all layers of the stack. I consider it wholly inappropriate to write-off the countless hours spend dealing with fallout from "BGP optimizers" and the significant financial damages we've sustained as "religious arguments". Kind regards, Job -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Tue Jul 16 18:35:18 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Tue, 16 Jul 2019 21:35:18 +0300 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: <238492739.4267.1563301451244.JavaMail.mhammett@ThunderFuck> References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> <238492739.4267.1563301451244.JavaMail.mhammett@ThunderFuck> Message-ID: Peace, On Tue, Jul 16, 2019, 9:24 PM Mike Hammett wrote: > BGP optimizers only harm the global Internet when route filters don't do > their job. (Un)Fortunately, many other things also harm the global Internet > when route filters don't do their job. > That is correct; however, there are potentially harmful things that cannot easily be avoided (so we accept the risk), and optimizers are not among those. E.g. there are quite a number of things which could cause an airplane to crash yet are still allowed onboard; but this alone isn't an argument convincing enough to allow handguns there. -- Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at instituut.net Tue Jul 16 18:49:00 2019 From: job at instituut.net (Job Snijders) Date: Tue, 16 Jul 2019 18:49:00 +0000 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: <238492739.4267.1563301451244.JavaMail.mhammett@ThunderFuck> References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> <238492739.4267.1563301451244.JavaMail.mhammett@ThunderFuck> Message-ID: <20190716184900.GQ33367@vurt.meerval.net> On Tue, Jul 16, 2019 at 01:24:11PM -0500, Mike Hammett wrote: > All of the same tragedy can happen without BGP optimizers, and does. I disagree. You are skipping over crucial distinction we should make between common 'route leaks' (incorrect propagation of valid routing information), and the poison that is 'bgp optimiser hijacks' (propagating of invalid/nonexistent routing information). In the first case, a simple leak of existing real routing information, you'll often see that the outcomes of the leak have a longer AS_PATH, and that the leaking ASN has an actual path towards the destination. In the best case the leaked routes are ignored because they don't become the best path, in the worst case anyone using those leaked paths suffers from congestion. In the second case, leaked routes that came from a so-called 'bgp optimiser', during the leak there is no forwarding path to the actual destination. The packets circulate in a loop and never arrive at the intended destination. This is hard downtime for the affected prefixes. We also often see that the AS_PATH is entirely fabricated by "BGP optimisers", further increasing the risk of the hijacked route announcements being used. > BGP optimizers only harm the global Internet when route filters don't > do their job. (Un)Fortunately, many other things also harm the global > Internet when route filters don't do their job. Things other than BGP > optimizers harm the global Internet more frequently via the same > vector (lack of proper route filters). > > A given set of bugs are unlikely to affect both Optimizer edge egress > filters and upstream ingress filters. If so, the Internet as a whole > has much graver things to worry about. I believe it is a fallacy to state that "because other things can harm the Internet" it would be somehow become OK to use a BGP optimiser. It is not, it is extremely dangerous for those networks whose prefixes are being 'optimised' (née hijacked). Every day we see negative effects as a result from "bgp optimizers". We also have observed that some of the 'bgp optimizers' have consciously chosen to not apply even the most basic of harm reduction methods, see https://twitter.com/JobSnijders/status/1143205986787831819 We can't stop people from deploying this type of software, the Internet simply doesn't provide that kind of regulatory environment, but one should be fully aware of the terrible risks involved when doing so. Networks should be cognizant of peers they suspect are using such software to steer traffic. Kind regards, Job From valdis.kletnieks at vt.edu Tue Jul 16 18:53:16 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Tue, 16 Jul 2019 14:53:16 -0400 Subject: Colo in Africa In-Reply-To: <0fc88b2c-6943-faa0-0d85-7ca2109708d4@rollernet.us> References: <0fc88b2c-6943-faa0-0d85-7ca2109708d4@rollernet.us> Message-ID: <30463.1563303196@turing-police> On Tue, 16 Jul 2019 11:13:45 -0700, Seth Mattinen said: > On 7/16/19 10:53 AM, Akshay Kumar via NANOG wrote: > > Then you are "doing it wrong(tm). Good luck. > > > Are you saying that anyone choosing not to use "the cloud" is simply > wrong because "cloud" is always right? No, he's saying that if you're data-mining the same terabytes of data every few seconds, you're doing it wrong. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From hendrikdm at gmail.com Tue Jul 16 19:40:56 2019 From: hendrikdm at gmail.com (Hendrik Meyburgh) Date: Tue, 16 Jul 2019 21:40:56 +0200 Subject: Colo in Africa In-Reply-To: References: Message-ID: I suggest you look at the Teraco facilities, specifically the JB1 (Isando) site. It is extremely well connected and carrier-neutral so you can choose who you want to use. Depending on your requirement you might need to work through a reseller. I work for an SP in South Africa, so let me know offline if you need any help. On Tue, Jul 16, 2019 at 4:34 PM Ken Gilmour wrote: > Hi Folks, > > I work for a Security Analytics org and we're looking to build a small POP > in Africa. I am pretty clueless about the region so I was wondering if you > could help guide me in the right direction for research? > > The challenges: > > 1. Network needs to be able to receive millions of small PPS (as > opposed to serving smaller numbers of larger files). > 2. Can't be cloud (need bare metal servers / colo). We use the full > capacity of each server, all the time. > 3. Must have good connectivity to most of the rest of Africa > 4. We can initially only have one POP > > This is not like a normal website that we can just host on "any old > provider", the requirements are very different. > > Is there a good location where we could either rent bare metal servers > (something like Internap - preferred) or colocate servers within Africa > that can serve most of the region? > > "Good" is defined as an area with stable connectivity and power, no legal > restrictions on things like encryption, and good latency (sub 100ms) to the > rest of Africa. > > Our two closest POPs are in Singapore and The Netherlands, so I'd like > something closer to the middle that can serve the rest of Africa. Middle > East will be deployed after Africa. > > I hope this is the right place to ask. > > Thanks! > > Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Tue Jul 16 21:21:18 2019 From: nick at foobar.org (Nick Hilliard) Date: Tue, 16 Jul 2019 22:21:18 +0100 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> <1b2df92e-cb33-5d11-779e-2299b7829696@foobar.org> Message-ID: <2d895d7e-6cef-59f0-213f-c1682a6659d2@foobar.org> Oh I don't know about that. There's been a pile of high profile incidents which have been associated with "BGP optimisers", affecting connectivity to huge chunks of the internet, world-wide. It's not unusual for a single incident to have widespread or even global effect, and what with the Internet playing such an important part of the world's economies, it's hard not to be curious about the overall financial impact of this sort of thing. Nick Ryan Hamel wrote on 16/07/2019 19:10: > Nowhere near the number as an engineer fat fingering a route. There are ISPs that accept routes all the way to /32 or /128, for traffic engineering with ease, and/or RTBH. > > Ryan > > -----Original Message----- > From: NANOG On Behalf Of Nick Hilliard > Sent: Tuesday, July 16, 2019 11:04 AM > To: Job Snijders > Cc: NANOG > Subject: Re: Performance metrics used in commercial BGP route optimizers > > Job Snijders wrote on 16/07/2019 18:41: >> I consider it wholly inappropriate to write-off the countless hours >> spend dealing with fallout from "BGP optimizers" and the significant >> financial damages we've sustained as "religious arguments". > > it would be interesting to see research into the financial losses experienced by people and organisations across the internet caused by routing outages relating to bgp optimisers. > > Nick > > From ken.gilmour at gmail.com Tue Jul 16 21:54:10 2019 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 16 Jul 2019 15:54:10 -0600 Subject: Colo in Africa In-Reply-To: <25853.1563297804@turing-police> References: <25853.1563297804@turing-police> Message-ID: We have a different use case to traditional analytics - We're aimed at consumers and small businesses, so instead of a SOC with one big screen refreshing 10000 rows of only alert data every 30 seconds, we have thousands of individuals refreshing all of their data every 30 seconds because there are comparatively less alerts for individuals than enterprises. What you "should" do often doesn't translate to what you "do" do. On Tue, 16 Jul 2019 at 11:23, Valdis Klētnieks wrote: > On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said: > > > These are actual real problems we face. thousands of customers load and > > reload TBs of data every few seconds on their dashboards. > > If they're reloading TBs of data every few seconds, you really should have > been > doing summaries during data ingestion and only reloading the summaries. > (Overlooking the fact that for dashboards, refreshing every few seconds is > usually pointless because you end up looking at short-term statistical > spikes > rather than anything that you can react to at human speeds. If you *care* > in > real time that the number of probes on a port spiked to 457% of average > for 2 > seconds you need to be doing automated responses.... > > Custom queries are more painful - but those don't happen "every few > seconds". > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfillekes at gmail.com Tue Jul 16 22:06:57 2019 From: cfillekes at gmail.com (C. A. Fillekes) Date: Tue, 16 Jul 2019 18:06:57 -0400 Subject: Colo in Africa In-Reply-To: References: <25853.1563297804@turing-police> Message-ID: Are they refreshing data they've already got, though? This is the classic use case for client-side caching. On Tue, Jul 16, 2019 at 5:56 PM Ken Gilmour wrote: > We have a different use case to traditional analytics - We're aimed at > consumers and small businesses, so instead of a SOC with one big screen > refreshing 10000 rows of only alert data every 30 seconds, we have > thousands of individuals refreshing all of their data every 30 seconds > because there are comparatively less alerts for individuals than > enterprises. > > What you "should" do often doesn't translate to what you "do" do. > > On Tue, 16 Jul 2019 at 11:23, Valdis Klētnieks > wrote: > >> On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said: >> >> > These are actual real problems we face. thousands of customers load and >> > reload TBs of data every few seconds on their dashboards. >> >> If they're reloading TBs of data every few seconds, you really should >> have been >> doing summaries during data ingestion and only reloading the summaries. >> (Overlooking the fact that for dashboards, refreshing every few seconds is >> usually pointless because you end up looking at short-term statistical >> spikes >> rather than anything that you can react to at human speeds. If you >> *care* in >> real time that the number of probes on a port spiked to 457% of average >> for 2 >> seconds you need to be doing automated responses.... >> >> Custom queries are more painful - but those don't happen "every few >> seconds". >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at mtcc.com Tue Jul 16 22:23:26 2019 From: mike at mtcc.com (Michael Thomas) Date: Tue, 16 Jul 2019 15:23:26 -0700 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <1394695366.764492.1563217632200.JavaMail.zimbra@baylink.com> References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> <1394695366.764492.1563217632200.JavaMail.zimbra@baylink.com> Message-ID: <64102dbd-08e6-ddb6-6e97-577f92ec2357@mtcc.com> On 7/15/19 12:07 PM, Jay R. Ashworth wrote: > ----- Original Message ----- >> From: "Christopher Morrow" >> On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins wrote: >>> Chris it would be trivial for this to be fixed, nearly overnight, by >>> creating some liability on the part of carriers for illicit use of >>> caller ID data on behalf of their customers. >> 'illicit use of caller id' - how is caller-id being illicitly used though? >> I don't think it's against the law to say a different 'callerid' in the call >> session, practically every actual call center does this, right? > I can speak to that, having originated calls from a call center. > > Yes, of course we sent out calls with "spoofed" CNID. > > But, even though only 2 or 3 or our 5 carriers* held *our* feet to the fire, > we held the clients' feet to the fire, requiring them to prove to our > satisfaction that they had adminstrative control over the numbers in question. > > But it's the carrier's responsibility, properly, to do that work. > How do the clients prove that? Way back when when we were working on mipv6 we had to work through a somewhat similar problem for handoffs. The ultimate answer was a return routability test: that is, if you can answer on the address you're trying to claim "ownership" for, it's good enough. Maybe such a thing can be done in for spoofing? Even out of band spot checking might be adequate to keep clients honest? But right you are, it's ultimately the carrier who needs to care about this problem at or nothing gets better. Mike From goemon at sasami.anime.net Tue Jul 16 22:27:34 2019 From: goemon at sasami.anime.net (Dan Hollis) Date: Tue, 16 Jul 2019 15:27:34 -0700 (PDT) Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <64102dbd-08e6-ddb6-6e97-577f92ec2357@mtcc.com> References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> <1394695366.764492.1563217632200.JavaMail.zimbra@baylink.com> <64102dbd-08e6-ddb6-6e97-577f92ec2357@mtcc.com> Message-ID: On Tue, 16 Jul 2019, Michael Thomas wrote: > But right you are, it's ultimately the carrier who needs to care about this > problem at or nothing gets better. either the carrier starts dealing with it or legislation will come down to force the issue. -Dan From ken.gilmour at gmail.com Tue Jul 16 22:46:04 2019 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 16 Jul 2019 16:46:04 -0600 Subject: Colo in Africa In-Reply-To: References: <25853.1563297804@turing-police> Message-ID: What matters is whether or not we can get a facility in Africa to provide service to our customers from Bare Metal Servers :) On Tue, 16 Jul 2019 at 16:07, C. A. Fillekes wrote: > Are they refreshing data they've already got, though? > This is the classic use case for client-side caching. > > On Tue, Jul 16, 2019 at 5:56 PM Ken Gilmour wrote: > >> We have a different use case to traditional analytics - We're aimed at >> consumers and small businesses, so instead of a SOC with one big screen >> refreshing 10000 rows of only alert data every 30 seconds, we have >> thousands of individuals refreshing all of their data every 30 seconds >> because there are comparatively less alerts for individuals than >> enterprises. >> >> What you "should" do often doesn't translate to what you "do" do. >> >> On Tue, 16 Jul 2019 at 11:23, Valdis Klētnieks >> wrote: >> >>> On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said: >>> >>> > These are actual real problems we face. thousands of customers load and >>> > reload TBs of data every few seconds on their dashboards. >>> >>> If they're reloading TBs of data every few seconds, you really should >>> have been >>> doing summaries during data ingestion and only reloading the summaries. >>> (Overlooking the fact that for dashboards, refreshing every few seconds >>> is >>> usually pointless because you end up looking at short-term statistical >>> spikes >>> rather than anything that you can react to at human speeds. If you >>> *care* in >>> real time that the number of probes on a port spiked to 457% of average >>> for 2 >>> seconds you need to be doing automated responses.... >>> >>> Custom queries are more painful - but those don't happen "every few >>> seconds". >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From notify.sina at gmail.com Tue Jul 16 22:57:58 2019 From: notify.sina at gmail.com (Sina Owolabi) Date: Tue, 16 Jul 2019 23:57:58 +0100 Subject: Colo in Africa In-Reply-To: References: <25853.1563297804@turing-police> Message-ID: If Nigeria is a possible location, you have a few, off the top of my head is any telco's colo (MTN, Airtel, Glo, or 9Mobile), and there's RackCentre, MainOne and I think IPNX for colo (virtual and bare metal). On Tue, Jul 16, 2019 at 11:48 PM Ken Gilmour wrote: > > What matters is whether or not we can get a facility in Africa to provide service to our customers from Bare Metal Servers :) > > On Tue, 16 Jul 2019 at 16:07, C. A. Fillekes wrote: >> >> Are they refreshing data they've already got, though? >> This is the classic use case for client-side caching. >> >> On Tue, Jul 16, 2019 at 5:56 PM Ken Gilmour wrote: >>> >>> We have a different use case to traditional analytics - We're aimed at consumers and small businesses, so instead of a SOC with one big screen refreshing 10000 rows of only alert data every 30 seconds, we have thousands of individuals refreshing all of their data every 30 seconds because there are comparatively less alerts for individuals than enterprises. >>> >>> What you "should" do often doesn't translate to what you "do" do. >>> >>> On Tue, 16 Jul 2019 at 11:23, Valdis Klētnieks wrote: >>>> >>>> On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said: >>>> >>>> > These are actual real problems we face. thousands of customers load and >>>> > reload TBs of data every few seconds on their dashboards. >>>> >>>> If they're reloading TBs of data every few seconds, you really should have been >>>> doing summaries during data ingestion and only reloading the summaries. >>>> (Overlooking the fact that for dashboards, refreshing every few seconds is >>>> usually pointless because you end up looking at short-term statistical spikes >>>> rather than anything that you can react to at human speeds. If you *care* in >>>> real time that the number of probes on a port spiked to 457% of average for 2 >>>> seconds you need to be doing automated responses.... >>>> >>>> Custom queries are more painful - but those don't happen "every few seconds". -- cordially yours, Sina Owolabi +2348176469061 From ken.gilmour at gmail.com Tue Jul 16 23:30:15 2019 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 16 Jul 2019 17:30:15 -0600 Subject: Colo in Africa In-Reply-To: <25853.1563297804@turing-police> References: <25853.1563297804@turing-police> Message-ID: TBs of data is not really that much data on average when you average it over thousands of customers. The data is summarized, There are a ton of other things happening in the background that I've already explained in the thread and are really irrelevant to the task at hand which is finding a facility in Africa that does Bare Metal servers. I've had a lot of helpful people, despite the naysayers. Thanks! On Tue, 16 Jul 2019 at 11:23, Valdis Klētnieks wrote: > On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said: > > > These are actual real problems we face. thousands of customers load and > > reload TBs of data every few seconds on their dashboards. > > If they're reloading TBs of data every few seconds, you really should have > been > doing summaries during data ingestion and only reloading the summaries. > (Overlooking the fact that for dashboards, refreshing every few seconds is > usually pointless because you end up looking at short-term statistical > spikes > rather than anything that you can react to at human speeds. If you *care* > in > real time that the number of probes on a port spiked to 457% of average > for 2 > seconds you need to be doing automated responses.... > > Custom queries are more painful - but those don't happen "every few > seconds". > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Tue Jul 16 23:45:35 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 16 Jul 2019 16:45:35 -0700 Subject: Colo in Africa In-Reply-To: References: <25853.1563297804@turing-police> Message-ID: <44e0e1e1-dda9-7019-8adb-250bd14215bb@rollernet.us> On 7/16/19 4:30 PM, Ken Gilmour wrote: > TBs of data is not really that much data on average when  you average it > over thousands of customers. The data is summarized, There are a ton of > other things happening in the background that I've already explained in > the thread and are really irrelevant to the task at hand which is > finding a facility in Africa that does Bare Metal servers. I've had a > lot of helpful people, despite the naysayers. > I did find all of the "why not cloud" responses disappointing when you asked for colo of servers. On this list I would assume someone asking for a specific thing knows why they want it. From valdis.kletnieks at vt.edu Tue Jul 16 23:55:01 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Tue, 16 Jul 2019 19:55:01 -0400 Subject: Colo in Africa In-Reply-To: References: <25853.1563297804@turing-police> Message-ID: <11899.1563321301@turing-police> On Tue, 16 Jul 2019 15:54:10 -0600, Ken Gilmour said: > We have a different use case to traditional analytics - We're aimed at > consumers and small businesses, so instead of a SOC with one big screen > refreshing 10000 rows of only alert data every 30 seconds, we have > thousands of individuals refreshing all of their data every 30 seconds > because there are comparatively less alerts for individuals than > enterprises. Plenty of room for lots of optimizations there, especially in conjunction with some client-side caching. If they're generating enough *new* events every 30 seconds to cause any significant load, they're either in the middle of a major event (something that shouldn't happen too often) or they have the logging is set to be so verbose that they're likely to miss actual important messages. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From Joel.Snyder at opus1.com Wed Jul 17 00:32:35 2019 From: Joel.Snyder at opus1.com (Joel M Snyder) Date: Tue, 16 Jul 2019 17:32:35 -0700 Subject: Colo in Africa Message-ID: Ken: >Is there a good location where we could either rent bare metal servers >(something like Internap - preferred) or colocate servers within >Africa that can serve most of the region? Africa is a tough nut to crack. I have been building networks there for clients for decades and the first thing to understand is that Africa is BIG. Geographically, you can fit the US, Europe, and Canada (and have room to spare). Typical Mercator maps make it look much smaller than it really is. Anyway, my point here is that you should not be thinking about Africa as "a region" or "a continent." When a lot of people say "Africa," they really mean "South Africa" (the small country), and there is great connectivity there---but positioning yourself in South Africa doesn't really help you any more to get to Ghana (for example) than being in the Netherlands. If you really are thinking AFRICA as in AFRICA, you probably should use an approach that divides it into regions. You can break it up however you want, but if you start with 4 regions (Southern, Northern, Western, Eastern/Central) you'll have chunks that actually hold together from a telecoms point of view pretty well. My best experiences (and these are about 3 years out of date) have been in Jo'burg (Southern), Nairobi/Addis (Eastern/Central), Ghana (Western), and Egypt (Northern), but there is a lot of interest and a lot of progress so getting some ground knowledge would be a good idea. The real bandwidth is submarine cables that go up and down the coasts --- you can find some maps of these of varying accuracy and quality --- while actual E/W and N/S connectivity in the center of the continent is much more limited. There are a number of Internet-promoting organizations in Africa---you can start with ISOC and Afrinic that sponsor a number of projects aimed at increasing capacity there, but you'll find a bunch of people trying to do good things. If you are mostly interested in South Africa, there's NAPAfrica and SAFNOG (Southern African equivalent of NANOG) as information sources. Anyway: I can get more specific, but it's hard to really offer super-specific advice on a vague question because, you know, Africa. That's a big topic. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From morrowc.lists at gmail.com Wed Jul 17 00:38:02 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 16 Jul 2019 20:38:02 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> <1394695366.764492.1563217632200.JavaMail.zimbra@baylink.com> <64102dbd-08e6-ddb6-6e97-577f92ec2357@mtcc.com> Message-ID: On Tue, Jul 16, 2019 at 6:28 PM Dan Hollis wrote: > > On Tue, 16 Jul 2019, Michael Thomas wrote: > > But right you are, it's ultimately the carrier who needs to care about this > > problem at or nothing gets better. > > either the carrier starts dealing with it or legislation will come down to > force the issue. It's 2019 right? This has been happening since ~1996 From morrowc.lists at gmail.com Wed Jul 17 00:41:29 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 16 Jul 2019 20:41:29 -0400 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: <2d895d7e-6cef-59f0-213f-c1682a6659d2@foobar.org> References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> <1b2df92e-cb33-5d11-779e-2299b7829696@foobar.org> <2d895d7e-6cef-59f0-213f-c1682a6659d2@foobar.org> Message-ID: On Tue, Jul 16, 2019 at 5:22 PM Nick Hilliard wrote: > > Oh I don't know about that. There's been a pile of high profile > incidents which have been associated with "BGP optimisers", affecting > connectivity to huge chunks of the internet, world-wide. How many, exactly and with a pointer/reference, have been 'not an optimizer' ? I almost made the same post as Mr Hammett ~4 messages (his messages) back made: "Err, all of these problems are possible without an optimizer", except I don't really believe that it's helpful: "All my friends failed out, but I just got D's..." isn't really selling this as a great plan. I suppose if your (not nick's) story is: "Well, I know what I'm doing, my upstreams filter me, I'd NEVER leak..." ok, but really no, not ok... someone 'not you' will eventually operate part of your network and fail where you hadn't. -chris From eric.kuhnke at gmail.com Wed Jul 17 01:05:09 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 16 Jul 2019 18:05:09 -0700 Subject: Colo in Africa In-Reply-To: References: Message-ID: Without being more specific on what geographic region you want to serve, in terms of ISPs, it's hard to say. For example: If you look at submarine cable topology at layer 1, and BGP sessions, AS adjacencies between ISPs: Freetown, Sierra Leone and Monrovia, Liberia are suburbs of London, UK. If you want to reach major things in the west african region the two best connected places are Accra, Ghana and Lagos, Nigeria. On the other hand, if you put equipment topologically close to the cable landing station in Accra it will have rather poor connectivity to the east side of Africa. It's a big place and there is very little cross-continent connectivity that doesn't take the long way around via submarine fiber to Cape Town, and then up the east coast. On Tue, Jul 16, 2019 at 7:34 AM Ken Gilmour wrote: > Hi Folks, > > I work for a Security Analytics org and we're looking to build a small POP > in Africa. I am pretty clueless about the region so I was wondering if you > could help guide me in the right direction for research? > > The challenges: > > 1. Network needs to be able to receive millions of small PPS (as > opposed to serving smaller numbers of larger files). > 2. Can't be cloud (need bare metal servers / colo). We use the full > capacity of each server, all the time. > 3. Must have good connectivity to most of the rest of Africa > 4. We can initially only have one POP > > This is not like a normal website that we can just host on "any old > provider", the requirements are very different. > > Is there a good location where we could either rent bare metal servers > (something like Internap - preferred) or colocate servers within Africa > that can serve most of the region? > > "Good" is defined as an area with stable connectivity and power, no legal > restrictions on things like encryption, and good latency (sub 100ms) to the > rest of Africa. > > Our two closest POPs are in Singapore and The Netherlands, so I'd like > something closer to the middle that can serve the rest of Africa. Middle > East will be deployed after Africa. > > I hope this is the right place to ask. > > Thanks! > > Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Wed Jul 17 01:42:06 2019 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 16 Jul 2019 20:42:06 -0500 (CDT) Subject: Colo in Africa In-Reply-To: <44e0e1e1-dda9-7019-8adb-250bd14215bb@rollernet.us> References: <25853.1563297804@turing-police> <44e0e1e1-dda9-7019-8adb-250bd14215bb@rollernet.us> Message-ID: <1319209073.4632.1563327721317.JavaMail.mhammett@ThunderFuck> But cloud all of the things!!!!!! ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Seth Mattinen" To: nanog at nanog.org Sent: Tuesday, July 16, 2019 6:45:35 PM Subject: Re: Colo in Africa On 7/16/19 4:30 PM, Ken Gilmour wrote: > TBs of data is not really that much data on average when you average it > over thousands of customers. The data is summarized, There are a ton of > other things happening in the background that I've already explained in > the thread and are really irrelevant to the task at hand which is > finding a facility in Africa that does Bare Metal servers. I've had a > lot of helpful people, despite the naysayers. > I did find all of the "why not cloud" responses disappointing when you asked for colo of servers. On this list I would assume someone asking for a specific thing knows why they want it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.gilmour at gmail.com Wed Jul 17 01:47:13 2019 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 16 Jul 2019 19:47:13 -0600 Subject: Colo in Africa In-Reply-To: <11899.1563321301@turing-police> References: <25853.1563297804@turing-police> <11899.1563321301@turing-police> Message-ID: I feel like I'm arguing with my teenager over why the WiFi is slow. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at haller.ws Wed Jul 17 03:57:26 2019 From: nanog at haller.ws (Patrick) Date: Wed, 17 Jul 2019 11:57:26 +0800 Subject: Ztomy.com again? Message-ID: <20190717035726.GA3223@haller.ws> Anyone else seeing DNS oddities from info.net / infonet.com ? fwdrev() { for ip in `dig +short A $1 @$2`; do echo $ip `dig +short -x $ip @$2` done } fwdrev smtp.microsoft.com 8.8.8.8 131.107.115.215 smtp.microsoft.com. mailb.microsoft.com. mail2.microsoft.com. 131.107.115.214 mailc.microsoft.com. mail3.microsoft.com. smtp.microsoft.com. 205.248.106.64 ns1327.ztomy.com. 205.248.106.30 ns1327.ztomy.com. 205.248.106.32 ns1327.ztomy.com. 131.107.115.212 smtp.microsoft.com. mail1.microsoft.com. fwdrev smtp.microsoft.com 1.1.1.1 205.248.106.30 ns1327.ztomy.com. 205.248.106.32 ns1327.ztomy.com. 205.248.106.64 ns1327.ztomy.com. 131.107.115.212 smtp.microsoft.com. mail1.microsoft.com. 131.107.115.214 mailc.microsoft.com. smtp.microsoft.com. mail3.microsoft.com. 131.107.115.215 mailb.microsoft.com. smtp.microsoft.com. mail2.microsoft.com. dig +trace -x 205.248.106.30 ... 248.205.in-addr.arpa. 86400 IN NS dns1.info.net. 248.205.in-addr.arpa. 86400 IN NS dns1.infonet.com. 248.205.in-addr.arpa. 86400 IN NS dnseur.info.net. ;; Received 360 bytes from 193.0.9.10#53(arin.authdns.ripe.net) in 179 ms 30.106.248.205.in-addr.arpa. 300 IN PTR ns1327.ztomy.com. ;; Received 86 bytes from 208.91.197.27#53(dns1.infonet.com) in 217 ms Patrick From hank at efes.iucc.ac.il Wed Jul 17 04:37:35 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 17 Jul 2019 07:37:35 +0300 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> Message-ID: On 16/07/2019 20:41, Job Snijders wrote: > On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett > wrote: > > More like do whatever you want in your own house as long as you > don't infringe upon others. > > > That's where the rub is; when using "BGP optimisers" to influence > public Internet routing, you cannot guarantee you won't infringe upon > others. > > The argument against route optimizers (assuming appropriate > ingress\egress filters) is a religious one and should be treated > as such. > There is a difference between BGP optimizers and route optimizers.  When was the last time you heard a complain about Akamai screwing up the global routing table over the past 12 years: https://www.akamai.com/us/en/about/news/press/2007-press/akamai-introduces-advanced-communications-protocol-for-accelerating-dynamic-applications.jsp https://developer.akamai.com/legacy/learn/Optimization/SureRoute.html -Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Wed Jul 17 05:48:40 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 17 Jul 2019 07:48:40 +0200 Subject: Colo in Africa In-Reply-To: References: <25853.1563297804@turing-police> Message-ID: On 17/Jul/19 00:57, Sina Owolabi wrote: > If Nigeria is a possible location, you have a few, off the top of my > head is any telco's colo (MTN, Airtel, Glo, or 9Mobile), and there's > RackCentre, MainOne and I think IPNX for colo (virtual and bare > metal). My concern about Nigeria is co-lo that isn't carrier-neutral. AFAIK, Medallion come close to being carrier-neutral, but then bandwidth pricing into the country becomes an issue at scale. Mark. From mark.tinka at seacom.mu Wed Jul 17 06:00:29 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 17 Jul 2019 08:00:29 +0200 Subject: Colo in Africa In-Reply-To: References: Message-ID: <859258c7-ce20-814c-8316-c7606759aad4@seacom.mu> On 17/Jul/19 02:32, Joel M Snyder wrote: >   > When a lot of people say "Africa," they really mean "South Africa" > (the small country), and there is great connectivity there---but > positioning yourself in South Africa doesn't really help you any more > to get to Ghana (for example) than being in the Netherlands. I've been dealing with a number of customers that are not investing - as an initial approach into Africa - in East Africa, mostly Kenya. So while South Africa seems an obvious choice for a number of reasons, Kenya is quickly becoming an immediate option to that for operators that want to kick-start something off in Africa. Also, because South Africa is most obvious most of the time, a few operators are looking to do something unique. > > If you really are thinking AFRICA as in AFRICA, you probably should > use an approach that divides it into regions.  You can break it up > however you want, but if you start with 4 regions (Southern, Northern, > Western, Eastern/Central) you'll have chunks that actually hold > together from a telecoms point of view pretty well. Yes, that's a good place to start. > > My best experiences (and these are about 3 years out of date) have > been in Jo'burg (Southern), Nairobi/Addis (Eastern/Central), Ghana > (Western), and Egypt (Northern), but there is a lot of interest and a > lot of progress so getting some ground knowledge would be a good idea. For East Africa, Mombasa is actually more ideal than Nairobi because you are close to all the major cable systems, being a coastal city. But most importantly, because Kenya's 1st carrier-neutral data centre (iColo) is operational there. Nairobi is some 5ms - 6ms away, so it's not the end of the world. However, iColo will also be launching in Nairobi in a few months from now. > > The real bandwidth is submarine cables that go up and down the coasts > --- you can find some maps of these of varying accuracy and quality > --- while actual E/W and N/S connectivity in the center of the > continent is much more limited. SEACOM and EASSy are your main systems on the East. There is the TEAMS system, but that runs east to Fujairah. WACS is your main system on the west. You don't necessarily need to buy capacity on those systems, as there are a number of operators (including the marine operations, themselves) that have built IP backbones over those systems. Google and Facebook are building new cables around Africa over the next few years as well:     https://www.forbes.com/sites/tobyshapshak/2019/07/03/google-and-facebook-to-build-own-undersea-cables-around-africa/#68e23529de16 Angola Cables launched SACS, which covers the western part of southern Africa, South America and the southern tips of North America:     https://www.angolacables.co.ao/en/sacs-cable-to-boost-connectivity-in-africa-via-teraco-data-centres/ > > There are a number of Internet-promoting organizations in Africa---you > can start with ISOC and Afrinic that sponsor a number of projects > aimed at increasing capacity there, but you'll find a bunch of people > trying to do good things.  If you are mostly interested in South > Africa, there's NAPAfrica and SAFNOG (Southern African equivalent of > NANOG) as information sources. AfPIF, iWeek and SAFNOG will all be happening between Mauritius and Johannesburg week of the 19th and week of the 26th August. Mark. From mark.tinka at seacom.mu Wed Jul 17 06:04:42 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 17 Jul 2019 08:04:42 +0200 Subject: Colo in Africa In-Reply-To: References: Message-ID: On 17/Jul/19 03:05, Eric Kuhnke wrote: > Without being more specific on what geographic region you want to > serve, in terms of ISPs, it's hard to say. > > For example: > > If you look at submarine cable topology at layer 1, and BGP sessions, > AS adjacencies between ISPs: Freetown, Sierra Leone and Monrovia, > Liberia are suburbs of London, UK. > > If you want to reach major things in the west african region the two > best connected places are Accra, Ghana and Lagos, Nigeria. > > On the other hand, if you put equipment topologically close to the > cable landing station in Accra it will have rather poor connectivity > to the east side of Africa. It's a big place and there is very little > cross-continent connectivity that doesn't take the long way around via > submarine fiber to Cape Town, and then up the east coast. The shortest path to get to East Africa from West Africa is as south as you can go into Europe. I suppose if you are trying to interconnect both regions for corporate reasons, that should be okay. But if you're trying to offload content, it's easier to do cache-fill from Europe and distribute locally. It's easier to get your systems talking to one another between Eastern and Southern Africa (and either one to/from Europe) as the connectivity on that side is a lot more robust. Mark. From mark.tinka at seacom.mu Wed Jul 17 06:05:33 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 17 Jul 2019 08:05:33 +0200 Subject: Colo in Africa In-Reply-To: References: Message-ID: <42354256-0db5-b64a-2767-38d3e83f32ad@seacom.mu> On 17/Jul/19 02:32, Joel M Snyder wrote: >   > When a lot of people say "Africa," they really mean "South Africa" > (the small country), and there is great connectivity there---but > positioning yourself in South Africa doesn't really help you any more > to get to Ghana (for example) than being in the Netherlands. I've been dealing with a number of customers that are now investing - as an initial approach into Africa - in East Africa, mostly Kenya. So while South Africa seems an obvious choice for a number of reasons, Kenya is quickly becoming an immediate option to that for operators that want to kick-start something off in Africa. Also, because South Africa is most obvious most of the time, a few operators are looking to do something unique. > If you really are thinking AFRICA as in AFRICA, you probably should > use an approach that divides it into regions.  You can break it up > however you want, but if you start with 4 regions (Southern, Northern, > Western, Eastern/Central) you'll have chunks that actually hold > together from a telecoms point of view pretty well. Yes, that's a good place to start. > My best experiences (and these are about 3 years out of date) have > been in Jo'burg (Southern), Nairobi/Addis (Eastern/Central), Ghana > (Western), and Egypt (Northern), but there is a lot of interest and a > lot of progress so getting some ground knowledge would be a good idea. For East Africa, Mombasa is actually more ideal than Nairobi because you are close to all the major cable systems, being a coastal city. But most importantly, because Kenya's 1st carrier-neutral data centre (iColo) is operational there. Nairobi is some 5ms - 6ms away, so it's not the end of the world. However, iColo will also be launching in Nairobi in a few months from now. > The real bandwidth is submarine cables that go up and down the coasts > --- you can find some maps of these of varying accuracy and quality > --- while actual E/W and N/S connectivity in the center of the > continent is much more limited. SEACOM and EASSy are your main systems on the East. There is the TEAMS system, but that runs east to Fujairah. WACS is your main system on the west. You don't necessarily need to buy capacity on those systems, as there are a number of operators (including the marine operations, themselves) that have built IP backbones over those systems. Google and Facebook are building new cables around Africa over the next few years as well:     https://www.forbes.com/sites/tobyshapshak/2019/07/03/google-and-facebook-to-build-own-undersea-cables-around-africa/#68e23529de16 Angola Cables launched SACS, which covers the western part of southern Africa, South America and the southern tips of North America:     https://www.angolacables.co.ao/en/sacs-cable-to-boost-connectivity-in-africa-via-teraco-data-centres/ > There are a number of Internet-promoting organizations in Africa---you > can start with ISOC and Afrinic that sponsor a number of projects > aimed at increasing capacity there, but you'll find a bunch of people > trying to do good things.  If you are mostly interested in South > Africa, there's NAPAfrica and SAFNOG (Southern African equivalent of > NANOG) as information sources. AfPIF, iWeek and SAFNOG will all be happening between Mauritius and Johannesburg week of the 19th and week of the 26th August. Mark. From mehmet at akcin.net Wed Jul 17 09:02:07 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 17 Jul 2019 10:02:07 +0100 Subject: Colo in Africa In-Reply-To: References: Message-ID: Visit https://live.infrapedia.com and you can connect colo owners , capacity owners directly On Tue, Jul 16, 2019 at 15:34 Ken Gilmour wrote: > Hi Folks, > > I work for a Security Analytics org and we're looking to build a small POP > in Africa. I am pretty clueless about the region so I was wondering if you > could help guide me in the right direction for research? > > The challenges: > > 1. Network needs to be able to receive millions of small PPS (as > opposed to serving smaller numbers of larger files). > 2. Can't be cloud (need bare metal servers / colo). We use the full > capacity of each server, all the time. > 3. Must have good connectivity to most of the rest of Africa > 4. We can initially only have one POP > > This is not like a normal website that we can just host on "any old > provider", the requirements are very different. > > Is there a good location where we could either rent bare metal servers > (something like Internap - preferred) or colocate servers within Africa > that can serve most of the region? > > "Good" is defined as an area with stable connectivity and power, no legal > restrictions on things like encryption, and good latency (sub 100ms) to the > rest of Africa. > > Our two closest POPs are in Singapore and The Netherlands, so I'd like > something closer to the middle that can serve the rest of Africa. Middle > East will be deployed after Africa. > > I hope this is the right place to ask. > > Thanks! > > Ken > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From allenmckinleykitchen at gmail.com Wed Jul 17 14:19:31 2019 From: allenmckinleykitchen at gmail.com (Allen Kitchen) Date: Wed, 17 Jul 2019 10:19:31 -0400 Subject: Way O/T - but I know you folks are resource-rich.. Message-ID: Folks, I work with several people on legal probation for various offenses such that they are completely prohibited from internet access. In a few cases, some of these would benefit educationally from having a copy of old printed Mouser, Digi-Key, Jameco or similar catalog - just for educational purposes. I know it's been almost a decade since most stopped printing the catalogs, but is there a chance that any of you have a stack of oldies around anywhere that you're finally ready to clear out? All I need is one or two to share, and I realize that the selection and prices would be completely obsolete. Still, there is lots to learn from those. I am certainly willing to pay for shipping if anyone wants. Off-line responses preferred for the good of the list - and thanks. Blessings.. Allen Kitchen Several hats worn, but THIS particular hat: Prison-After-Care Ministries (PAC-Min) 404 Franklin St, Butler, PA 16001 412-295-7736 / allenmckinleykitchen at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregoire.ehoumi at yahoo.fr Tue Jul 16 23:20:13 2019 From: gregoire.ehoumi at yahoo.fr (Gregoire Ehoumi) Date: Tue, 16 Jul 2019 19:20:13 -0400 Subject: Colo in Africa Message-ID: Ken,You can have useful information in AFNOG mailing list (afnog at afnog.org).--Gregoire Ehoumi------ Original message------From: Ken GilmourDate: Tue, Jul 16, 2019 6:48 PMTo: C. A. Fillekes;Cc: North Group;Subject:Re: Colo in AfricaWhat matters is whether or not we can get a facility in Africa to provide service to our customers from Bare Metal Servers :)On Tue, 16 Jul 2019 at 16:07, C. A. Fillekes wrote:Are they refreshing data they've already got, though? This is the classic use case for client-side caching. On Tue, Jul 16, 2019 at 5:56 PM Ken Gilmour wrote:We have a different use case to traditional analytics - We're aimed at consumers and small businesses, so instead of a SOC with one big screen refreshing 10000 rows of only alert data every 30 seconds, we have thousands of individuals refreshing all of their data every 30 seconds because there are comparatively less alerts for individuals than enterprises.What you "should" do often doesn't translate to what you "do" do.On Tue, 16 Jul 2019 at 11:23, Valdis Kl??tnieks wrote:On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said: > These are actual real problems we face. thousands of customers load and > reload TBs of data every few seconds on their dashboards. If they're reloading TBs of data every few seconds, you really should have been doing summaries during data ingestion and only reloading the summaries. (Overlooking the fact that for dashboards, refreshing every few seconds is usually pointless because you end up looking at short-term statistical spikes rather than anything that you can react to at human speeds.?? If you *care* in real time that the number of probes on a port spiked to 457% of average for 2 seconds you need to be doing automated responses.... Custom queries are more painful - but those don't happen "every few seconds". -------------- next part -------------- An HTML attachment was scrubbed... URL: From rod.beck at unitedcablecompany.com Wed Jul 17 15:04:25 2019 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Wed, 17 Jul 2019 15:04:25 +0000 Subject: Colo in Africa In-Reply-To: References: , Message-ID: The cross continent connectivity is not going to be particularly reliable. Prone to cuts due to wars and regional turmoil. And imagine how it takes to repair problems at the physical layer. ________________________________ From: NANOG on behalf of Eric Kuhnke Sent: Wednesday, July 17, 2019 3:05 AM To: Ken Gilmour ; nanog at nanog.org list Subject: Re: Colo in Africa Without being more specific on what geographic region you want to serve, in terms of ISPs, it's hard to say. For example: If you look at submarine cable topology at layer 1, and BGP sessions, AS adjacencies between ISPs: Freetown, Sierra Leone and Monrovia, Liberia are suburbs of London, UK. If you want to reach major things in the west african region the two best connected places are Accra, Ghana and Lagos, Nigeria. On the other hand, if you put equipment topologically close to the cable landing station in Accra it will have rather poor connectivity to the east side of Africa. It's a big place and there is very little cross-continent connectivity that doesn't take the long way around via submarine fiber to Cape Town, and then up the east coast. On Tue, Jul 16, 2019 at 7:34 AM Ken Gilmour > wrote: Hi Folks, I work for a Security Analytics org and we're looking to build a small POP in Africa. I am pretty clueless about the region so I was wondering if you could help guide me in the right direction for research? The challenges: 1. Network needs to be able to receive millions of small PPS (as opposed to serving smaller numbers of larger files). 2. Can't be cloud (need bare metal servers / colo). We use the full capacity of each server, all the time. 3. Must have good connectivity to most of the rest of Africa 4. We can initially only have one POP This is not like a normal website that we can just host on "any old provider", the requirements are very different. Is there a good location where we could either rent bare metal servers (something like Internap - preferred) or colocate servers within Africa that can serve most of the region? "Good" is defined as an area with stable connectivity and power, no legal restrictions on things like encryption, and good latency (sub 100ms) to the rest of Africa. Our two closest POPs are in Singapore and The Netherlands, so I'd like something closer to the middle that can serve the rest of Africa. Middle East will be deployed after Africa. I hope this is the right place to ask. Thanks! Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From stillwaxin at gmail.com Wed Jul 17 17:00:50 2019 From: stillwaxin at gmail.com (Michael Still) Date: Wed, 17 Jul 2019 13:00:50 -0400 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, Jul 17, 2019 at 12:38 AM Hank Nussbacher wrote: > > On 16/07/2019 20:41, Job Snijders wrote: > > On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett wrote: >> >> More like do whatever you want in your own house as long as you don't infringe upon others. > > > That's where the rub is; when using "BGP optimisers" to influence public Internet routing, you cannot guarantee you won't infringe upon others. > >> >> The argument against route optimizers (assuming appropriate ingress\egress filters) is a religious one and should be treated as such. > > There is a difference between BGP optimizers and route optimizers. When was the last time you heard a complain about Akamai screwing up the global routing table over the past 12 years: > > https://www.akamai.com/us/en/about/news/press/2007-press/akamai-introduces-advanced-communications-protocol-for-accelerating-dynamic-applications.jsp > > https://developer.akamai.com/legacy/learn/Optimization/SureRoute.html > > -Hank > > Along these same lines I'd like to point out that nearly all or possibly even all incidents in recent memory are attributable to a single product whereas there has been at least one other product on the market for something like 15+ years that AFAIK has not had a single incident associated with it (and also does not create more specific prefixes as part of its operation). So is it really that one product is spoiling the market for the rest here or are they all bad? -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ From mark.tinka at seacom.mu Wed Jul 17 17:16:29 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Wed, 17 Jul 2019 19:16:29 +0200 Subject: Colo in Africa In-Reply-To: References: Message-ID: <65e530cd-72a2-fff3-5b03-fa3fbca6e871@seacom.mu> On 17/Jul/19 17:04, Rod Beck wrote: > The cross continent connectivity is not going to be particularly > reliable. Prone to cuts due to wars and regional turmoil. And imagine > how it takes to repair problems at the physical layer. I think that view is too myopic... you make it sound like Namibia, Botswana, Zimbabwe and Zambia are at war. Just like all other continents, unrest exists in some states, not all of them. For the regions the OP is interested in, there isn't any conflict there that would prevent him from deploying network. Terrestrial connectivity is not a viable solution because: * It costs too much. * Different countries (even direct neighbors) do not share social, economic or political values. * Most of the available network is in the hands of incumbents, typically controlled by the gubbermint. * It costs too much. * There isn't sufficient capacity to drive prices down when crossing 2 or more countries. * It costs too much. * Many markets are closed off and it's impossible to obtain licenses to compete. * It costs too much. * Much of the network is old and has barely been upgraded. * It costs too much. * For those bold enough to build, the terrain in some parts is not a walkover. * It costs too much. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at compuwizz.net Wed Jul 17 18:51:08 2019 From: jared at compuwizz.net (Jared Geiger) Date: Wed, 17 Jul 2019 11:51:08 -0700 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> Message-ID: I was attracted to BGP route optimizers for latency/jitter reduction and partial black hole detection scenarios. Our traffic is low enough in volume that we aren't playing the circuit commit game, but rather optimizing the path to VoIP customers who don't care that provider Y in path X-Y-Z had a fiber cut causing issues with their phone service. They are a piece of the SDN and automation fun. Hopefully the vendors will devise ways of dealing with traffic load balancing without splitting prefixes.Or maybe RPKI will become more ubiquitous and leaks won't be as painful. Similar to how DNSSEC led many ISPs to remove their DNS redirecting "search services". On Wed, Jul 17, 2019 at 10:02 AM Michael Still wrote: > On Wed, Jul 17, 2019 at 12:38 AM Hank Nussbacher > wrote: > > > > On 16/07/2019 20:41, Job Snijders wrote: > > > > On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett wrote: > >> > >> More like do whatever you want in your own house as long as you don't > infringe upon others. > > > > > > That's where the rub is; when using "BGP optimisers" to influence public > Internet routing, you cannot guarantee you won't infringe upon others. > > > >> > >> The argument against route optimizers (assuming appropriate > ingress\egress filters) is a religious one and should be treated as such. > > > > There is a difference between BGP optimizers and route optimizers. When > was the last time you heard a complain about Akamai screwing up the global > routing table over the past 12 years: > > > > > https://www.akamai.com/us/en/about/news/press/2007-press/akamai-introduces-advanced-communications-protocol-for-accelerating-dynamic-applications.jsp > > > > https://developer.akamai.com/legacy/learn/Optimization/SureRoute.html > > > > -Hank > > > > > > Along these same lines I'd like to point out that nearly all or > possibly even all incidents in recent memory are attributable to a > single product whereas there has been at least one other product on > the market for something like 15+ years that AFAIK has not had a > single incident associated with it (and also does not create more > specific prefixes as part of its operation). So is it really that one > product is spoiling the market for the rest here or are they all bad? > > -- > [stillwaxin at gmail.com ~]$ cat .signature > cat: .signature: No such file or directory > [stillwaxin at gmail.com ~]$ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Wed Jul 17 19:49:29 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 17 Jul 2019 22:49:29 +0300 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> Message-ID: On Wed, Jul 17, 2019, 9:52 PM Jared Geiger wrote: > Similar to how DNSSEC led many ISPs to remove their DNS redirecting > "search services". > Not that significant, but DNSSec, at the 4% adoption rate, didn't do that, HTTPS and HSTS did. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rod.beck at unitedcablecompany.com Wed Jul 17 22:04:35 2019 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Wed, 17 Jul 2019 22:04:35 +0000 Subject: Colo in Africa In-Reply-To: <65e530cd-72a2-fff3-5b03-fa3fbca6e871@seacom.mu> References: , <65e530cd-72a2-fff3-5b03-fa3fbca6e871@seacom.mu> Message-ID: Circuits linking Asia & Europe via Siberia have proven highly unreliable. Repairs are long and difficult. And arguably Russia is a better case scenario than Africa. More politically stable. Better finances. Better basic infrastructure. ________________________________ From: NANOG on behalf of Mark Tinka Sent: Wednesday, July 17, 2019 7:16 PM To: nanog at nanog.org Subject: Re: Colo in Africa On 17/Jul/19 17:04, Rod Beck wrote: The cross continent connectivity is not going to be particularly reliable. Prone to cuts due to wars and regional turmoil. And imagine how it takes to repair problems at the physical layer. I think that view is too myopic... you make it sound like Namibia, Botswana, Zimbabwe and Zambia are at war. Just like all other continents, unrest exists in some states, not all of them. For the regions the OP is interested in, there isn't any conflict there that would prevent him from deploying network. Terrestrial connectivity is not a viable solution because: * It costs too much. * Different countries (even direct neighbors) do not share social, economic or political values. * Most of the available network is in the hands of incumbents, typically controlled by the gubbermint. * It costs too much. * There isn't sufficient capacity to drive prices down when crossing 2 or more countries. * It costs too much. * Many markets are closed off and it's impossible to obtain licenses to compete. * It costs too much. * Much of the network is old and has barely been upgraded. * It costs too much. * For those bold enough to build, the terrain in some parts is not a walkover. * It costs too much. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nik at neko.id.au Wed Jul 17 22:16:07 2019 From: nik at neko.id.au (Nikolas Geyer) Date: Wed, 17 Jul 2019 22:16:07 +0000 Subject: Performance metrics used in commercial BGP route optimizers In-Reply-To: References: <1522786687.3825.1563288576033.JavaMail.mhammett@ThunderFuck> <162947220.3898.1563290980353.JavaMail.mhammett@ThunderFuck> , Message-ID: You can achieve performance based routing using latency/jitter and partial blackhole detection as your metrics without resorting to prefix splitting - adjust local preferences on received routes, don’t install received routes, add static routes, change MPLS label if doing EPE etc. I see very few, if any, use cases for prefix splitting that could not be accommodated for via other mechanisms that do not leave a network in a “locked and loaded” dangerous state. But it’s a free world and market economy (at least in the NA part of NANOG) so people will use this stuff unfortunately. But take a look at the Twitter link Job supplied earlier where a vendor confirmed they are insecure mode of operation by default. Why??? Being good corporate citizens the model should be secure by default and you can remove the safety if you know what you’re doing (ideally you couldn’t remove the safety at all, but see above comment around free market). Handing people software with the safety removed and assuming they won’t pull the trigger is reckless business conduct IMO. But at the end of the day, it’s all about the almighty dollar and if a customer can be gained where the path is resistance is less giving them an insecure product by default, typically because the customer doesn’t have the technical knowledge to understand what they’re actually doing, then so be it. Sent from my iPhone On Jul 17, 2019, at 2:53 PM, Jared Geiger > wrote: I was attracted to BGP route optimizers for latency/jitter reduction and partial black hole detection scenarios. Our traffic is low enough in volume that we aren't playing the circuit commit game, but rather optimizing the path to VoIP customers who don't care that provider Y in path X-Y-Z had a fiber cut causing issues with their phone service. They are a piece of the SDN and automation fun. Hopefully the vendors will devise ways of dealing with traffic load balancing without splitting prefixes.Or maybe RPKI will become more ubiquitous and leaks won't be as painful. Similar to how DNSSEC led many ISPs to remove their DNS redirecting "search services". On Wed, Jul 17, 2019 at 10:02 AM Michael Still > wrote: On Wed, Jul 17, 2019 at 12:38 AM Hank Nussbacher > wrote: > > On 16/07/2019 20:41, Job Snijders wrote: > > On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett > wrote: >> >> More like do whatever you want in your own house as long as you don't infringe upon others. > > > That's where the rub is; when using "BGP optimisers" to influence public Internet routing, you cannot guarantee you won't infringe upon others. > >> >> The argument against route optimizers (assuming appropriate ingress\egress filters) is a religious one and should be treated as such. > > There is a difference between BGP optimizers and route optimizers. When was the last time you heard a complain about Akamai screwing up the global routing table over the past 12 years: > > https://www.akamai.com/us/en/about/news/press/2007-press/akamai-introduces-advanced-communications-protocol-for-accelerating-dynamic-applications.jsp > > https://developer.akamai.com/legacy/learn/Optimization/SureRoute.html > > -Hank > > Along these same lines I'd like to point out that nearly all or possibly even all incidents in recent memory are attributable to a single product whereas there has been at least one other product on the market for something like 15+ years that AFAIK has not had a single incident associated with it (and also does not create more specific prefixes as part of its operation). So is it really that one product is spoiling the market for the rest here or are they all bad? -- [stillwaxin at gmail.com ~]$ cat .signature cat: .signature: No such file or directory [stillwaxin at gmail.com ~]$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbothe at me.com Wed Jul 17 23:10:42 2019 From: jbothe at me.com (JASON BOTHE) Date: Wed, 17 Jul 2019 18:10:42 -0500 Subject: Fiber providers - Englewood / Centennial Colorado Message-ID: Hi all Just curious if you know of any fiber providers other than CL or Zayo in the Englewood/Centennial area. Having a really tough time finding routes that avoid the Solarium at Quebec / E Orchard as well as 910 15th St. Seems there are so many single points of failure and collapsed routes that all lead to these two locations to get diverse long haul. Many thanks. J~ From mikebolitho at gmail.com Wed Jul 17 23:18:53 2019 From: mikebolitho at gmail.com (Mike Bolitho) Date: Wed, 17 Jul 2019 16:18:53 -0700 Subject: Fiber providers - Englewood / Centennial Colorado In-Reply-To: References: Message-ID: Denver is a tough market for diversity's sake. Just about everyone that was there was gobbled up by what is now CenturyLink. -Mike Bolitho On Wed, Jul 17, 2019, 4:12 PM JASON BOTHE via NANOG wrote: > Hi all > > Just curious if you know of any fiber providers other than CL or Zayo in > the Englewood/Centennial area. Having a really tough time finding routes > that avoid the Solarium at Quebec / E Orchard as well as 910 15th St. Seems > there are so many single points of failure and collapsed routes that all > lead to these two locations to get diverse long haul. > > Many thanks. > > J~ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj at pcguys.us Thu Jul 18 00:15:19 2019 From: tj at pcguys.us (TJ Trout) Date: Wed, 17 Jul 2019 17:15:19 -0700 Subject: Bgpmon alternatives? In-Reply-To: <67F895A2-1F69-4442-AA0D-7BF415FBA893@as397444.net> References: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> <20190616094827.GA34940@meow.BKantor.net> <6429449a-e076-b4db-62f0-1eb5fc43454f@he.net> <20190616112050.GA35876@meow.BKantor.net> <67F895A2-1F69-4442-AA0D-7BF415FBA893@as397444.net> Message-ID: Anyone know of a hosted alternative to bgpmon? I'm testing Qrator but I can't determine if it will notify in real-time of a prefix hijack? On Sun, Jun 16, 2019 at 9:23 AM Matt Corallo wrote: > There's also https://github.com/NLNOG/bgpalerter (which I believe they're > trying to turn into a website frontend based on RIS, but I run it with > patches for as_path regexes and it works pretty well). > > On Jun 16, 2019, at 07:40, Michael Hallgren wrote: > > RIS Live API is a choice for this. > > mh > Le 16 juin 2019, à 13:21, Brian Kantor a écrit: >> >> That would be wonderful. Thank you! >> - Brian >> >> >> On Sun, Jun 16, 2019 at 03:59:29AM -0700, Mike Leber wrote: >> >>> I'm sure if it doesn't do exactly that already, we can add it shortly. >>> >>> Some of planned functionality for hijack detection is already live. >>> That's one of the main reasons for creating this service. >>> >>> Mike. >>> >>> On 6/16/19 2:48 AM, Brian Kantor wrote: >>> >>>> On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote: >>>> >>>>> As a beta service you can try out rt-bgp.he.net. This is a real time >>>>> bgp monitoring service we are developing. >>>>> >>>> It's interesting, but I don't see any way to do what I primarily >>>> use the existing BGPMon for: watch for hijacks. >>>> >>>> That is, set up one or more prefixes to be continuously monitored >>>> and have the monitor send me an email alert when that prefix or a >>>> subnet of it begins to be announced by someone new. >>>> >>>> For example, if I have told it to monitor 44.0.0.0/8 and someone >>>> somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very >>>> much like to know about that, along with details of who and where. >>>> >>>> Then if that announcement is authorized, I can tell the monitoring >>>> service that this new entry is NOT a hijack, and it won't bug me >>>> about it again. >>>> >>>> Can it be persuaded to do this? >>>> - Brian >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Jul 18 00:54:49 2019 From: randy at psg.com (Randy Bush) Date: Wed, 17 Jul 2019 17:54:49 -0700 Subject: netstat -s Message-ID: do folk use `netstat -s` to help diagnose on routers/switches? randy From ximaera at gmail.com Thu Jul 18 05:44:48 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Thu, 18 Jul 2019 08:44:48 +0300 Subject: Bgpmon alternatives? In-Reply-To: References: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> <20190616094827.GA34940@meow.BKantor.net> <6429449a-e076-b4db-62f0-1eb5fc43454f@he.net> <20190616112050.GA35876@meow.BKantor.net> <67F895A2-1F69-4442-AA0D-7BF415FBA893@as397444.net> Message-ID: On Thu, Jul 18, 2019 at 3:16 AM TJ Trout wrote: > Anyone know of a hosted alternative to bgpmon? I'm testing > Qrator but I can't determine if it will notify in real-time of a > prefix hijack? Qrator guy there. Real-time notifications are there but are only available on a commercial basis, because basically real time is expensive to compute. The rest is free. -- Töma From mark.tinka at seacom.mu Thu Jul 18 08:25:07 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 18 Jul 2019 10:25:07 +0200 Subject: Colo in Africa In-Reply-To: References: <65e530cd-72a2-fff3-5b03-fa3fbca6e871@seacom.mu> Message-ID: <359e0e39-b607-dda6-a97d-3e38dd627669@seacom.mu> On 18/Jul/19 00:04, Rod Beck wrote: > Circuits linking Asia & Europe via Siberia have proven highly > unreliable. Repairs are long and difficult. And arguably Russia is a > better case scenario than Africa. More politically stable. Better > finances. Better basic infrastructure.  Wasn't aware Russia was a continent... Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nuclearcat at nuclearcat.com Thu Jul 18 09:04:38 2019 From: nuclearcat at nuclearcat.com (Denys Fedoryshchenko) Date: Thu, 18 Jul 2019 12:04:38 +0300 Subject: Colo in Africa In-Reply-To: <65e530cd-72a2-fff3-5b03-fa3fbca6e871@seacom.mu> References: <65e530cd-72a2-fff3-5b03-fa3fbca6e871@seacom.mu> Message-ID: <6f9281993a228fe41c3ad9453206d22a@nuclearcat.com> Africa, Russia... You can take as example Lebanon. Capital and major city in tiny country, ~40km away from each other, and only way you can get 2 points connected over microwaves(due mountains - several hops), over "licensed" providers, DSP, who hook this points for $10-$30/mbps/month. And many of them don't have support at evenings and weekend. Of course, due crappy electricity in country and economical situation, discharged batteries and outages at evening/night at "licensed" DSP sites - common case. The laws of the country are so cool, that it is even forbidden to lay optics from the building standing next to other building, unless you are government monopoly (and they don't sell fiber connectivity). In Africa, many people do not have electricity at all and cook on open fire, i imagine what difficulties they have with connectivity. The last time when I worked with a team on study to invest in telecom in Africa - results discouraged even trying to engage in telecom subject there. I think the only ones who are interested in decent connectivity there - mobile operators. Maybe worth to find connections and talk to them. On 2019-07-17 20:16, Mark Tinka wrote: > On 17/Jul/19 17:04, Rod Beck wrote: > >> The cross continent connectivity is not going to be particularly >> reliable. Prone to cuts due to wars and regional turmoil. And >> imagine how it takes to repair problems at the physical layer. > > I think that view is too myopic... you make it sound like Namibia, > Botswana, Zimbabwe and Zambia are at war. Just like all other > continents, unrest exists in some states, not all of them. > > For the regions the OP is interested in, there isn't any conflict > there that would prevent him from deploying network. > > Terrestrial connectivity is not a viable solution because: > > * It costs too much. > * Different countries (even direct neighbors) do not share social, > economic or political values. > * Most of the available network is in the hands of incumbents, > typically controlled by the gubbermint. > * It costs too much. > * There isn't sufficient capacity to drive prices down when crossing > 2 or more countries. > * It costs too much. > * Many markets are closed off and it's impossible to obtain licenses > to compete. > * It costs too much. > * Much of the network is old and has barely been upgraded. > * It costs too much. > * For those bold enough to build, the terrain in some parts is not a > walkover. > > * It costs too much. > > Mark. From hank at efes.iucc.ac.il Thu Jul 18 09:42:53 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 18 Jul 2019 12:42:53 +0300 Subject: Bgpmon alternatives? In-Reply-To: References: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> <20190616094827.GA34940@meow.BKantor.net> <6429449a-e076-b4db-62f0-1eb5fc43454f@he.net> <20190616112050.GA35876@meow.BKantor.net> <67F895A2-1F69-4442-AA0D-7BF415FBA893@as397444.net> Message-ID: <1c78bd41-a877-5f5f-8bed-3ecfbfa6694d@efes.iucc.ac.il> On 18/07/2019 08:44, Töma Gavrichenkov wrote: > On Thu, Jul 18, 2019 at 3:16 AM TJ Trout wrote: >> Anyone know of a hosted alternative to bgpmon? I'm testing >> Qrator but I can't determine if it will notify in real-time of a >> prefix hijack? > Qrator guy there. > Real-time notifications are there but are only available on a > commercial basis, because basically real time is expensive to compute. > The rest is free. > > -- > Töma > What about once a day notification of BGP hijack?  Is that also expensive to compute?  I have an account and cannot find any documentation of realtime notifications nor its cost.  All I found was this - https://qrator.net/en/pricing .   Can you send links to the BGP hijack notification service and its cost? Thanks, -Hank From jhellenthal at dataix.net Thu Jul 18 10:28:27 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Thu, 18 Jul 2019 05:28:27 -0500 Subject: netstat -s In-Reply-To: References: Message-ID: I know I have a few times after seeing SNMP bumps of errors but mainly just so I could get up to the moment error rates or stats. Other than that though it’s a very minor usage IMO -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. > On Jul 17, 2019, at 19:55, Randy Bush wrote: > > do folk use `netstat -s` to help diagnose on routers/switches? > > randy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available URL: From rwfireguru at gmail.com Thu Jul 18 13:01:16 2019 From: rwfireguru at gmail.com (Robert Webb) Date: Thu, 18 Jul 2019 09:01:16 -0400 Subject: Antennas in the data center Message-ID: Anyone out there deal with data center design? Looking for any info available which provides guidelines on putting antennas, like LTE booster, in the data center. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Thu Jul 18 13:08:43 2019 From: matt at netfire.net (Matt Harris) Date: Thu, 18 Jul 2019 08:08:43 -0500 Subject: Antennas in the data center In-Reply-To: References: Message-ID: On Thu, Jul 18, 2019 at 8:01 AM Robert Webb wrote: > Anyone out there deal with data center design? > > Looking for any info available which provides guidelines on putting > antennas, like LTE booster, in the data center. > Not quite sure what you're looking for here Robert. As far as placing something like an LTE booster in a data center, you'd just use common sense (place it in the best possible place from a connectivity standpoint). Is this something you're considering in order to provide service to folks who run LTE backup connections on their gear (like serial concentrators)? Wireless/RF site surveys and how to do them effectively are pretty well-documented at this point. Or are you asking about roof access/deploying antennas on a rooftop safely/securely? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwfireguru at gmail.com Thu Jul 18 13:30:31 2019 From: rwfireguru at gmail.com (Robert Webb) Date: Thu, 18 Jul 2019 09:30:31 -0400 Subject: Antennas in the data center In-Reply-To: References: Message-ID: So I have a situation where I am trying to get LTE to an out of band router and there is no signal available in the data center. There was a booster setup purchased and I have a manager telling me that standards, industry and not local, prohibit the installation. He has yet to produce any documented industry standard so I thought I would reach out to see if anyone here has heard of this. We fall under NIST controls and I haven't found anything there and have also looked at TIA and not found anything. Thanks... On Thu, Jul 18, 2019 at 9:09 AM Matt Harris wrote: > On Thu, Jul 18, 2019 at 8:01 AM Robert Webb wrote: > >> Anyone out there deal with data center design? >> >> Looking for any info available which provides guidelines on putting >> antennas, like LTE booster, in the data center. >> > > Not quite sure what you're looking for here Robert. As far as placing > something like an LTE booster in a data center, you'd just use common sense > (place it in the best possible place from a connectivity standpoint). Is > this something you're considering in order to provide service to folks who > run LTE backup connections on their gear (like serial concentrators)? > Wireless/RF site surveys and how to do them effectively are pretty > well-documented at this point. > > Or are you asking about roof access/deploying antennas on a rooftop > safely/securely? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Thu Jul 18 13:35:28 2019 From: matt at netfire.net (Matt Harris) Date: Thu, 18 Jul 2019 08:35:28 -0500 Subject: Antennas in the data center In-Reply-To: References: Message-ID: On Thu, Jul 18, 2019 at 8:30 AM Robert Webb wrote: > So I have a situation where I am trying to get LTE to an out of band > router and there is no signal available in the data center. There was a > booster setup purchased and I have a manager telling me that standards, > industry and not local, prohibit the installation. > > He has yet to produce any documented industry standard so I thought I > would reach out to see if anyone here has heard of this. > > We fall under NIST controls and I haven't found anything there and have > also looked at TIA and not found anything. > I've never heard of any industry standard preventing such a thing. There are a few questions this raises though. The first and most obvious being, are you sure that a "booster setup" will actually help? Have you done a site survey to figure out how to actually accomplish what you need to accomplish? The other question is whether perhaps the issue he has is with the specific "booster setup" chosen. Perhaps there's something naughty about it, in particular, that has caused him to not want it in his facility (cheap Chinese radios are known, for example, for polluting the spectrum outside of the frequencies that they are designed to operate within.) Maybe he has other folks doing legit RF stuff in there and doesn't want to risk that pollution? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwfireguru at gmail.com Thu Jul 18 13:54:32 2019 From: rwfireguru at gmail.com (Robert Webb) Date: Thu, 18 Jul 2019 09:54:32 -0400 Subject: Antennas in the data center In-Reply-To: References: Message-ID: Thanks for the info on the standards portion. The booster configuration has been setup in a test scenario where the external antenna has been placed outside with line of site to the tower, less than a tenth of a mile away, with the feed cable run down a hallway indoors, the booster connected, and the indoor antenna connected (not in the data center though). Test with LTE equipment, ie. cell phones, has brought the signal from barely a single bar of 1x to 4 bars of LTE with good speeds. Manager has no issue with equipment purchased and has polled the other tenants in the same data center and they are also OK with it. He has just cited that there is some standard but has not been forthcoming with any documentation. I figured if there was such a standard then someone here would probably have run across it at some time. I am getting the feeling this is just something he has heard or been told in the past and really doesn't know. On Thu, Jul 18, 2019 at 9:35 AM Matt Harris wrote: > On Thu, Jul 18, 2019 at 8:30 AM Robert Webb wrote: > >> So I have a situation where I am trying to get LTE to an out of band >> router and there is no signal available in the data center. There was a >> booster setup purchased and I have a manager telling me that standards, >> industry and not local, prohibit the installation. >> >> He has yet to produce any documented industry standard so I thought I >> would reach out to see if anyone here has heard of this. >> >> We fall under NIST controls and I haven't found anything there and have >> also looked at TIA and not found anything. >> > > I've never heard of any industry standard preventing such a thing. There > are a few questions this raises though. The first and most obvious being, > are you sure that a "booster setup" will actually help? Have you done a > site survey to figure out how to actually accomplish what you need to > accomplish? The other question is whether perhaps the issue he has is with > the specific "booster setup" chosen. Perhaps there's something naughty > about it, in particular, that has caused him to not want it in his facility > (cheap Chinese radios are known, for example, for polluting the spectrum > outside of the frequencies that they are designed to operate within.) Maybe > he has other folks doing legit RF stuff in there and doesn't want to risk > that pollution? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Thu Jul 18 13:57:58 2019 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 18 Jul 2019 08:57:58 -0500 (CDT) Subject: Fiber providers - Englewood / Centennial Colorado In-Reply-To: References: Message-ID: <1563909227.5799.1563458275226.JavaMail.mhammett@ThunderFuck> Depending on what you're trying to do, you might find some bits and pieces from Windstream, Crown Castle, UPN, and XO. They're all in that Englewood - Centennial area in different ways with different capabilities. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "JASON BOTHE via NANOG" To: nanog at nanog.org Sent: Wednesday, July 17, 2019 6:10:42 PM Subject: Fiber providers - Englewood / Centennial Colorado Hi all Just curious if you know of any fiber providers other than CL or Zayo in the Englewood/Centennial area. Having a really tough time finding routes that avoid the Solarium at Quebec / E Orchard as well as 910 15th St. Seems there are so many single points of failure and collapsed routes that all lead to these two locations to get diverse long haul. Many thanks. J~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Thu Jul 18 14:00:41 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 18 Jul 2019 07:00:41 -0700 Subject: Antennas in the data center In-Reply-To: References: Message-ID: <88d83650-730c-203c-ea3b-86d6fc47d3cc@rollernet.us> On 7/18/19 6:54 AM, Robert Webb wrote: > > Manager has no issue with equipment purchased and has polled the other > tenants in the same data center and they are also OK with it. He has > just cited that there is some standard but has not been forthcoming with > any documentation. > Never heard of such a "standard". Data centers usually either allow antennas or they don't as a policy of their own. From mfidelman at meetinghouse.net Thu Jul 18 14:25:53 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 18 Jul 2019 10:25:53 -0400 Subject: Antennas in the data center In-Reply-To: References: Message-ID: <81b1f09c-1f92-19d6-fa33-fa89363a13cd@meetinghouse.net> It's not quite clear what you mean by "NIST controls" - NIST publishes standards & guidelines, they don't regulate. Now, if you're running a Federal data center, or one for a government contractor - perhaps you're referring to "NIST Compliance" under FISMA (the Federal Information Security Management Act) - which involves compliance with a bunch of FIPS (Federal Information Processing Standards).  See https://csrc.nist.gov/topics/laws-and-regulations/laws/fisma & https://digitalguardian.com/blog/what-nist-compliance for some background. Now if I had to guess - I expect that there are some security standards that would prohibit placing an antenna inside a data center handling any kind of sensitive or classified data. If you have any systems, in the data center, that require security certification & accreditation, I expect your accreditation authority would be the person to talk to.  Or your information security officer. On 7/18/19 9:30 AM, Robert Webb wrote: > So I have a situation where I am trying to get LTE to an out of band > router and there is no signal available in the data center. There was > a booster setup purchased and I have a manager telling me that > standards, industry and not local, prohibit the installation. > > He has yet to produce any documented industry standard so I thought I > would reach out to see if anyone here has heard of this. > > We fall under NIST controls and I haven't found anything there and > have also looked at TIA and not found anything. > > Thanks... > > On Thu, Jul 18, 2019 at 9:09 AM Matt Harris > wrote: > > On Thu, Jul 18, 2019 at 8:01 AM Robert Webb > wrote: > > Anyone out there deal with data center design? > > Looking for any info available which provides guidelines on > putting antennas, like LTE booster, in the data center. > > > Not quite sure what you're looking for here Robert. As far as > placing something like an LTE booster in a data center, you'd just > use common sense (place it in the best possible place from a > connectivity standpoint). Is this something you're considering in > order to provide service to folks who run LTE backup connections > on their gear (like serial concentrators)? Wireless/RF site > surveys and how to do them effectively are pretty well-documented > at this point. > > Or are you asking about roof access/deploying antennas on a > rooftop safely/securely? > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no one knows why. ... unknown -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiel at flowtools.net Thu Jul 18 15:32:46 2019 From: jschiel at flowtools.net (John Schiel) Date: Thu, 18 Jul 2019 09:32:46 -0600 Subject: Antennas in the data center In-Reply-To: References: Message-ID: <9d059342-a14d-3c89-1f63-71de6c033c47@flowtools.net> On 7/18/19 7:54 AM, Robert Webb wrote: > Thanks for the info on the standards portion. > > The booster configuration has been setup in a test scenario where the > external antenna has been placed outside with line of site to the > tower, less than a tenth of a mile away, with the feed cable run down > a hallway indoors, the booster connected, and the indoor antenna > connected (not in the data center though). > > Test with LTE equipment, ie. cell phones, has brought the signal from > barely a single bar of 1x to 4 bars of LTE with good speeds. > > Manager has no issue with equipment purchased and has polled the other > tenants in the same data center and they are also OK with it. He has > just cited that there is some standard but has not been forthcoming > with any documentation. > > I figured if there was such a standard then someone here would > probably have run across it at some time. Is he denying on some industry "LTE" standard or some other data center or security standard? > > I am getting the feeling this is just something he has heard or been > told in the past and really doesn't know. > > > > On Thu, Jul 18, 2019 at 9:35 AM Matt Harris > wrote: > > On Thu, Jul 18, 2019 at 8:30 AM Robert Webb > wrote: > > So I have a situation where I am trying to get LTE to an out > of band router and there is no signal available in the data > center. There was a booster setup purchased and I have a > manager telling me that standards, industry and not local, > prohibit the installation. > > He has yet to produce any documented industry standard so I > thought I would reach out to see if anyone here has heard of this. > > We fall under NIST controls and I haven't found anything there > and have also looked at TIA and not found anything. > > > I've never heard of any industry standard preventing such a thing. > There are a few questions this raises though. The first and most > obvious being, are you sure that a "booster setup" will actually > help? Have you done a site survey to figure out how to actually > accomplish what you need to accomplish? The other question is > whether perhaps the issue he has is with the specific "booster > setup" chosen. Perhaps there's something naughty about it, in > particular, that has caused him to not want it in his facility > (cheap Chinese radios are known, for example, for polluting the > spectrum outside of the frequencies that they are designed to > operate within.) Maybe he has other folks doing legit RF stuff in > there and doesn't want to risk that pollution? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lathama at gmail.com Thu Jul 18 15:37:52 2019 From: lathama at gmail.com (Andrew Latham) Date: Thu, 18 Jul 2019 10:37:52 -0500 Subject: Antennas in the data center In-Reply-To: <81b1f09c-1f92-19d6-fa33-fa89363a13cd@meetinghouse.net> References: <81b1f09c-1f92-19d6-fa33-fa89363a13cd@meetinghouse.net> Message-ID: I agree with Miles that this is more of an infiltration and or ex-filtration of data issue. Can you firewall at the booster? Out of Band management is tricky when LTE bandwidth is so high that one could export large quantities of data. On Thu, Jul 18, 2019 at 9:28 AM Miles Fidelman wrote: > It's not quite clear what you mean by "NIST controls" - NIST publishes > standards & guidelines, they don't regulate. > > Now, if you're running a Federal data center, or one for a government > contractor - perhaps you're referring to "NIST Compliance" under FISMA (the > Federal Information Security Management Act) - which involves compliance > with a bunch of FIPS (Federal Information Processing Standards). See > https://csrc.nist.gov/topics/laws-and-regulations/laws/fisma & > https://digitalguardian.com/blog/what-nist-compliance for some background. > > Now if I had to guess - I expect that there are some security standards > that would prohibit placing an antenna inside a data center handling any > kind of sensitive or classified data. > > If you have any systems, in the data center, that require security > certification & accreditation, I expect your accreditation authority would > be the person to talk to. Or your information security officer. > On 7/18/19 9:30 AM, Robert Webb wrote: > > So I have a situation where I am trying to get LTE to an out of band > router and there is no signal available in the data center. There was a > booster setup purchased and I have a manager telling me that standards, > industry and not local, prohibit the installation. > > He has yet to produce any documented industry standard so I thought I > would reach out to see if anyone here has heard of this. > > We fall under NIST controls and I haven't found anything there and have > also looked at TIA and not found anything. > > Thanks... > > On Thu, Jul 18, 2019 at 9:09 AM Matt Harris wrote: > >> On Thu, Jul 18, 2019 at 8:01 AM Robert Webb wrote: >> >>> Anyone out there deal with data center design? >>> >>> Looking for any info available which provides guidelines on putting >>> antennas, like LTE booster, in the data center. >>> >> >> Not quite sure what you're looking for here Robert. As far as placing >> something like an LTE booster in a data center, you'd just use common sense >> (place it in the best possible place from a connectivity standpoint). Is >> this something you're considering in order to provide service to folks who >> run LTE backup connections on their gear (like serial concentrators)? >> Wireless/RF site surveys and how to do them effectively are pretty >> well-documented at this point. >> >> Or are you asking about roof access/deploying antennas on a rooftop >> safely/securely? >> >> -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > Theory is when you know everything but nothing works. > Practice is when everything works but no one knows why. > In our lab, theory and practice are combined: > nothing works and no one knows why. ... unknown > > -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahebert at pubnix.net Thu Jul 18 15:39:45 2019 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 18 Jul 2019 11:39:45 -0400 Subject: Antennas in the data center In-Reply-To: References: Message-ID:     Hi,     Some PCI auditors (loaded words right there) will freak out and you're stuck explaining the concept of life all over again...     Anyway, those works in a DC (25k') built inside a support structure for a train station =D.     https://www.wilsonamplifiers.com/     Wilson Pro 70 Plus Select (50 Ohm) Omni/Dome Kit | 462327     SKU: WA462327 On 2019-07-18 09:35, Matt Harris wrote: > On Thu, Jul 18, 2019 at 8:30 AM Robert Webb > wrote: > > So I have a situation where I am trying to get LTE to an out of > band router and there is no signal available in the data center. > There was a booster setup purchased and I have a manager telling > me that standards, industry and not local, prohibit the installation. > > He has yet to produce any documented industry standard so I > thought I would reach out to see if anyone here has heard of this. > > We fall under NIST controls and I haven't found anything there and > have also looked at TIA and not found anything. > > > I've never heard of any industry standard preventing such a thing. > There are a few questions this raises though. The first and most > obvious being, are you sure that a "booster setup" will actually help? > Have you done a site survey to figure out how to actually accomplish > what you need to accomplish? The other question is whether perhaps the > issue he has is with the specific "booster setup" chosen. Perhaps > there's something naughty about it, in particular, that has caused him > to not want it in his facility (cheap Chinese radios are known, for > example, for polluting the spectrum outside of the frequencies that > they are designed to operate within.) Maybe he has other folks doing > legit RF stuff in there and doesn't want to risk that pollution? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwfireguru at gmail.com Thu Jul 18 15:51:59 2019 From: rwfireguru at gmail.com (Robert Webb) Date: Thu, 18 Jul 2019 11:51:59 -0400 Subject: Antennas in the data center In-Reply-To: References: <81b1f09c-1f92-19d6-fa33-fa89363a13cd@meetinghouse.net> Message-ID: The is booster to only get an LTE signal from Verizon into the data center.. For our purpose of needing it, we have a cisco router with LTE for our system as a back management access in case of loss to the system by normal means. On Thu, Jul 18, 2019 at 11:39 AM Andrew Latham wrote: > I agree with Miles that this is more of an infiltration and or > ex-filtration of data issue. Can you firewall at the booster? Out of Band > management is tricky when LTE bandwidth is so high that one could export > large quantities of data. > > On Thu, Jul 18, 2019 at 9:28 AM Miles Fidelman > wrote: > >> It's not quite clear what you mean by "NIST controls" - NIST publishes >> standards & guidelines, they don't regulate. >> >> Now, if you're running a Federal data center, or one for a government >> contractor - perhaps you're referring to "NIST Compliance" under FISMA (the >> Federal Information Security Management Act) - which involves compliance >> with a bunch of FIPS (Federal Information Processing Standards). See >> https://csrc.nist.gov/topics/laws-and-regulations/laws/fisma & >> https://digitalguardian.com/blog/what-nist-compliance for some >> background. >> >> Now if I had to guess - I expect that there are some security standards >> that would prohibit placing an antenna inside a data center handling any >> kind of sensitive or classified data. >> >> If you have any systems, in the data center, that require security >> certification & accreditation, I expect your accreditation authority would >> be the person to talk to. Or your information security officer. >> On 7/18/19 9:30 AM, Robert Webb wrote: >> >> So I have a situation where I am trying to get LTE to an out of band >> router and there is no signal available in the data center. There was a >> booster setup purchased and I have a manager telling me that standards, >> industry and not local, prohibit the installation. >> >> He has yet to produce any documented industry standard so I thought I >> would reach out to see if anyone here has heard of this. >> >> We fall under NIST controls and I haven't found anything there and have >> also looked at TIA and not found anything. >> >> Thanks... >> >> On Thu, Jul 18, 2019 at 9:09 AM Matt Harris wrote: >> >>> On Thu, Jul 18, 2019 at 8:01 AM Robert Webb >>> wrote: >>> >>>> Anyone out there deal with data center design? >>>> >>>> Looking for any info available which provides guidelines on putting >>>> antennas, like LTE booster, in the data center. >>>> >>> >>> Not quite sure what you're looking for here Robert. As far as placing >>> something like an LTE booster in a data center, you'd just use common sense >>> (place it in the best possible place from a connectivity standpoint). Is >>> this something you're considering in order to provide service to folks who >>> run LTE backup connections on their gear (like serial concentrators)? >>> Wireless/RF site surveys and how to do them effectively are pretty >>> well-documented at this point. >>> >>> Or are you asking about roof access/deploying antennas on a rooftop >>> safely/securely? >>> >>> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> Theory is when you know everything but nothing works. >> Practice is when everything works but no one knows why. >> In our lab, theory and practice are combined: >> nothing works and no one knows why. ... unknown >> >> > > -- > - Andrew "lathama" Latham - > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Thu Jul 18 16:25:03 2019 From: beecher at beecher.cc (Tom Beecher) Date: Thu, 18 Jul 2019 12:25:03 -0400 Subject: Antennas in the data center In-Reply-To: References: <81b1f09c-1f92-19d6-fa33-fa89363a13cd@meetinghouse.net> Message-ID: Being told "industry standard" seems like a cop out for "we don't want to do it". Which is a completely legitimate response, but ideally they'd just come out and say that. On Thu, Jul 18, 2019 at 11:54 AM Robert Webb wrote: > The is booster to only get an LTE signal from Verizon into the data > center.. > > For our purpose of needing it, we have a cisco router with LTE for our > system as a back management access in case of loss to the system by normal > means. > > On Thu, Jul 18, 2019 at 11:39 AM Andrew Latham wrote: > >> I agree with Miles that this is more of an infiltration and or >> ex-filtration of data issue. Can you firewall at the booster? Out of Band >> management is tricky when LTE bandwidth is so high that one could export >> large quantities of data. >> >> On Thu, Jul 18, 2019 at 9:28 AM Miles Fidelman < >> mfidelman at meetinghouse.net> wrote: >> >>> It's not quite clear what you mean by "NIST controls" - NIST publishes >>> standards & guidelines, they don't regulate. >>> >>> Now, if you're running a Federal data center, or one for a government >>> contractor - perhaps you're referring to "NIST Compliance" under FISMA (the >>> Federal Information Security Management Act) - which involves compliance >>> with a bunch of FIPS (Federal Information Processing Standards). See >>> https://csrc.nist.gov/topics/laws-and-regulations/laws/fisma & >>> https://digitalguardian.com/blog/what-nist-compliance for some >>> background. >>> >>> Now if I had to guess - I expect that there are some security standards >>> that would prohibit placing an antenna inside a data center handling any >>> kind of sensitive or classified data. >>> >>> If you have any systems, in the data center, that require security >>> certification & accreditation, I expect your accreditation authority would >>> be the person to talk to. Or your information security officer. >>> On 7/18/19 9:30 AM, Robert Webb wrote: >>> >>> So I have a situation where I am trying to get LTE to an out of band >>> router and there is no signal available in the data center. There was a >>> booster setup purchased and I have a manager telling me that standards, >>> industry and not local, prohibit the installation. >>> >>> He has yet to produce any documented industry standard so I thought I >>> would reach out to see if anyone here has heard of this. >>> >>> We fall under NIST controls and I haven't found anything there and have >>> also looked at TIA and not found anything. >>> >>> Thanks... >>> >>> On Thu, Jul 18, 2019 at 9:09 AM Matt Harris wrote: >>> >>>> On Thu, Jul 18, 2019 at 8:01 AM Robert Webb >>>> wrote: >>>> >>>>> Anyone out there deal with data center design? >>>>> >>>>> Looking for any info available which provides guidelines on putting >>>>> antennas, like LTE booster, in the data center. >>>>> >>>> >>>> Not quite sure what you're looking for here Robert. As far as placing >>>> something like an LTE booster in a data center, you'd just use common sense >>>> (place it in the best possible place from a connectivity standpoint). Is >>>> this something you're considering in order to provide service to folks who >>>> run LTE backup connections on their gear (like serial concentrators)? >>>> Wireless/RF site surveys and how to do them effectively are pretty >>>> well-documented at this point. >>>> >>>> Or are you asking about roof access/deploying antennas on a rooftop >>>> safely/securely? >>>> >>>> -- >>> In theory, there is no difference between theory and practice. >>> In practice, there is. .... Yogi Berra >>> >>> Theory is when you know everything but nothing works. >>> Practice is when everything works but no one knows why. >>> In our lab, theory and practice are combined: >>> nothing works and no one knows why. ... unknown >>> >>> >> >> -- >> - Andrew "lathama" Latham - >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Thu Jul 18 16:40:39 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Thu, 18 Jul 2019 18:40:39 +0200 Subject: Colo in Africa In-Reply-To: <6f9281993a228fe41c3ad9453206d22a@nuclearcat.com> References: <65e530cd-72a2-fff3-5b03-fa3fbca6e871@seacom.mu> <6f9281993a228fe41c3ad9453206d22a@nuclearcat.com> Message-ID: <67b5cebc-44ff-6d7a-da0a-c95c3d8c3ec0@seacom.mu> On 18/Jul/19 11:04, Denys Fedoryshchenko wrote: > Africa, Russia... > > You can take as example Lebanon. > Capital and major city in tiny country, ~40km away from each other, > and only way you can get 2 points connected over microwaves(due > mountains - several hops), over "licensed" providers, DSP, who hook > this points for $10-$30/mbps/month. And many of them don't have > support at evenings and weekend. Of course, due crappy electricity in > country and economical situation, discharged batteries and outages at > evening/night at "licensed" DSP sites - common case. > The laws of the country are so cool, that it is even forbidden to lay > optics from the building standing next to other building, unless you > are government monopoly (and they don't sell fiber connectivity). There is no shortage of countries around the world that stifle the development of their telecommunications industry because they don't understand how different the Internet is from POTS. Countries such as Djibouti land a tremendous amount of submarine cable systems, and yet it makes very little sense to the average operator to deploy meaningful network there. The Middle East, Asia, Europe and Latin America all have their own examples of the same. North America is no exception in some parts of those countries. You need to remember that Africa is not one country. Observing an assessment in one country has nothing to do with the the situation in the other 54. > > In Africa, many people do not have electricity at all and cook on open > fire, i imagine what difficulties they have with connectivity. Cooking with firewood is not a linear basis for the depth of connectivity in Africa. Traditional views don't always work, which is how Africa is the fastest growing mobile phone economy in the world. It shouldn't be, but it is. You'll need to open your mind to how differently folk get by this side of the world. > The last time when I worked with a team on study to invest in telecom > in Africa - results discouraged even trying to engage in telecom > subject there. I'm curious where this team was based... We have no shortage of "consultants" that desktop Africa from an office in New York. I can send you my consulting contract if you like. I live in Africa :-). > I think the only ones who are interested in decent connectivity there > - mobile operators. Maybe worth to find connections and talk to them. Perhaps it's time I went and got my mobile operator license :-). Mark. From jbothe at me.com Thu Jul 18 17:25:44 2019 From: jbothe at me.com (JASON BOTHE) Date: Thu, 18 Jul 2019 12:25:44 -0500 Subject: Fiber providers - Englewood / Centennial Colorado In-Reply-To: <1563909227.5799.1563458275226.JavaMail.mhammett@ThunderFuck> References: <1563909227.5799.1563458275226.JavaMail.mhammett@ThunderFuck> Message-ID: <9F588226-C35B-463F-91E4-453BC675361A@me.com> Thanks Mike I hit up crown and they have some segments, just not quite enough. I’ll try Windstream and see what I can find. Thanks J~ > On Jul 18, 2019, at 08:57, Mike Hammett wrote: > > Depending on what you're trying to do, you might find some bits and pieces from Windstream, Crown Castle, UPN, and XO. They're all in that Englewood - Centennial area in different ways with different capabilities. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > From: "JASON BOTHE via NANOG" > To: nanog at nanog.org > Sent: Wednesday, July 17, 2019 6:10:42 PM > Subject: Fiber providers - Englewood / Centennial Colorado > > Hi all > > Just curious if you know of any fiber providers other than CL or Zayo in the Englewood/Centennial area. Having a really tough time finding routes that avoid the Solarium at Quebec / E Orchard as well as 910 15th St. Seems there are so many single points of failure and collapsed routes that all lead to these two locations to get diverse long haul. > > Many thanks. > > J~ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joly at punkcast.com Thu Jul 18 17:46:48 2019 From: joly at punkcast.com (Joly MacFie) Date: Thu, 18 Jul 2019 13:46:48 -0400 Subject: Colo in Africa In-Reply-To: <67b5cebc-44ff-6d7a-da0a-c95c3d8c3ec0@seacom.mu> References: <65e530cd-72a2-fff3-5b03-fa3fbca6e871@seacom.mu> <6f9281993a228fe41c3ad9453206d22a@nuclearcat.com> <67b5cebc-44ff-6d7a-da0a-c95c3d8c3ec0@seacom.mu> Message-ID: You might want to consider attending AfPIF in Mauritius 20-22 Aug https://www.afpif.org/ -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- - -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj at pcguys.us Thu Jul 18 18:31:07 2019 From: tj at pcguys.us (TJ Trout) Date: Thu, 18 Jul 2019 11:31:07 -0700 Subject: Bgpmon alternatives? In-Reply-To: References: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> <20190616094827.GA34940@meow.BKantor.net> <6429449a-e076-b4db-62f0-1eb5fc43454f@he.net> <20190616112050.GA35876@meow.BKantor.net> <67F895A2-1F69-4442-AA0D-7BF415FBA893@as397444.net> Message-ID: I also cannot find a way to subscribe to your hijack notifications? On Wed, Jul 17, 2019, 10:45 PM Töma Gavrichenkov wrote: > On Thu, Jul 18, 2019 at 3:16 AM TJ Trout wrote: > > Anyone know of a hosted alternative to bgpmon? I'm testing > > Qrator but I can't determine if it will notify in real-time of a > > prefix hijack? > > Qrator guy there. > Real-time notifications are there but are only available on a > commercial basis, because basically real time is expensive to compute. > The rest is free. > > -- > Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DWayne.Saunders at team.telstra.com Thu Jul 18 00:44:55 2019 From: DWayne.Saunders at team.telstra.com (Saunders, D'Wayne) Date: Thu, 18 Jul 2019 00:44:55 +0000 Subject: Bgpmon alternatives? In-Reply-To: References: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> <20190616094827.GA34940@meow.BKantor.net> <6429449a-e076-b4db-62f0-1eb5fc43454f@he.net> <20190616112050.GA35876@meow.BKantor.net> <67F895A2-1F69-4442-AA0D-7BF415FBA893@as397444.net> Message-ID: We moved to Thousandeyes for this function D'Wayne Saunders From: NANOG on behalf of TJ Trout Date: Thursday, 18 July 2019 at 10:15 am To: Matt Corallo Cc: nanog Subject: Re: Bgpmon alternatives? [External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. Anyone know of a hosted alternative to bgpmon? I'm testing Qrator but I can't determine if it will notify in real-time of a prefix hijack? On Sun, Jun 16, 2019 at 9:23 AM Matt Corallo > wrote: There's also https://github.com/NLNOG/bgpalerter (which I believe they're trying to turn into a website frontend based on RIS, but I run it with patches for as_path regexes and it works pretty well). On Jun 16, 2019, at 07:40, Michael Hallgren > wrote: RIS Live API is a choice for this. mh Le 16 juin 2019, à 13:21, Brian Kantor > a écrit: That would be wonderful. Thank you! - Brian On Sun, Jun 16, 2019 at 03:59:29AM -0700, Mike Leber wrote: I'm sure if it doesn't do exactly that already, we can add it shortly. Some of planned functionality for hijack detection is already live. That's one of the main reasons for creating this service. Mike. On 6/16/19 2:48 AM, Brian Kantor wrote: On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote: As a beta service you can try out rt-bgp.he.net. This is a real time bgp monitoring service we are developing. It's interesting, but I don't see any way to do what I primarily use the existing BGPMon for: watch for hijacks. That is, set up one or more prefixes to be continuously monitored and have the monitor send me an email alert when that prefix or a subnet of it begins to be announced by someone new. For example, if I have told it to monitor 44.0.0.0/8 and someone somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very much like to know about that, along with details of who and where. Then if that announcement is authorized, I can tell the monitoring service that this new entry is NOT a hijack, and it won't bug me about it again. Can it be persuaded to do this? - Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccariffe at gmail.com Thu Jul 18 03:21:40 2019 From: ccariffe at gmail.com (Chris Cariffe) Date: Wed, 17 Jul 2019 23:21:40 -0400 Subject: netstat -s In-Reply-To: References: Message-ID: -rn and -an fan here! On Wed, Jul 17, 2019 at 8:56 PM Randy Bush wrote: > do folk use `netstat -s` to help diagnose on routers/switches? > > randy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vikash_sorout at yahoo.com Thu Jul 18 10:45:39 2019 From: vikash_sorout at yahoo.com (Vikash Sorout) Date: Thu, 18 Jul 2019 10:45:39 +0000 (UTC) Subject: Cisco wifi signal fluctuations References: <663319894.3094042.1563446739182.ref@mail.yahoo.com> Message-ID: <663319894.3094042.1563446739182@mail.yahoo.com> On Cisco wifi, we started seeing signal fluctuations since 1-2 months. The only change that was done to change windows user preference from 2.4 GHz Radio to 5 GHz radio through a windows group policy change. But this was done in response to the problem reported by certain users.We have lately discovered that some of the neighboring APs opt for same frequency band at 5.0 GHz and also at 2.4 GHz. Reboot of these APs have not helped to choose different frequency band by these APs.Channel assignment is set to be auto and we cannot change it to static though we are aware of definitive AP positions at all floors in campus. The reason being that the controller serves APAC and we do not know the definite / relative positions of different APs.The wireless survey conducted before (when there was no complaint on wifi) did show presence of co-channel interferences in certain areas, but SNR was seen to be very good in all areas of all the floors. For skype, we have call drop or call noisy complain from users across the three floors irrespective of if they are connected to wifi or LAN. We are using Cisco WLC 5520 controller. Regards,Vikash SoroutHand-phone : +91-9013866229Email: vikash_sorout at yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.gilmour at gmail.com Thu Jul 18 18:45:25 2019 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Thu, 18 Jul 2019 12:45:25 -0600 Subject: Twitter security team? Message-ID: Anyone on the list know how to contact the Twitter Security team? Seems the new update allows an attacker to modify other people's tweets. The "Hackerone" form for reporting a vulnerability is the wrong form and the "My account has been hacked" form is also the wrong form. The whole site has been compromised, I have evidence and can't contact anyone due to the lack of an appropriate form and the fact that the security@ email address doesn't work. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhellenthal at dataix.net Thu Jul 18 18:59:55 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Thu, 18 Jul 2019 13:59:55 -0500 Subject: Twitter security team? In-Reply-To: References: Message-ID: <6A408DA2-98CD-4C64-B787-9F0CF41CE475@dataix.net> Yes/No ? https://help.twitter.com/en/rules-and-policies/reporting-security-vulnerabilities > On Jul 18, 2019, at 13:45, Ken Gilmour wrote: > > Anyone on the list know how to contact the Twitter Security team? > > Seems the new update allows an attacker to modify other people's tweets. The "Hackerone" form for reporting a vulnerability is the wrong form and the "My account has been hacked" form is also the wrong form. The whole site has been compromised, I have evidence and can't contact anyone due to the lack of an appropriate form and the fact that the security@ email address doesn't work. > > Thanks! From jhellenthal at dataix.net Thu Jul 18 19:01:01 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Thu, 18 Jul 2019 14:01:01 -0500 Subject: Twitter security team? In-Reply-To: <6A408DA2-98CD-4C64-B787-9F0CF41CE475@dataix.net> References: <6A408DA2-98CD-4C64-B787-9F0CF41CE475@dataix.net> Message-ID: <533EF405-2D3B-485A-8DF2-327180D57B82@dataix.net> Or maybe a tweet to @twittersecurity > On Jul 18, 2019, at 13:59, J. Hellenthal wrote: > > > Yes/No ? > > https://help.twitter.com/en/rules-and-policies/reporting-security-vulnerabilities > >> On Jul 18, 2019, at 13:45, Ken Gilmour wrote: >> >> Anyone on the list know how to contact the Twitter Security team? >> >> Seems the new update allows an attacker to modify other people's tweets. The "Hackerone" form for reporting a vulnerability is the wrong form and the "My account has been hacked" form is also the wrong form. The whole site has been compromised, I have evidence and can't contact anyone due to the lack of an appropriate form and the fact that the security@ email address doesn't work. >> >> Thanks! > From ross at tajvar.io Thu Jul 18 19:05:51 2019 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 18 Jul 2019 15:05:51 -0400 Subject: Twitter security team? In-Reply-To: <533EF405-2D3B-485A-8DF2-327180D57B82@dataix.net> References: <6A408DA2-98CD-4C64-B787-9F0CF41CE475@dataix.net> <533EF405-2D3B-485A-8DF2-327180D57B82@dataix.net> Message-ID: Why is Hacker one wrong? Seems like this would be exactly what it's for. On Thu, Jul 18, 2019, 3:04 PM J. Hellenthal via NANOG wrote: > Or maybe a tweet to @twittersecurity > > > On Jul 18, 2019, at 13:59, J. Hellenthal wrote: > > > > > > Yes/No ? > > > > > https://help.twitter.com/en/rules-and-policies/reporting-security-vulnerabilities > > > >> On Jul 18, 2019, at 13:45, Ken Gilmour wrote: > >> > >> Anyone on the list know how to contact the Twitter Security team? > >> > >> Seems the new update allows an attacker to modify other people's > tweets. The "Hackerone" form for reporting a vulnerability is the wrong > form and the "My account has been hacked" form is also the wrong form. The > whole site has been compromised, I have evidence and can't contact anyone > due to the lack of an appropriate form and the fact that the security@ > email address doesn't work. > >> > >> Thanks! > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric-list at truenet.com Thu Jul 18 19:06:27 2019 From: eric-list at truenet.com (Eric Tykwinski) Date: Thu, 18 Jul 2019 15:06:27 -0400 Subject: Twitter security team? In-Reply-To: <533EF405-2D3B-485A-8DF2-327180D57B82@dataix.net> References: <6A408DA2-98CD-4C64-B787-9F0CF41CE475@dataix.net> <533EF405-2D3B-485A-8DF2-327180D57B82@dataix.net> Message-ID: <013b01d53d9b$e6ed8a50$b4c89ef0$@truenet.com> They also have a bug bounty program on HackerOne: https://hackerone.com/twitter > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of J. Hellenthal > via NANOG > Sent: Thursday, July 18, 2019 3:01 PM > To: Ken Gilmour > Cc: North Group > Subject: Re: Twitter security team? > > Or maybe a tweet to @twittersecurity > > > On Jul 18, 2019, at 13:59, J. Hellenthal wrote: > > > > > > Yes/No ? > > > > https://help.twitter.com/en/rules-and-policies/reporting-security- > vulnerabilities > > > >> On Jul 18, 2019, at 13:45, Ken Gilmour wrote: > >> > >> Anyone on the list know how to contact the Twitter Security team? > >> > >> Seems the new update allows an attacker to modify other people's tweets. > The "Hackerone" form for reporting a vulnerability is the wrong form and the > "My account has been hacked" form is also the wrong form. The whole site > has been compromised, I have evidence and can't contact anyone due to the > lack of an appropriate form and the fact that the security@ email address > doesn't work. > >> > >> Thanks! > > From ken.gilmour at gmail.com Thu Jul 18 19:06:48 2019 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Thu, 18 Jul 2019 13:06:48 -0600 Subject: Twitter security team? In-Reply-To: <6A408DA2-98CD-4C64-B787-9F0CF41CE475@dataix.net> References: <6A408DA2-98CD-4C64-B787-9F0CF41CE475@dataix.net> Message-ID: no On Thu, 18 Jul 2019 at 12:59, J. Hellenthal wrote: > > Yes/No ? > > > https://help.twitter.com/en/rules-and-policies/reporting-security-vulnerabilities > > > On Jul 18, 2019, at 13:45, Ken Gilmour wrote: > > > > Anyone on the list know how to contact the Twitter Security team? > > > > Seems the new update allows an attacker to modify other people's tweets. > The "Hackerone" form for reporting a vulnerability is the wrong form and > the "My account has been hacked" form is also the wrong form. The whole > site has been compromised, I have evidence and can't contact anyone due to > the lack of an appropriate form and the fact that the security@ email > address doesn't work. > > > > Thanks! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.gilmour at gmail.com Thu Jul 18 19:08:26 2019 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Thu, 18 Jul 2019 13:08:26 -0600 Subject: Twitter security team? In-Reply-To: References: <6A408DA2-98CD-4C64-B787-9F0CF41CE475@dataix.net> <533EF405-2D3B-485A-8DF2-327180D57B82@dataix.net> Message-ID: Because I didn't find the vulnerability, I'm not looking for a bug bounty and I don't know what the vulnerability is, just seeing the effects of it. On Thu, 18 Jul 2019 at 13:06, Ross Tajvar wrote: > Why is Hacker one wrong? Seems like this would be exactly what it's for. > > On Thu, Jul 18, 2019, 3:04 PM J. Hellenthal via NANOG > wrote: > >> Or maybe a tweet to @twittersecurity >> >> > On Jul 18, 2019, at 13:59, J. Hellenthal >> wrote: >> > >> > >> > Yes/No ? >> > >> > >> https://help.twitter.com/en/rules-and-policies/reporting-security-vulnerabilities >> > >> >> On Jul 18, 2019, at 13:45, Ken Gilmour wrote: >> >> >> >> Anyone on the list know how to contact the Twitter Security team? >> >> >> >> Seems the new update allows an attacker to modify other people's >> tweets. The "Hackerone" form for reporting a vulnerability is the wrong >> form and the "My account has been hacked" form is also the wrong form. The >> whole site has been compromised, I have evidence and can't contact anyone >> due to the lack of an appropriate form and the fact that the security@ >> email address doesn't work. >> >> >> >> Thanks! >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.buxey at gmail.com Thu Jul 18 20:01:06 2019 From: alan.buxey at gmail.com (Alan Buxey) Date: Thu, 18 Jul 2019 21:01:06 +0100 Subject: Cisco wifi signal fluctuations In-Reply-To: <663319894.3094042.1563446739182@mail.yahoo.com> References: <663319894.3094042.1563446739182.ref@mail.yahoo.com> <663319894.3094042.1563446739182@mail.yahoo.com> Message-ID: hi, do you have any of the WLC settings on such as dynamic power assignment (which allows the controller to work out neighbour cell coverage and reduce the signal to stop much overlap). which 5GHz channels are being used - if you're using those in DFS space then RADAR detection means that DAC will kick in and the APs will be changing channel (which of course, means they'll be doing some clear channel assessment before coming back. is the SSID still doing WPA? If so, any MAC check failures from a dodgy client will cause the AP to enact counter measures etc etc really, I'd suggest turning on much logging for this area/building , slap it all into a simple ELK setup (just spin one up from available docker compose files if needed) - and then browse the resulting dataset with Kibana etc to see whats going on. or go and do a proper wireless survey and fix it from base level up :) alan On Thu, 18 Jul 2019 at 19:46, Vikash Sorout via NANOG wrote: > > On Cisco wifi, we started seeing signal fluctuations since 1-2 months. The only change that was done to change windows user preference from 2.4 GHz Radio to 5 GHz radio through a windows group policy change. But this was done in response to the problem reported by certain users.We have lately discovered that some of the neighboring APs opt for same frequency band at 5.0 GHz and also at 2.4 GHz. Reboot of these APs have not helped to choose different frequency band by these APs.Channel assignment is set to be auto and we cannot change it to static though we are aware of definitive AP positions at all floors in campus. The reason being that the controller serves APAC and we do not know the definite / relative positions of different APs.The wireless survey conducted before (when there was no complaint on wifi) did show presence of co-channel interferences in certain areas, but SNR was seen to be very good in all areas of all the floors. > > For skype, we have call drop or call noisy complain from users across the three floors irrespective of if they are connected to wifi or LAN. > > We are using Cisco WLC 5520 controller. > > > > Regards, > Vikash Sorout > Hand-phone : +91-9013866229 > Email: vikash_sorout at yahoo.com From gregori.parker at gmail.com Thu Jul 18 19:08:08 2019 From: gregori.parker at gmail.com (Gregori Parker) Date: Thu, 18 Jul 2019 14:08:08 -0500 Subject: Twitter security team? In-Reply-To: <533EF405-2D3B-485A-8DF2-327180D57B82@dataix.net> References: <6A408DA2-98CD-4C64-B787-9F0CF41CE475@dataix.net> <533EF405-2D3B-485A-8DF2-327180D57B82@dataix.net> Message-ID: https://hackerone.com/twitter is the correct means to report -G On Thu, Jul 18, 2019 at 2:04 PM J. Hellenthal via NANOG wrote: > Or maybe a tweet to @twittersecurity > > > On Jul 18, 2019, at 13:59, J. Hellenthal wrote: > > > > > > Yes/No ? > > > > > https://help.twitter.com/en/rules-and-policies/reporting-security-vulnerabilities > > > >> On Jul 18, 2019, at 13:45, Ken Gilmour wrote: > >> > >> Anyone on the list know how to contact the Twitter Security team? > >> > >> Seems the new update allows an attacker to modify other people's > tweets. The "Hackerone" form for reporting a vulnerability is the wrong > form and the "My account has been hacked" form is also the wrong form. The > whole site has been compromised, I have evidence and can't contact anyone > due to the lack of an appropriate form and the fact that the security@ > email address doesn't work. > >> > >> Thanks! > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu Jul 18 21:34:07 2019 From: bill at herrin.us (William Herrin) Date: Thu, 18 Jul 2019 14:34:07 -0700 Subject: netstat -s In-Reply-To: References: Message-ID: On Thu, Jul 18, 2019 at 11:43 AM Chris Cariffe wrote: > [netstat] -rn and -an fan here! > Rarely use them. "ip route show" and "lsof +c 15 -nP | grep TCP" are normally more useful. -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mianosm at gmail.com Thu Jul 18 21:45:39 2019 From: mianosm at gmail.com (Steven M. Miano) Date: Thu, 18 Jul 2019 17:45:39 -0400 Subject: netstat -s In-Reply-To: References: Message-ID: <3690303c-56ed-676f-0953-966034c2e5f0@gmail.com> Ideally folks should be subshells (unless you're on a strange system or legacy system). netstat is now mostly obsolete.  Replacement for netstat is ss.   Replacement for  netstat -r is ip route. Replacement for netstat -i is ip -s link. Replacement for netstat -g is ip maddr. https://www.linux.com/learn/intro-to-linux/2017/7/introduction-ss-command r/s, Steven M. Miano (727)244-9990 http://stevenmiano.com 1811 C2CB 8219 4F52 On 7/17/19 20:54, Randy Bush wrote: > do folk use `netstat -s` to help diagnose on routers/switches? > > randy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Thu Jul 18 21:52:50 2019 From: randy at psg.com (Randy Bush) Date: Thu, 18 Jul 2019 14:52:50 -0700 Subject: netstat -s In-Reply-To: <3690303c-56ed-676f-0953-966034c2e5f0@gmail.com> References: <3690303c-56ed-676f-0953-966034c2e5f0@gmail.com> Message-ID: > Ideally folks should be subshells (unless you're on a strange system or > legacy system). > > netstat is now mostly obsolete.  > Replacement for netstat is ss.   > Replacement for  netstat -r is ip route. > Replacement for netstat -i is ip -s link. > Replacement for netstat -g is ip maddr. on some vendors. but could you answer my question? do you use it? From ross at tajvar.io Thu Jul 18 21:56:09 2019 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 18 Jul 2019 17:56:09 -0400 Subject: netstat -s In-Reply-To: References: <3690303c-56ed-676f-0953-966034c2e5f0@gmail.com> Message-ID: Why do you want to know? On Thu, Jul 18, 2019, 5:55 PM Randy Bush wrote: > > Ideally folks should be subshells (unless you're on a strange system or > > legacy system). > > > > netstat is now mostly obsolete. > > Replacement for netstat is ss. > > Replacement for netstat -r is ip route. > > Replacement for netstat -i is ip -s link. > > Replacement for netstat -g is ip maddr. > > on some vendors. but could you answer my question? do you use it? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Jul 18 21:57:19 2019 From: randy at psg.com (Randy Bush) Date: Thu, 18 Jul 2019 14:57:19 -0700 Subject: netstat -s In-Reply-To: References: <3690303c-56ed-676f-0953-966034c2e5f0@gmail.com> Message-ID: > Why do you want to know? why do you want to know why i want to know? :) From rsk at gsp.org Thu Jul 18 21:59:45 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 18 Jul 2019 17:59:45 -0400 Subject: Twitter security team? In-Reply-To: References: Message-ID: <20190718215945.GA2857@gsp.org> On Thu, Jul 18, 2019 at 12:45:25PM -0600, Ken Gilmour wrote: > I have evidence and can't contact anyone due to > the lack of an appropriate form and the fact that the security@ email > address doesn't work. Of course I'm not surprised that the ignorant newbies running Twitter can't manage this: who wouldn't be, given their atrocious track record? But for everyone else: [ engage soapbox ] RFC 2142 was published in 1997, and most of the role addresses it specifies were in relatively common use prior to that. Yet -- nearly every day -- this list carries traffic from someone attempting to help/warn/etc. some allegedly professional operation that has its fingers firmly lodged in its ears in a desperate attempt to prevent basic communication and expects people who are already trying to provide them with free consulting services to jump through various annoying hoops in order to do so. RTFRFC, folks, and implement it. It's operations 101. It's something you should have done in the first hour of the first day, before you turned on the rest of your stuff. It's not hard. And when a day like this comes for your operation, which it will, it may save you considerable pain, time, and/or money. [ soapbox off - for now ;) ] ---rsk From ross at tajvar.io Thu Jul 18 22:00:34 2019 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 18 Jul 2019 18:00:34 -0400 Subject: netstat -s In-Reply-To: References: <3690303c-56ed-676f-0953-966034c2e5f0@gmail.com> Message-ID: > but could you answer my question? Just seemed like there was some urgency so I was curious. On Thu, Jul 18, 2019, 5:57 PM Randy Bush wrote: > > Why do you want to know? > > why do you want to know why i want to know? :) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at the-watsons.org Thu Jul 18 22:02:12 2019 From: brett at the-watsons.org (Brett Watson) Date: Thu, 18 Jul 2019 16:02:12 -0600 Subject: netstat -s In-Reply-To: References: Message-ID: <5324DC57-C5A9-4E17-A6A4-25095E85AB5F@the-watsons.org> > On Jul 17, 2019, at 6:54 PM, Randy Bush wrote: > > do folk use `netstat -s` to help diagnose on routers/switches? > indeed. From jra at baylink.com Thu Jul 18 22:07:17 2019 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 18 Jul 2019 22:07:17 +0000 (UTC) Subject: Spam In-Reply-To: <1986194041.765231.1563223314578.JavaMail.zimbra@baylink.com> References: <1986194041.765231.1563223314578.JavaMail.zimbra@baylink.com> Message-ID: <941802054.800903.1563487637789.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "jra" > Someone tell Trevor Walford at ECG in Valdosta that scraping the list for > addresses to spam is a suboptimal approach? I have to apologize to Mr Walford. A search through my old mail archive shows mail from his organization from a year and two years ago, also times when I was not especially active on NANOG. I retract the accusation, and regret the error. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From james.cutler at consultant.com Thu Jul 18 22:10:00 2019 From: james.cutler at consultant.com (James R Cutler) Date: Thu, 18 Jul 2019 18:10:00 -0400 Subject: netstat -s, but off topic a bit In-Reply-To: References: <3690303c-56ed-676f-0953-966034c2e5f0@gmail.com> Message-ID: <2F8A28FC-6860-4CEB-B8C1-03C5F82938B8@consultant.com> > Ideally folks should be subshells (unless you're on a strange system or > legacy system). > I have never thought of myself as subshell, even on a low carbohydrate system > netstat is now mostly obsolete. > Replacement for netstat is ss. > Replacement for netstat -r is ip route. > Replacement for netstat -i is ip -s link. > Replacement for netstat -g is ip maddr. Microsoft (Windows, that is) and Apple macOS have no knowledge of ss. That is why I use netstat often, but never netstat -s to diagnose routing. (Hi, Randy.) James R. Cutler James.cutler at consultant.com GPG keys: hkps://hkps.pool.sks-keyservers.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jra at baylink.com Thu Jul 18 22:15:11 2019 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 18 Jul 2019 22:15:11 +0000 (UTC) Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <64102dbd-08e6-ddb6-6e97-577f92ec2357@mtcc.com> References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> <1394695366.764492.1563217632200.JavaMail.zimbra@baylink.com> <64102dbd-08e6-ddb6-6e97-577f92ec2357@mtcc.com> Message-ID: <33743927.800957.1563488111119.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Michael Thomas" > On 7/15/19 12:07 PM, Jay R. Ashworth wrote: >> Yes, of course we sent out calls with "spoofed" CNID. >> >> But, even though only 2 or 3 or our 5 carriers* held *our* feet to the fire, >> we held the clients' feet to the fire, requiring them to prove to our >> satisfaction that they had adminstrative control over the numbers in question. >> >> But it's the carrier's responsibility, properly, to do that work. > > How do the clients prove that? Do you know, I don't know; it was above my paygrade; the few times I stubbed a toe on it, I threw it over a wall. I presume that there was paperwork... > Way back when when we were working on mipv6 we had to work through a > somewhat similar problem for handoffs. The ultimate answer was a return > routability test: that is, if you can answer on the address you're > trying to claim "ownership" for, it's good enough. Might have been a handshake like that; I suspect it was mostly just "here's a picture of the client's phone bill". > But right you are, it's ultimately the carrier who needs to care about > this problem at or nothing gets better. Yup. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From nanog-post at rsuc.gweep.net Thu Jul 18 22:26:09 2019 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 18 Jul 2019 18:26:09 -0400 Subject: netstat -s In-Reply-To: References: Message-ID: <20190718222609.GA41803@gweep.net> On Wed, Jul 17, 2019 at 05:54:49PM -0700, Randy Bush wrote: > do folk use `netstat -s` to help diagnose on routers/switches? Sometimes - it depends on the problems and visibility/lack thereof provided by other methods. In the netstat family of flags, what I *really* miss is DEC's 'netstat -z', especially when having "application vs network" arguments for poorly instrucmented applications. Cheers, Joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From mike at mtcc.com Thu Jul 18 22:33:10 2019 From: mike at mtcc.com (Michael Thomas) Date: Thu, 18 Jul 2019 15:33:10 -0700 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <33743927.800957.1563488111119.JavaMail.zimbra@baylink.com> References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> <1394695366.764492.1563217632200.JavaMail.zimbra@baylink.com> <64102dbd-08e6-ddb6-6e97-577f92ec2357@mtcc.com> <33743927.800957.1563488111119.JavaMail.zimbra@baylink.com> Message-ID: On 7/18/19 3:15 PM, Jay R. Ashworth wrote: > ----- Original Message ----- >> From: "Michael Thomas" >> On 7/15/19 12:07 PM, Jay R. Ashworth wrote: >>> Yes, of course we sent out calls with "spoofed" CNID. >>> >>> But, even though only 2 or 3 or our 5 carriers* held *our* feet to the fire, >>> we held the clients' feet to the fire, requiring them to prove to our >>> satisfaction that they had adminstrative control over the numbers in question. >>> >>> But it's the carrier's responsibility, properly, to do that work. >> How do the clients prove that? > Do you know, I don't know; it was above my paygrade; the few times I stubbed > a toe on it, I threw it over a wall. > > I presume that there was paperwork... > > I still think this would be much easier to solve in the Internet domain instead of in the PSTN domain. That is, use SIP From: address instead of telephone numbers. We already have the ability to give with reasonable certainty that a message has been originated by a given domain. If we present that address in preference to caller ID, and I can filter based on that it puts a lot of positive pressure on legit callers to identify themselves (they already do it for their email), and negative pressure on the callerid holdouts. They'd have to use their own domain name and prove their control of it, and that's a good thing. You'd think this would be easier for the carriers too since they wouldn't have to vet shady clients... it's their domain they're trashing, not the carriers. I for one would be perfectly happy with a UA that went straight to a quarantine if it only had callerid in it. Mike From msa at latt.net Fri Jul 19 02:57:58 2019 From: msa at latt.net (Majdi S. Abbas) Date: Thu, 18 Jul 2019 22:57:58 -0400 Subject: 44/8 Message-ID: <20190719025758.GB29374@puck.nether.net> Apparently isn't 44/8 anymore: NetRange: 44.192.0.0 - 44.255.255.255 CIDR: 44.192.0.0/10 NetName: AT-88-Z NetHandle: NET-44-192-0-0-1 Parent: NET44 (NET-44-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Amazon Technologies Inc. (AT-88-Z) RegDate: 2019-07-18 Updated: 2019-07-18 Ref: https://rdap.arin.net/registry/ip/44.192.0.0 Some additional color is available at: https://www.ampr.org/amprnet/ What's interesting about this is it was not an ARIN allocation, and the ARDC folks are not the original registrant. This IANA /8 was initially delegated to a community, not an organization. So, to the individuals listed in the blog, that I've excerpted below, what do you have to say about this? Brian Kantor kc claffy Phil Karn Paul Vixie [I've omitted those I don't know to be NANOG familiar.] ARIN also appears to have a role here. Any comment, ARIN folks? --msa P.S. I've been licensed as a ham since prior to the organization of ARDC in 1992 -- where's my check? From morrowc.lists at gmail.com Fri Jul 19 03:02:40 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 18 Jul 2019 23:02:40 -0400 Subject: 44/8 In-Reply-To: <20190719025758.GB29374@puck.nether.net> References: <20190719025758.GB29374@puck.nether.net> Message-ID: On Thu, Jul 18, 2019 at 10:59 PM Majdi S. Abbas wrote: > > > What's interesting about this is it was not an ARIN allocation, So.. this is/was a legacy allocation, right? with some 'not great' contact/etc info... the ARIN folk could have said: "Well.... sure! if the current folk who control access can positively show they do AND they don't mind parting with a /10... ok?" This ends up with a /10 of a /8 with better registration information and MAYBE better records keeping over time, right? that seems like a win to the ARIN community? From aveline at misaka.io Fri Jul 19 03:07:38 2019 From: aveline at misaka.io (Siyuan Miao) Date: Fri, 19 Jul 2019 11:07:38 +0800 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> Message-ID: Did a fast lookup via ARIN WHOIS: 44/8 is now 44/9 + 44.128/10 NetRange: 44.0.0.0 - 44.191.255.255 CIDR: 44.0.0.0/9, 44.128.0.0/10 NetName: AMPRNET NetHandle: NET-44-0-0-0-1 Parent: NET44 (NET-44-0-0-0-0) NetType: Direct Assignment OriginAS: Organization: Amateur Radio Digital Communications (ARDC) RegDate: 1992-07-01 Updated: 2019-07-18 Ref: https://rdap.arin.net/registry/ip/44.0.0.0 On Fri, Jul 19, 2019 at 11:04 AM Christopher Morrow wrote: > On Thu, Jul 18, 2019 at 10:59 PM Majdi S. Abbas wrote: > > > > > > What's interesting about this is it was not an ARIN allocation, > > So.. this is/was a legacy allocation, right? with some 'not great' > contact/etc info... > the ARIN folk could have said: "Well.... sure! if the current folk who > control access can positively show they do AND they don't mind parting > with a /10... ok?" > > This ends up with a /10 of a /8 with better registration information > and MAYBE better records keeping over time, right? > that seems like a win to the ARIN community? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at instituut.net Fri Jul 19 03:08:55 2019 From: job at instituut.net (Job Snijders) Date: Thu, 18 Jul 2019 23:08:55 -0400 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> Message-ID: A potential upside is that hamnet operators maybe have access to some RPKI services now! -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at xtom.com Fri Jul 19 03:10:23 2019 From: david at xtom.com (David Guo) Date: Fri, 19 Jul 2019 03:10:23 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> , Message-ID: finally they start selling it. Get Outlook for iOS ________________________________ From: NANOG on behalf of Siyuan Miao Sent: Friday, July 19, 2019 11:07:38 AM To: Christopher Morrow Cc: nanog list Subject: Re: 44/8 Did a fast lookup via ARIN WHOIS: 44/8 is now 44/9 + 44.128/10 NetRange: 44.0.0.0 - 44.191.255.255 CIDR: 44.0.0.0/9, 44.128.0.0/10 NetName: AMPRNET NetHandle: NET-44-0-0-0-1 Parent: NET44 (NET-44-0-0-0-0) NetType: Direct Assignment OriginAS: Organization: Amateur Radio Digital Communications (ARDC) RegDate: 1992-07-01 Updated: 2019-07-18 Ref: https://rdap.arin.net/registry/ip/44.0.0.0 On Fri, Jul 19, 2019 at 11:04 AM Christopher Morrow > wrote: On Thu, Jul 18, 2019 at 10:59 PM Majdi S. Abbas > wrote: > > > What's interesting about this is it was not an ARIN allocation, So.. this is/was a legacy allocation, right? with some 'not great' contact/etc info... the ARIN folk could have said: "Well.... sure! if the current folk who control access can positively show they do AND they don't mind parting with a /10... ok?" This ends up with a /10 of a /8 with better registration information and MAYBE better records keeping over time, right? that seems like a win to the ARIN community? -------------- next part -------------- An HTML attachment was scrubbed... URL: From msa at latt.net Fri Jul 19 03:13:24 2019 From: msa at latt.net (Majdi S. Abbas) Date: Thu, 18 Jul 2019 23:13:24 -0400 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> Message-ID: <20190719031324.GA11512@puck.nether.net> On Thu, Jul 18, 2019 at 11:02:40PM -0400, Christopher Morrow wrote: > So.. this is/was a legacy allocation, right? with some 'not great' > contact/etc info... It's been announced by UCSD as a /8, consistently available, with tunnel services and rDNS available on a consistent basis, for a long time. The folks involved are not hard to find and never have been. Amusingly, they still seem to be advertising the covering aggregate, so I guess the Cal system is going to provide transit to Amazon? Do the Regents know about this arrangement? > the ARIN folk could have said: "Well.... sure! if the current folk who > control access can positively show they do AND they don't mind parting > with a /10... ok?" ... I'm not sure this would make the 44/8 allocation anything but a bogon, or ARIN WHOIS & RPKI a reliable resource for the community. Potentially quite the contrary. If I start advertising space, and can show I thusly "control" it, can I monetize it, too? I could use "some millions." --msa From Bryan at bryanfields.net Fri Jul 19 03:15:42 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 18 Jul 2019 23:15:42 -0400 Subject: 44/8 In-Reply-To: <20190719025758.GB29374@puck.nether.net> References: <20190719025758.GB29374@puck.nether.net> Message-ID: <084c1c99-a290-507d-71d4-9caf49e3a415@bryanfields.net> On 7/18/19 10:57 PM, Majdi S. Abbas wrote: > > What's interesting about this is it was not an ARIN allocation, > and the ARDC folks are not the original registrant. This IANA /8 was > initially delegated to a community, not an organization. > > So, to the individuals listed in the blog, that I've excerpted > below, what do you have to say about this? > > Brian Kantor > kc claffy > Phil Karn > Paul Vixie This is par for the course with ARDC. I was a TAC committee member (I resigned in disgust just 15 min ago), and the board has failed to inform anyone this was happening. I discussed this prior as we could lease it, do something with it, make some money from it, and was 100% shot down. This has always been Brian Kantor's private little thing ever since he took over administration of it. This take over was before ARDC existed, and ARDC was never structured to be a proper community focused organization. I'd addressed this at TAPR meetings and NANOG with Brian and KC before. This also over looked the huge conflict of interest in KC being a board member of ARDC and Network Telescope getting a feed of 44/8 direct at no cost. This 44/8 announcement and UCSD routing broke connectivity to directly connected BGP subnets for years. My concern as an ARDC supporter an member is now no planning in the community for this, many people assume 44/8 is going to be licensed amateurs (I have many firewalls with permit 44/8 in them), and no accountability of what ARDC is doing. I believe with Brian retiring from UCSD he's looking for a job and being a board member of a well funded 501(c)3 can be a lucrative job. Also it's 100% broken reverse DNS for all of 44/8. :golf clap: This was theft from the community it was meant to serve. -- Bryan Fields, W9CR Former ARDC TAC member 727-409-1194 - Voice http://bryanfields.net From morrowc.lists at gmail.com Fri Jul 19 03:21:58 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 18 Jul 2019 23:21:58 -0400 Subject: 44/8 In-Reply-To: <20190719031324.GA11512@puck.nether.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> Message-ID: On Thu, Jul 18, 2019 at 11:13 PM Majdi S. Abbas wrote: > > On Thu, Jul 18, 2019 at 11:02:40PM -0400, Christopher Morrow wrote: > > So.. this is/was a legacy allocation, right? with some 'not great' > > contact/etc info... > > It's been announced by UCSD as a /8, consistently available, > with tunnel services and rDNS available on a consistent basis, for a > long time. > > The folks involved are not hard to find and never have been. > > Amusingly, they still seem to be advertising the covering > aggregate, so I guess the Cal system is going to provide transit to > Amazon? Do the Regents know about this arrangement? who knows? probably? not really my personal concern I guess. > > the ARIN folk could have said: "Well.... sure! if the current folk who > > control access can positively show they do AND they don't mind parting > > with a /10... ok?" > > ... I'm not sure this would make the 44/8 allocation anything > but a bogon, or ARIN WHOIS & RPKI a reliable resource for the community. > Potentially quite the contrary. > I'm not sure how you're quite going in this direction... > If I start advertising space, and can show I thusly "control" > it, can I monetize it, too? I could use "some millions." > My guess is that arin needed more than just: "can control routing for a few bits of time". I don't really know, but I hope they had more requirements than that :) I suppose though, are you more upset that the radio folk now have some endowment (or what-have-you) or that the block is getting somewhat chopped up? their blog seems to indicate that there is plenty of space left, more than they'd allocated previously (though I don't see any actioal records). They also state that the trust which was setup previously controled the space and dealt with ARIN + the buyer. it SEEMS above board... more above board than some other transactions I've seen in the last while :( Does it serve the larger community to get the space under RSA and potentially signed in the RPKI? or to leave it where it was before? -chris > --msa From job at instituut.net Fri Jul 19 03:23:33 2019 From: job at instituut.net (Job Snijders) Date: Fri, 19 Jul 2019 03:23:33 +0000 Subject: 44/8 In-Reply-To: <20190719031651.GA29056@mid.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031651.GA29056@mid.net> Message-ID: On Fri, Jul 19, 2019 at 3:16 AM Adam Korab wrote: > > On 07/18/2019 at 23:08, Job Snijders wrote: > > A potential upside is that hamnet operators maybe have access to some RPKI > > services now! > > OK, I'll bite....how do you mean? Ah, let me clarify, I didn't mean this as a tongue-in-cheek remark. Previously no RIR "managed" the space in the conventional sense of the word. In the case of 44.0.0.0/8, the consequences seemed to be that none of the RIRs were in a position to provide RPKI services (ROAs) for 44.0.0.0/8 or any more specific block within that /8. I saw that the IANA registry was updated https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml it now shows "Administered by ARIN". My interpretation is that now a pathway exists towards ARIN facilitating the creation of RPKI ROAs which cover (parts of) 44.0.0.0/8. In order to get RPKI services in context of ARIN, it appears a RSA or LRSA needs to exist. I suspect a LRSA-style agreement was instantiated, opening the door for RPKI services. Kind regards, Job From msa at latt.net Fri Jul 19 03:40:12 2019 From: msa at latt.net (Majdi S. Abbas) Date: Thu, 18 Jul 2019 23:40:12 -0400 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> Message-ID: <20190719034012.GB11512@puck.nether.net> On Thu, Jul 18, 2019 at 11:21:58PM -0400, Christopher Morrow wrote: > who knows? probably? not really my personal concern I guess. If they're using taxpayer supported networks to provide transit to a private, for profit entity, we should all care. > I'm not sure how you're quite going in this direction... In order to sell something, you must own it...if you pop up, claim responsibility for it, sit on it a while, and then sell it.. did you truly own it? If you represent a community, in theory, and sell something without prior discussion, are there ethical concerns around that? There are some potential legal title questions around this, and if ARIN is facilitating transactions with questionable history, that is something the Internet community might be concerned about. Certainly, facilitating questionable transfers makes the idea of an RIR sponsored registry that controls routing less palatable to some individuals. And this is why I'd love some additional color from the participants. Perhaps this is all explicable -- but that blog entry did not assuage my concerns. --msa From ww at styx.org Fri Jul 19 03:44:44 2019 From: ww at styx.org (William Waites) Date: Thu, 18 Jul 2019 23:44:44 -0400 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> Message-ID: <20190719034444.ober67lvyr4vvpw6@welcome.groovy.net> On 07/18, Christopher Morrow wrote: > My guess is that arin needed more than just: "can control routing for > a few bits of time". > I don't really know, but I hope they had more requirements than that :) It certainly doesn't look like it... My understanding is that 44/8 was, very much like different pieces of the radio spectrum, collective common property of amateur radio operators. That an organisation was needed to operate a registry because of the nature of IP address allocation does not amount to ownership or the right to sell anything. This is exactly analogous to the fact that the ARRL (or RAC, or RSGB etc) does not own and cannot sell radio spectrum allocated for amateur use. This is not a legitimate sale. ARIN should reverse the changes in its record, and the ARDC should give the "several million dollars" back to Amazon. Then we can decide, openly and transparently, if, for example, some piece of 44/8 should be returned to IANA for allocation to the RIRs. Greetings, William Waites VE3HW From morrowc.lists at gmail.com Fri Jul 19 03:47:21 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 18 Jul 2019 23:47:21 -0400 Subject: 44/8 In-Reply-To: <20190719034012.GB11512@puck.nether.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: On Thu, Jul 18, 2019 at 11:40 PM Majdi S. Abbas wrote: > > On Thu, Jul 18, 2019 at 11:21:58PM -0400, Christopher Morrow wrote: > > who knows? probably? not really my personal concern I guess. > > If they're using taxpayer supported networks to provide transit > to a private, for profit entity, we should all care. presumably 44/8 is shorter than the prefix AMZN is going to announce, right? (the /10) so... either UC wll eat backscatter when/if AMZN dorks u ptheir announcement/routing-config OR this isn't an issue. Right? Also, who's this 'we'.. I don't live in california... I presume UC is getting funding from california, not virginia. (mostly) It seems though that 44/8 was being used in some research project at UC so... maybe this is just that still at play. less nefarious and more 'meh, why change if we don't have to?' > > > I'm not sure how you're quite going in this direction... > > In order to sell something, you must own it...if you pop up, > claim responsibility for it, sit on it a while, and then sell it.. > did you truly own it? > didn't the ardc thing come into existence ~10 yrs back? though what looks like legit paths... > If you represent a community, in theory, and sell something > without prior discussion, are there ethical concerns around that? it sounded like there were discussions though (based on what Mr Fields said earlier Perhaps those weren't as upfront as some folk want? or perhaps they were constrained by the legal process surrounding the sale event (and negotiations leading up to that) > There are some potential legal title questions around this, > and if ARIN is facilitating transactions with questionable history, > that is something the Internet community might be concerned about. > sure. > Certainly, facilitating questionable transfers makes the idea > of an RIR sponsored registry that controls routing less palatable to > some individuals. > > And this is why I'd love some additional color from the > participants. Perhaps this is all explicable -- but that blog entry > did not assuage my concerns. > perhaps they will pipe up now :) -chris > --msa From nanog at as397444.net Fri Jul 19 03:48:45 2019 From: nanog at as397444.net (Matt Corallo) Date: Thu, 18 Jul 2019 23:48:45 -0400 Subject: 44/8 In-Reply-To: <20190719034444.ober67lvyr4vvpw6@welcome.groovy.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034444.ober67lvyr4vvpw6@welcome.groovy.net> Message-ID: <1383C4CB-1A1B-4B79-9EFE-17C8F58E17CF@as397444.net> I presume they'd be more than happy to if some HAM's were to file a lawsuit against ARIN (not entirely an un-serious suggestion), but, short that, what do they care if they cooperated in stealing some otherwise-unused IPs and giving them to Amazon? Matt > On Jul 18, 2019, at 23:44, William Waites wrote: > >> On 07/18, Christopher Morrow wrote: >> >> My guess is that arin needed more than just: "can control routing for >> a few bits of time". >> I don't really know, but I hope they had more requirements than that :) > > It certainly doesn't look like it... > > My understanding is that 44/8 was, very much like different pieces of the radio > spectrum, collective common property of amateur radio operators. That an > organisation was needed to operate a registry because of the nature of IP > address allocation does not amount to ownership or the right to sell anything. > This is exactly analogous to the fact that the ARRL (or RAC, or RSGB etc) does > not own and cannot sell radio spectrum allocated for amateur use. > > This is not a legitimate sale. ARIN should reverse the changes in its record, > and the ARDC should give the "several million dollars" back to Amazon. > > Then we can decide, openly and transparently, if, for example, some piece of > 44/8 should be returned to IANA for allocation to the RIRs. > > Greetings, > William Waites VE3HW From msa at latt.net Fri Jul 19 03:50:15 2019 From: msa at latt.net (Majdi S. Abbas) Date: Thu, 18 Jul 2019 23:50:15 -0400 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: <20190719035015.GC11512@puck.nether.net> On Thu, Jul 18, 2019 at 11:47:21PM -0400, Christopher Morrow wrote: > Also, who's this 'we'.. I don't live in california... I presume UC is > getting funding from california, not virginia. (mostly) > It seems though that 44/8 was being used in some research project at > UC so... maybe this is just that still at play. > less nefarious and more 'meh, why change if we don't have to?' [Off-NANOG] Chris, Remember that state college systems receive federal education funding; some of your dollars are in this pot, too. --msa From morrowc.lists at gmail.com Fri Jul 19 03:56:55 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 18 Jul 2019 23:56:55 -0400 Subject: 44/8 In-Reply-To: <20190719035015.GC11512@puck.nether.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> <20190719035015.GC11512@puck.nether.net> Message-ID: On Thu, Jul 18, 2019 at 11:50 PM Majdi S. Abbas wrote: > > On Thu, Jul 18, 2019 at 11:47:21PM -0400, Christopher Morrow wrote: > > Also, who's this 'we'.. I don't live in california... I presume UC is > > getting funding from california, not virginia. (mostly) > > It seems though that 44/8 was being used in some research project at > > UC so... maybe this is just that still at play. > > less nefarious and more 'meh, why change if we don't have to?' > > [Off-NANOG] > > Chris, > > Remember that state college systems receive federal education > funding; some of your dollars are in this pot, too. Sure,but... that space has been an internet telescope supporting numerous research folk for a decade + (probably closer to 2 decades). the amazon prefix is longer by a bit so won't really use the /8 even if ucsd keeps the /8 up. a bunch of this just sounds like grousing, which I guess is great... but none of this is particularly un-predictable. I find a bunch of the other sales far more sketchy :( I also find this prefix hilarious: 149.1.0.0/16 (not a sale, but surely available if you track down the owner .. who owns a winery) anyway, it'll be fun watching what happens with 44/8 I suppose. From Bryan at bryanfields.net Fri Jul 19 04:26:55 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Fri, 19 Jul 2019 00:26:55 -0400 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> <20190719035015.GC11512@puck.nether.net> Message-ID: <9dcbadc5-b8ba-137b-aef4-a6199c2e2fb8@bryanfields.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 7/18/19 11:56 PM, Christopher Morrow wrote: > Sure,but... that space has been an internet telescope supporting > numerous research folk for a decade + (probably closer to 2 decades). > the amazon prefix is longer by a bit so won't really use the /8 even > if ucsd keeps the /8 up. And one of the principal people in the network telescope project was KC, who also weaseled herself onto the ARDC board without even holding an amateur radio license. Conflict of interest here, holy carp. Caida has been using an amateur radio resource as far back as 2001, when we couldn't even be blessed to get 44net space for our own legitimate radio use. I'm sure I have the message from Brian denying it in my archives. - -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAl0xRoQACgkQYTmgYVLG kUBDmA//XOUz4PtyFktPm0Yi2jyA56y1QGLdZrgc+dfk8mPImjE3ipaJ+GgUEwEY a10TccbNuC9hWZv1n1F/pD/Kcn+An9uhHOOrIIb9DfST0eUq/qhlK00tbq/1WJtI SKOvJNhdE7815ucl4096e5fEOv7HQg9SxRpstLN/zZffFBL0R3fPtKEWbrgxA6lN Ldj3DnCie7tMG0ZXSTUkHBoumE7NlAcEolQhdu1SrnCbePtbEk/oSy0krT6xIoz5 BoXKarFAh/Ti1LMTUnDt2g1XEKrTtUI40egSzAlBXGvLzkDqW5539ZY+X5HElZzM Kqo84qmupX04xW1QFyA0EtKIwc1RD0PtnN6xhqOQ04llXYp6q82MKlNfgrvC+A2+ W2fq6EOZXAmRobNnfWt6g2k6I9Tc7fRc2xdMZNd8SU8BML/F3wfPPAnifaYqem2Z eoFtVhNr+yaAKUo7OumkfXI40Ab1AfP+r/iGiRg/S3oejhcVMyrZpd6mKAZ6OdiD lbi+lV4K2T0yKntRifqE/R1ASi7RjF379g63IOq1e2CpLbkRljNKx9gi/iU95PP2 C4qxcmX2SRPPDoGiz7Wom9UtWO9NxSFWISVqNL3jdOkCi3388TpRiI4mKLopLgzz wS9FozypHtRFOBZM0D7+1yckxhsf1Q4lZ0WNIVGNlCl6PaU7CnU= =1JCu -----END PGP SIGNATURE----- From morrowc.lists at gmail.com Fri Jul 19 04:31:18 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 19 Jul 2019 00:31:18 -0400 Subject: 44/8 In-Reply-To: <9dcbadc5-b8ba-137b-aef4-a6199c2e2fb8@bryanfields.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> <20190719035015.GC11512@puck.nether.net> <9dcbadc5-b8ba-137b-aef4-a6199c2e2fb8@bryanfields.net> Message-ID: On Fri, Jul 19, 2019 at 12:28 AM Bryan Fields wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > On 7/18/19 11:56 PM, Christopher Morrow wrote: > > Sure,but... that space has been an internet telescope supporting > > numerous research folk for a decade + (probably closer to 2 decades). > > the amazon prefix is longer by a bit so won't really use the /8 even > > if ucsd keeps the /8 up. > > And one of the principal people in the network telescope project was KC, who > also weaseled herself onto the ARDC board without even holding an amateur > radio license. Conflict of interest here, holy carp. having a large user of the space (and perhaps even a partner to the org) be a part of the board doesn't seem like a conflict. > Caida has been using an amateur radio resource as far back as 2001, when we > couldn't even be blessed to get 44net space for our own legitimate radio use. > I'm sure I have the message from Brian denying it in my archives. I'm sure you can pursue legal avenues if you feel this went super sideways. you should do that. -chris > - -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAl0xRoQACgkQYTmgYVLG > kUBDmA//XOUz4PtyFktPm0Yi2jyA56y1QGLdZrgc+dfk8mPImjE3ipaJ+GgUEwEY > a10TccbNuC9hWZv1n1F/pD/Kcn+An9uhHOOrIIb9DfST0eUq/qhlK00tbq/1WJtI > SKOvJNhdE7815ucl4096e5fEOv7HQg9SxRpstLN/zZffFBL0R3fPtKEWbrgxA6lN > Ldj3DnCie7tMG0ZXSTUkHBoumE7NlAcEolQhdu1SrnCbePtbEk/oSy0krT6xIoz5 > BoXKarFAh/Ti1LMTUnDt2g1XEKrTtUI40egSzAlBXGvLzkDqW5539ZY+X5HElZzM > Kqo84qmupX04xW1QFyA0EtKIwc1RD0PtnN6xhqOQ04llXYp6q82MKlNfgrvC+A2+ > W2fq6EOZXAmRobNnfWt6g2k6I9Tc7fRc2xdMZNd8SU8BML/F3wfPPAnifaYqem2Z > eoFtVhNr+yaAKUo7OumkfXI40Ab1AfP+r/iGiRg/S3oejhcVMyrZpd6mKAZ6OdiD > lbi+lV4K2T0yKntRifqE/R1ASi7RjF379g63IOq1e2CpLbkRljNKx9gi/iU95PP2 > C4qxcmX2SRPPDoGiz7Wom9UtWO9NxSFWISVqNL3jdOkCi3388TpRiI4mKLopLgzz > wS9FozypHtRFOBZM0D7+1yckxhsf1Q4lZ0WNIVGNlCl6PaU7CnU= > =1JCu > -----END PGP SIGNATURE----- From bill at herrin.us Fri Jul 19 05:04:10 2019 From: bill at herrin.us (William Herrin) Date: Thu, 18 Jul 2019 22:04:10 -0700 Subject: 44/8 In-Reply-To: <20190719034012.GB11512@puck.nether.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: On Thu, Jul 18, 2019 at 8:48 PM Majdi S. Abbas wrote: > In order to sell something, you must own it...if you pop up, > claim responsibility for it, sit on it a while, and then sell it.. > did you truly own it? > Yes, actually. The legal term is "adverse possession" or more colloquially "squatters rights." Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Fri Jul 19 05:23:42 2019 From: sean at donelan.com (Sean Donelan) Date: Fri, 19 Jul 2019 01:23:42 -0400 (EDT) Subject: Multi-day GNSS Galileo outage -- Civilization survives Message-ID: So much for the disaster scenarioes about a global clamity, planes falling out the sky, the end of civil society because a global navigation satellite system fails. The European Galileo GNSS was down for days, and life went on. I guess disasters exercise planners now need a new technical failure for table top exercises. • NAGU number 2019025 on 2019-07-11 14:45 on the potential service degradation; • NAGU number 2019026 on 2019-07-13 20:15 on the service outage; • NAGU number 2019027 on 2019-07-18 08:20 on the service recovery; https://www.gsa.europa.eu/newsroom/news/galileo-initial-services-have-now-been-restored From swmike at swm.pp.se Fri Jul 19 05:30:49 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 19 Jul 2019 07:30:49 +0200 (CEST) Subject: Multi-day GNSS Galileo outage -- Civilization survives In-Reply-To: References: Message-ID: On Fri, 19 Jul 2019, Sean Donelan wrote: > So much for the disaster scenarioes about a global clamity, planes falling > out the sky, the end of civil society because a global navigation satellite > system fails. The European Galileo GNSS was down for days, and life went on. It wasn't even in full production, and I am not aware of much equipment that solely relies on Galileo. A lot of devices today can use multiple GNSS and this is great, as this incident shows that one of them can go offline. Relying on only one of them is risky. This outage and its lack of ramifications doesn't imply that if GPS went offline there woulnd't be consequences. Galileo is just a few years old, and wasn't even in production. If GPS would go offline, you'd see a lot different fallout. Lots of things rely on GPS solely. -- Mikael Abrahamsson email: swmike at swm.pp.se From owen at delong.com Fri Jul 19 05:52:54 2019 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Jul 2019 22:52:54 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> <20190719035015.GC11512@puck.nether.net> <9dcbadc5-b8ba-137b-aef4-a6199c2e2fb8@bryanfields.net> Message-ID: > On Jul 18, 2019, at 21:31 , Christopher Morrow wrote: > > On Fri, Jul 19, 2019 at 12:28 AM Bryan Fields wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> >> On 7/18/19 11:56 PM, Christopher Morrow wrote: >>> Sure,but... that space has been an internet telescope supporting >>> numerous research folk for a decade + (probably closer to 2 decades). >>> the amazon prefix is longer by a bit so won't really use the /8 even >>> if ucsd keeps the /8 up. >> >> And one of the principal people in the network telescope project was KC, who >> also weaseled herself onto the ARDC board without even holding an amateur >> radio license. Conflict of interest here, holy carp. > > having a large user of the space (and perhaps even a partner to the > org) be a part of the board doesn't seem like a conflict. There is some question as to the legitimacy of a large allocation of this space to CAIDA as CAIDA has virtually nothing to do with Amateur Radio. Putting someone without an Amateur Radio License who represents such an organization does, actually, look like a COI to me. Don’t get me wrong… I like KC and I think CAIDA does some great stuff. I just don’t think it serves an Amateur Radio purpose and thus doesn’t really belong in 44.0.0.0/8. >> Caida has been using an amateur radio resource as far back as 2001, when we >> couldn't even be blessed to get 44net space for our own legitimate radio use. >> I'm sure I have the message from Brian denying it in my archives. > > I'm sure you can pursue legal avenues if you feel this went super sideways. > you should do that I suspect that’s not unlikely, but I’m still trying to learn more about what and how it happened first. Owen KB6MER From george.herbert at gmail.com Fri Jul 19 07:20:11 2019 From: george.herbert at gmail.com (George Herbert) Date: Fri, 19 Jul 2019 00:20:11 -0700 Subject: Multi-day GNSS Galileo outage -- Civilization survives In-Reply-To: References: Message-ID: <7B91F13B-A6EF-4EDF-9D79-DF9C02B1CF1F@gmail.com> Worthwhile noting however that they’re not reliably pushing notifications to people on their notifications list. Worthwhile checking fundamentals you do depend on with your own low level monitoring. -George Sent from my iPhone > On Jul 18, 2019, at 10:30 PM, Mikael Abrahamsson wrote: > >> On Fri, 19 Jul 2019, Sean Donelan wrote: >> >> So much for the disaster scenarioes about a global clamity, planes falling out the sky, the end of civil society because a global navigation satellite system fails. The European Galileo GNSS was down for days, and life went on. > > It wasn't even in full production, and I am not aware of much equipment that solely relies on Galileo. > > A lot of devices today can use multiple GNSS and this is great, as this incident shows that one of them can go offline. Relying on only one of them is risky. > > This outage and its lack of ramifications doesn't imply that if GPS went offline there woulnd't be consequences. Galileo is just a few years old, and wasn't even in production. If GPS would go offline, you'd see a lot different fallout. Lots of things rely on GPS solely. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From jcurran at arin.net Fri Jul 19 12:03:10 2019 From: jcurran at arin.net (John Curran) Date: Fri, 19 Jul 2019 12:03:10 +0000 Subject: 44/8 In-Reply-To: <20190719034012.GB11512@puck.nether.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: On 18 Jul 2019, at 11:40 PM, Majdi S. Abbas > wrote: ... There are some potential legal title questions around this, and if ARIN is facilitating transactions with questionable history, that is something the Internet community might be concerned about. Majdi - If you believe that fraud has occurred with respect to an update of the ARIN registry, then please report it here - https://www.arin.net/reference/tools/fraud_report/ Be specific in your report regarding what change you believe was in error and why – we investigate all such reports and will correct any changes made in error. Thanks! /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsk at gsp.org Fri Jul 19 12:31:38 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 19 Jul 2019 08:31:38 -0400 Subject: netstat -s In-Reply-To: References: Message-ID: <20190719123138.GA19874@gsp.org> On Wed, Jul 17, 2019 at 05:54:49PM -0700, Randy Bush wrote: > do folk use `netstat -s` to help diagnose on routers/switches? I (mostly) use it on firewalls, but yes, it's something I turn to fairly often (along with other incantations of netstat, plus lsof and other tools). ---rsk From bortzmeyer at nic.fr Fri Jul 19 12:33:31 2019 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 19 Jul 2019 08:33:31 -0400 Subject: 44/8 In-Reply-To: <20190719031324.GA11512@puck.nether.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> Message-ID: <20190719123331.GA20295@laperouse.bortzmeyer.org> On Thu, Jul 18, 2019 at 11:13:24PM -0400, Majdi S. Abbas wrote a message of 26 lines which said: > Amusingly, they still seem to be advertising the covering > aggregate, Are you sure? RIPE stat shows it stopped one month ago Same thing on other looking glasses. From jcurran at istaff.org Fri Jul 19 12:45:44 2019 From: jcurran at istaff.org (John Curran) Date: Fri, 19 Jul 2019 08:45:44 -0400 Subject: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC In-Reply-To: <6ee6c6cc-0584-ca49-8bd6-d633c5fbc429@mtcc.com> References: <922fae7d-dcc9-dd16-9f70-4202655c72fa@telcodata.us> <57dbb8c2-b126-ebcf-4eea-15893dc207ab@telcodata.us> <6ee6c6cc-0584-ca49-8bd6-d633c5fbc429@mtcc.com> Message-ID: <5F15CC06-ED69-4EAE-BDB0-B0E4A0179243@istaff.org> On 11 Jul 2019, at 3:23 PM, Michael Thomas wrote: > > I used to think that email spam was a law enforcement problem too, but it's become very clear that law enforcement has little to no interest in solving geeks' problems. Law enforcement deals with legal entities (persons, organizations) and jurisdictions (i.e. physical locations) in determining both applicable law and appropriate enforcement authority. The Internet does not provide reliable attribution of entity or locale, thus precluding any efficient use of our existing law enforcement framework – it is no surprise that our Internet design choices have such consequences. c'est la vie sur Internet, /John From ak at mid.net Fri Jul 19 03:16:54 2019 From: ak at mid.net (Adam Korab) Date: Fri, 19 Jul 2019 03:16:54 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> Message-ID: <20190719031651.GA29056@mid.net> On 07/18/2019 at 23:08, Job Snijders wrote: > A potential upside is that hamnet operators maybe have access to some RPKI > services now! OK, I'll bite....how do you mean? --Adam From koutalisk at gmail.com Thu Jul 18 21:40:44 2019 From: koutalisk at gmail.com (Konstantinos Koutalis) Date: Fri, 19 Jul 2019 00:40:44 +0300 Subject: Bgpmon alternatives? In-Reply-To: References: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> <20190616094827.GA34940@meow.BKantor.net> <6429449a-e076-b4db-62f0-1eb5fc43454f@he.net> <20190616112050.GA35876@meow.BKantor.net> <67F895A2-1F69-4442-AA0D-7BF415FBA893@as397444.net> Message-ID: I've been testing out thousandeyes for the past 1,5-2 month(s) and I'm very happy with it. Depending on what you want to do with it, it can be expensive but for my current employer it's worth the investment due to the extra visibility it provides. -- Kostas (Konstantinos) Koutalis Sent from my OnePlus 6 On Thu, Jul 18, 2019, 03:17 TJ Trout wrote: > Anyone know of a hosted alternative to bgpmon? I'm testing Qrator but I > can't determine if it will notify in real-time of a prefix hijack? > > On Sun, Jun 16, 2019 at 9:23 AM Matt Corallo wrote: > >> There's also https://github.com/NLNOG/bgpalerter (which I believe >> they're trying to turn into a website frontend based on RIS, but I run it >> with patches for as_path regexes and it works pretty well). >> >> On Jun 16, 2019, at 07:40, Michael Hallgren wrote: >> >> RIS Live API is a choice for this. >> >> mh >> Le 16 juin 2019, à 13:21, Brian Kantor a écrit: >>> >>> That would be wonderful. Thank you! >>> - Brian >>> >>> >>> On Sun, Jun 16, 2019 at 03:59:29AM -0700, Mike Leber wrote: >>> >>>> I'm sure if it doesn't do exactly that already, we can add it shortly. >>>> >>>> Some of planned functionality for hijack detection is already live. >>>> That's one of the main reasons for creating this service. >>>> >>>> Mike. >>>> >>>> On 6/16/19 2:48 AM, Brian Kantor wrote: >>>> >>>>> On Sun, Jun 16, 2019 at 02:25:40AM -0700, Mike Leber wrote: >>>>> >>>>>> As a beta service you can try out rt-bgp.he.net. This is a real time >>>>>> bgp monitoring service we are developing. >>>>>> >>>>> It's interesting, but I don't see any way to do what I primarily >>>>> use the existing BGPMon for: watch for hijacks. >>>>> >>>>> That is, set up one or more prefixes to be continuously monitored >>>>> and have the monitor send me an email alert when that prefix or a >>>>> subnet of it begins to be announced by someone new. >>>>> >>>>> For example, if I have told it to monitor 44.0.0.0/8 and someone >>>>> somewhere begins announcing it, or perhaps 44.1.0.0/16, I'd very >>>>> much like to know about that, along with details of who and where. >>>>> >>>>> Then if that announcement is authorized, I can tell the monitoring >>>>> service that this new entry is NOT a hijack, and it won't bug me >>>>> about it again. >>>>> >>>>> Can it be persuaded to do this? >>>>> - Brian >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog-list-2009 at hayler.de Fri Jul 19 07:39:22 2019 From: nanog-list-2009 at hayler.de (Michael Hayler) Date: Fri, 19 Jul 2019 09:39:22 +0200 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> Message-ID: <20190719073921.h6oqsb6rgsb6eh7q@hayler.de> On 19/07/18 11:02, Christopher Morrow wrote: > So.. this is/was a legacy allocation, right? with some 'not great' > contact/etc info... > the ARIN folk could have said: "Well.... sure! if the current folk who > control access can positively show they do AND they don't mind parting > with a /10... ok?" > > This ends up with a /10 of a /8 with better registration information > and MAYBE better records keeping over time, right? > that seems like a win to the ARIN community? I see at least 2 /16 out of the mentioned /10 that are well documented in the HamnetDB. As far as I know, there is an ongoing renumbering "project" to get Services out of 44.224/16 and 44.225/16 here in DL, but from my perspective that is not finished yet. So that promisses some fun ... also, I do not see the Covering /8 Route anymore at our Internet Edge Routers. -- Best Regards Michael Hayler (DC1SHM) From matt at netfire.net Fri Jul 19 13:33:54 2019 From: matt at netfire.net (Matt Harris) Date: Fri, 19 Jul 2019 08:33:54 -0500 Subject: 44/8 In-Reply-To: <20190719034444.ober67lvyr4vvpw6@welcome.groovy.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034444.ober67lvyr4vvpw6@welcome.groovy.net> Message-ID: On Thu, Jul 18, 2019 at 10:45 PM William Waites wrote: > > Then we can decide, openly and transparently, if, for example, some piece > of > 44/8 should be returned to IANA for allocation to the RIRs. > This sounds like the more correct answer with regard to what should be done with space that isn't and is probably never going to be used that is allocated to a community organization. After reading the analogy above regarding spectrum space, I shudder to think what the community response would be if the FCC were to tacitly allow the ARRL to receive several million (or billion in this case) dollars from, say, Verizon in exchange for some part of our exclusive amateur bands. Indeed the ARRL has a fund (the "Spectrum Defense Fund") with the purpose of employing lawyers and public policy folks to help prevent our community resources from shrinking out from under us. 73's - K1RIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Fri Jul 19 14:37:51 2019 From: bruns at 2mbit.com (Brielle) Date: Fri, 19 Jul 2019 08:37:51 -0600 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: > On Jul 19, 2019, at 6:03 AM, John Curran wrote: > Be specific in your report regarding what change you believe was in error and why – we investigate all such reports and will correct any changes made in error. Actually, I’d love to hear an official statement from ARIN about the state of this transfer - it’s legitimacy, ARINs involvement with it, who approved of the transfer (if any) etc. Was ARIN not involved? If not, why not? 44/8 isn’t like a normal assignment. It’s a legacy assignment likely with stipulations from when it was originally assigned to the HAM group(s). From the outside, this smells fishy and reeks of backroom deals. I remember when ARIN was handing out /20s to shell company spam spewers on a daily basis, with fraudulent Whois records and companies that were formed the day before just to get clean IP space to spew from. The drawn out bullshit I had to deal with just to legitimately transfer a legacy /24 from an old consulting company to my new one, where you (ARIN) demanded we hand over confidential business documents including asset lists, company financials... So yeah, some of us kinda view this with a huge level of awe and disgust. I’m not a HAM license holder, but that doesn’t mean that situations like this don’t make me worry. From sethm at rollernet.us Fri Jul 19 14:46:12 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 19 Jul 2019 07:46:12 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034444.ober67lvyr4vvpw6@welcome.groovy.net> Message-ID: <08de0e2e-26cf-0091-d29c-28b2d09a3f5f@rollernet.us> On 7/19/19 6:33 AM, Matt Harris wrote: > > After reading the analogy above regarding spectrum space, I shudder to > think what the community response would be if the FCC were to tacitly > allow the ARRL to receive several million (or billion in this case) > dollars from, say, Verizon in exchange for some part of our exclusive > amateur bands. Indeed the ARRL has a fund (the "Spectrum Defense Fund") > with the purpose of employing lawyers and public policy folks to help > prevent our community resources from shrinking out from under us. But clearly the cell carriers need all the spectrum, for only they know what's best for us. From jcurran at arin.net Fri Jul 19 14:54:24 2019 From: jcurran at arin.net (John Curran) Date: Fri, 19 Jul 2019 14:54:24 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: On 19 Jul 2019, at 10:37 AM, Brielle > wrote: On Jul 19, 2019, at 6:03 AM, John Curran > wrote: Be specific in your report regarding what change you believe was in error and why – we investigate all such reports and will correct any changes made in error. Actually, I’d love to hear an official statement from ARIN about the state of this transfer - it’s legitimacy, ARINs involvement with it, who approved of the transfer (if any) etc. Was ARIN not involved? If not, why not? 44/8 isn’t like a normal assignment. It’s a legacy assignment likely with stipulations from when it was originally assigned to the HAM group(s). As stated before, ARIN did receive and process a request from the 44/8 registrant to transfer a portion of the block to another party. For all transfer requests, we review and confirm: - That the source of the transfer is the legal entity which holds the rights to the address block in the registry - That the transfer is authorized by an registered officer of that legal entity - That the recipient org has approval per policy to receive an address block of the appropriate size You may have other questions that are better referred to the registrant (Amateur Radio Digital Communications); e.g. regarding why the request was made – I will note that the contact information for the block is current in the Whois database, and available at Thanks, /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Fri Jul 19 14:57:10 2019 From: matt at netfire.net (Matt Harris) Date: Fri, 19 Jul 2019 09:57:10 -0500 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: On Fri, Jul 19, 2019 at 9:38 AM Brielle wrote: > > > On Jul 19, 2019, at 6:03 AM, John Curran wrote: > > Be specific in your report regarding what change you believe was in > error and why – we investigate all such reports and will correct any > changes made in error. > > Actually, I’d love to hear an official statement from ARIN about the state > of this transfer - it’s legitimacy, ARINs involvement with it, who approved > of the transfer (if any) etc. > That would be an interesting read. > Was ARIN not involved? If not, why not? 44/8 isn’t like a normal > assignment. It’s a legacy assignment likely with stipulations from when it > was originally assigned to the HAM group(s). > So my understanding based on what Job has said in this thread, without looking myself, is that it seems as though 44/8 was brought under an ARIN RSA either as part of this deal or as a pre-requisite to this deal happening. Hence it's no longer "legacy" space that isn't covered by an RIR RSA but is instead now covered by an ARIN RSA. This is interesting because amateur radio is a global (and beyond - the folks on the ISS participate!) pursuit, one which is officially sanctioned by almost every national government in the world, and which has international involvement overseen by the ITU ( https://life.itu.int/radioclub/ars.htm). A /8 is an exceptionally large IPv4 block, and governance thereof, when held in trust for the benefit of a greater community, should always be transparent. At the very least, we must admit that there was a tremendous failure of transparency here. - Matt (K1RIN) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Fri Jul 19 15:01:28 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 19 Jul 2019 15:01:28 +0000 Subject: Multi-day GNSS Galileo outage -- Civilization survives In-Reply-To: <7B91F13B-A6EF-4EDF-9D79-DF9C02B1CF1F@gmail.com> References: , <7B91F13B-A6EF-4EDF-9D79-DF9C02B1CF1F@gmail.com> Message-ID: I suspect the Vatican was involved :) -mel > On Jul 19, 2019, at 12:20 AM, George Herbert wrote: > > Worthwhile noting however that they’re not reliably pushing notifications to people on their notifications list. > > Worthwhile checking fundamentals you do depend on with your own low level monitoring. > > -George > > Sent from my iPhone > >>> On Jul 18, 2019, at 10:30 PM, Mikael Abrahamsson wrote: >>> >>> On Fri, 19 Jul 2019, Sean Donelan wrote: >>> >>> So much for the disaster scenarioes about a global clamity, planes falling out the sky, the end of civil society because a global navigation satellite system fails. The European Galileo GNSS was down for days, and life went on. >> >> It wasn't even in full production, and I am not aware of much equipment that solely relies on Galileo. >> >> A lot of devices today can use multiple GNSS and this is great, as this incident shows that one of them can go offline. Relying on only one of them is risky. >> >> This outage and its lack of ramifications doesn't imply that if GPS went offline there woulnd't be consequences. Galileo is just a few years old, and wasn't even in production. If GPS would go offline, you'd see a lot different fallout. Lots of things rely on GPS solely. >> >> -- >> Mikael Abrahamsson email: swmike at swm.pp.se From Brian at ampr.org Fri Jul 19 15:02:57 2019 From: Brian at ampr.org (Brian Kantor) Date: Fri, 19 Jul 2019 08:02:57 -0700 Subject: 44.192.0.0/10 sale Message-ID: <20190719150257.GA30984@meow.BKantor.net> Because questions have arisen here that are well answered by a short series of postings from the 44net mailing list, at the request of the author [Phil Karn] and others, I am reposting them here. - Brian From: Phil Karn Subject: [44net] 44.192.0.0/10 sale Hello all, I've not been active here, but some of you may remember me as the guy who first got TCP/IP going on amateur packet radio way back in 1986. At one time, my name was registered as the owner of the block. This makes me one of a VERY small group of people with any arguable personal property interest in network 44. And yes, 25% of this space, which is VERY unlikely to ever be used by hams, has been sold to Amazon. Rather than try to personally profit from this, we all readily agreed to place the *entire* proceeds of this sale into a 501(c)(3) charity chartered to support amateur digital radio and related developments. No one is buying a yacht or a mansion. As a tax-exempt charity, our tax returns and related documents will be publicly available so you can see what is being done. Like the rest of the amateur community, all of you will have the opportunity to apply for grants and do good things for amateur radio with them. 73, Phil _________________________________________ On 7/18/19 21:25, Gavin Rogers wrote: > On 19/07/2019 12:19 pm, Phil Karn wrote: >> Like the rest of the amateur community, all of you >> will have the opportunity to apply for grants and do good things for >> amateur radio with them. > I don't know much about US-registered charities and tax law, but will > this include amateurs and clubs located outside of the US? Sure. We'd like to cast the net as widely as possible for worthy grant recipients. Doesn't matter where they are in the world, as long as the purpose is consistent with our charter, which is to benefit amateur digital radio and related development. That's a worldwide activity. I suppose US legal restrictions on dealing with certain "pariah" countries might come into play (e.g., North Korea) but that's a very short list and there isn't much ham radio in them anyway. We're already thinking about things like: Educational grants to students who are hams; Existing amateur radio 501(c)(3) organizations; Development of *freely available* technology: hardware, software, protocols, etc Field trials, demonstrations, pilot projects, educational outreach, etc; This list is NOT exhaustive by any means, and in fact we'll be looking for good ideas from anyone who has them. We want to be as transparent about this as possible. Again, though we might have been able to establish a *personal* property claim over network 44, we all quickly decided to not open that can of worms and instead sign everything over to the ARDC. Face it, given who we are we'd probably just spend the money on ham radio development ourselves. This is a much better way to do it. 73, Phil _________________________________________ On 7/18/19 21:38, David Ranch wrote: > > Wow! This is rather big news but has also been VERY opaque to the > AMPR community. I'm also surprised that the sale has already occurred > and not auctioned off to say the highest bidder? Since ARDC is a > corporation, when will we learn about the sale price and how this > money will be *really* spent? > > The bottom of https://www.ampr.org/amprnet/ does cover a little of > this but it's all too vague for my tastes. I didn't like the secrecy either, but it was necessary given the nature of the process. We are precluded by the terms of the sale from giving precise figures at this time, but suffice it to say that we (Brian, actually) worked *very* hard to get the best possible price. I am fully satisfied that he did. Everyone with any arguable legal property interest in 44/8 was fully informed and consented to give up that interest and have it benefit ham radio instead. I didn't even think twice about it. Remember, this is an IRS 501(c)(3) charity, which means there are strict rules on transparency, how money can be spent and how it must be accounted for. Tax returns and other documents are public information. One of the most important rules for a non-profit, which the IRS takes pretty seriously, is a prohibition on "self dealing". This is how Donald Trump's personal charity got shut down. 73, Phil _________________________________________ On 7/18/19 22:08, David Ranch wrote: > >> I have so many words for the conspiracy theorists and negative >> naysayers, >> but Ill hold that back and not contribute to the shitstorm. > > My main concern is what will stop the ARDC board from selling the next > 25% or 50% of 44 space? The fact that, unlike 44.192.0.0/10, it's being used by hams? I personally approved the sale on two conditions: 1) The block wasn't being used by hams and had no viable prospect of being used by hams. [Editor's note: minor correction: 44.224.0.0/15 *was* in use as an unrouted internal network by a German ham radio society; they have been given a routable block of /15 and were in the process of renumbering to it.] 2) All of the proceeds went to a non-profit to benefit amateur digital development and related efforts. I am not an expert in the IP address market, but from everything I saw and heard I am fully satisfied that Brian did the best possible job in getting the best price for the /10 that was sold. It was explained to us that a /10 would be more than twice as valuable as two /11s or four /12s and so on, and this seemed perfectly logical to me. Remember, IPv4 addresses won't be valuable forever. IPv6 is developing slowly, but it *is* developing. I for one have long been interested in getting IPv6 much more widely used within amateur radio (as well as the larger Internet) as even the full 44/8 block was woefully inadequate for doing a lot of the things that could and should be done. 73, Phil From beecher at beecher.cc Fri Jul 19 15:02:59 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 19 Jul 2019 11:02:59 -0400 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: > > Was ARIN not involved? If not, why not? 44/8 isn’t like a normal > assignment. It’s a legacy assignment likely with stipulations from when it > was originally assigned to the HAM group(s). > My recollection from some years ago was that the IANA assignments done before the RIR system were not done with legally binding agreements as they are today. In the absence of proof that there were IANA legal restrictions on 44/8, that should likely not be assumed. On Fri, Jul 19, 2019 at 10:40 AM Brielle wrote: > > > On Jul 19, 2019, at 6:03 AM, John Curran wrote: > > Be specific in your report regarding what change you believe was in > error and why – we investigate all such reports and will correct any > changes made in error. > > Actually, I’d love to hear an official statement from ARIN about the state > of this transfer - it’s legitimacy, ARINs involvement with it, who approved > of the transfer (if any) etc. > > Was ARIN not involved? If not, why not? 44/8 isn’t like a normal > assignment. It’s a legacy assignment likely with stipulations from when it > was originally assigned to the HAM group(s). > > From the outside, this smells fishy and reeks of backroom deals. > > I remember when ARIN was handing out /20s to shell company spam spewers on > a daily basis, with fraudulent Whois records and companies that were formed > the day before just to get clean IP space to spew from. > > The drawn out bullshit I had to deal with just to legitimately transfer a > legacy /24 from an old consulting company to my new one, where you (ARIN) > demanded we hand over confidential business documents including asset > lists, company financials... > > So yeah, some of us kinda view this with a huge level of awe and disgust. > I’m not a HAM license holder, but that doesn’t mean that situations like > this don’t make me worry. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Fri Jul 19 15:06:49 2019 From: matt at netfire.net (Matt Harris) Date: Fri, 19 Jul 2019 10:06:49 -0500 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: On Fri, Jul 19, 2019 at 9:54 AM John Curran wrote: > > As stated before, ARIN did receive and process a request from the 44/8 > registrant to transfer a portion of the block to another party. > > For all transfer requests, we review and confirm: > > - That the source of the transfer is the legal entity which holds the > rights to the address block in the registry > - That the transfer is authorized by an registered officer of that legal > entity > - That the recipient org has approval per policy to receive an address > block of the appropriate size > > You may have other questions that are better referred to the registrant > (Amateur Radio Digital Communications); e.g. regarding why the request was > made – > I will note that the contact information for the block is current in the > Whois database, and available at < > https://search.arin.net/rdap/?query=44.0.0.0> > Hey John, I think perhaps the relevant questions for ARIN here are: 1> How did the organization currently holding the rights to the 44/8 block come to hold those rights, and how did ARIN verify that it held those rights? 2> Did ARIN ensure that the establishment of an ARIN RSA for the 44/8 block did not violate any prior agreements related to the stewardship of the 44/8 block? If so, how was this done? 3> What were the terms under which the rights to the 44/8 block was held by said organization prior to the establishment of an ARIN RSA? 4> When was an ARIN RSA established which covered the 44/8 block? The bigger question here is how we got to the point where an organization with virtually no transparency came to hold the legal rights to a community asset without any sort of oversight or contractual obligations with regard to management of said resource. Ultimately that means figuring out if the legacy agreements by which 44/8 was held by the organization did indeed include encumberences on the sale or transfer of the space (which would make sense, if I am giving stewardship of a large community asset to an organization, I'm going to include stipulations about what they can't do with it, and selling it to a for-profit entity for cash is going to be #1 on that list.) Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Jul 19 15:09:57 2019 From: jcurran at arin.net (John Curran) Date: Fri, 19 Jul 2019 15:09:57 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: <895027C7-ADFE-4FCA-A84C-97A8FF7F3A8D@arin.net> On 19 Jul 2019, at 11:06 AM, Matt Harris wrote: > > Hey John, > I think perhaps the relevant questions for ARIN here are: > ... Matt - ARIN doesn’t publicly discuss details of any specific registration requests; you would need to refer any of those questions to the registrant. Thanks, /John John Curran President and CEO American Registry for Internet Numbers From morrowc.lists at gmail.com Fri Jul 19 15:12:47 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 19 Jul 2019 11:12:47 -0400 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: On Fri, Jul 19, 2019 at 10:58 AM Matt Harris wrote: >Hence it's no longer "legacy" space that isn't covered by an RIR RSA but is instead now covered by an ARIN RSA. > 'RIR RSA" is not a thing. Legacy blocks are basically drifting in the winds... there's no requirement on the holders to do anything really.. If they choose to they could have (in the ARIN region) signed a LRSA, but that's even been removed, in favor of the now much more watered down RSA. From marco at paesani.it Fri Jul 19 15:19:41 2019 From: marco at paesani.it (Marco Paesani) Date: Fri, 19 Jul 2019 17:19:41 +0200 Subject: 44/8 In-Reply-To: <895027C7-ADFE-4FCA-A84C-97A8FF7F3A8D@arin.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> <895027C7-ADFE-4FCA-A84C-97A8FF7F3A8D@arin.net> Message-ID: Hi Guys Today there are over 200 networks announced on big internet on 44/8. It's normal ? Ciao, Il giorno ven 19 lug 2019 alle ore 17:17 John Curran ha scritto: > On 19 Jul 2019, at 11:06 AM, Matt Harris wrote: > > > > Hey John, > > I think perhaps the relevant questions for ARIN here are: > > ... > > Matt - > > ARIN doesn’t publicly discuss details of any specific registration > requests; you would need to refer any of those questions to the registrant. > > Thanks, > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > -- Marco Paesani Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco at paesani.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Jul 19 15:29:53 2019 From: jcurran at arin.net (John Curran) Date: Fri, 19 Jul 2019 15:29:53 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: On 19 Jul 2019, at 11:12 AM, Christopher Morrow wrote: > > On Fri, Jul 19, 2019 at 10:58 AM Matt Harris wrote: > >> Hence it's no longer "legacy" space that isn't covered by an RIR RSA but is instead now covered by an ARIN RSA. > > 'RIR RSA" is not a thing. > Legacy blocks are basically drifting in the winds... there's no > requirement on the holders to do anything really.. > If they choose to they could have (in the ARIN region) signed a LRSA, > but that's even been removed, in favor > of the now much more watered down RSA. Matt - Chris is correct. Those who received IPv4 address blocks by InterNIC (or its predecessors) prior to the inception of ARIN on 22 December 1997 are legacy resource holders, and continue to receive those same registry services for those blocks (Whois, reverse DNS, ability to update) without any need for an agreement with ARIN. This has been provided without any fee to the original registrants (or their legal successors) as recognition of their contributions to the early Internet. Some legacy resource holders opt to sign a “legacy registration services agreement” by which ARIN provides specific and well-defined legal rights to the registrant – this is the same RSA as other ARIN customers, but ARIN caps the total annual maintenance fees that are incurred by legacy resource holders. An RSA is also required to receive services that the community has funded the developed since ARIN’s inception, such as resource certification services. Thanks, /John John Curran President and CEO American Registry for Internet Numbers From jhellenthal at dataix.net Fri Jul 19 15:30:07 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Fri, 19 Jul 2019 10:30:07 -0500 Subject: netstat -s In-Reply-To: <20190719123138.GA19874@gsp.org> References: <20190719123138.GA19874@gsp.org> Message-ID: <20190719153007.B0A8B513C937@DataIX.net> Personaly I think that circumstance weighs the benifits of the utilities used to diagnose a problem. Given any instance, you use the utilities available to you to see that problem through to completion of a proper result. The question in hand is very broad but particular to an instance that is trying to be solved. 1. Dev is trying to weight whether its worth while to consider diagnosing a problem that considers the use of netstat with an option that in its legacy use was quite considerable debug output. 2. Regardless of the system the old method is still supported but is the output still supported and enough to gain evidential knowledge of the current facts. 3. Will the rseult gathhered by this and the effort be well worth considering the target be gainful toward the final intended result. With that said, Randy I personally think that you already have the annswer that you were looking for given the minimal input ... maybe 3-4 actual interactions of the utility but given that, I think I would sum it up as people don't know the actual usefulness of netstat(1) these days and why it was originaly put out there and what they could gain by instances where they may be required to use it to set themselves on a path to correct the pronlem they are currently facing. On Fri, Jul 19, 2019 at 08:31:38AM -0400, Rich Kulawiec wrote: > On Wed, Jul 17, 2019 at 05:54:49PM -0700, Randy Bush wrote: > > do folk use `netstat -s` to help diagnose on routers/switches? > > I (mostly) use it on firewalls, but yes, it's something I turn > to fairly often (along with other incantations of netstat, plus > lsof and other tools). > > ---rsk -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 533 bytes Desc: not available URL: From beecher at beecher.cc Fri Jul 19 15:33:32 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 19 Jul 2019 11:33:32 -0400 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: > > If they choose to they could have (in the ARIN region) signed a LRSA, > but that's even been removed, in favor > of the now much more watered down RSA. > I believe ARCD would have been required to sign an LRSA (if they had not previously) in order to transfer the block to Amazon. Also, a question for perhaps John here. Organization: Amazon Technologies Inc. (AT-88-Z) > https://www.arin.net/about/corporate/agreements/rsa_faq/#legacy-resource-holder-faq How do I know if my legacy number resources are already covered under an > LRSA or not? Typically, any legacy number resources that are covered under an LRSA will > be associated with an Organization ID ending in a “-Z”. If you have any > questions regarding your legacy resources, please contact ARIN’s > Registration Services Department. You may contact the Registration Services > Help Desk at +1.703.227.0660 or by submitting an Ask ARIN > > ticket via your ARIN Online account. Unless there was a clerical error somewhere, is this telling us that 44.192.0.0/10 remains classified as a legacy resource? I didn't think that was possible given that Amazon was not the original assignee. On Fri, Jul 19, 2019 at 11:19 AM Christopher Morrow wrote: > On Fri, Jul 19, 2019 at 10:58 AM Matt Harris wrote: > > >Hence it's no longer "legacy" space that isn't covered by an RIR RSA but > is instead now covered by an ARIN RSA. > > > > 'RIR RSA" is not a thing. > Legacy blocks are basically drifting in the winds... there's no > requirement on the holders to do anything really.. > If they choose to they could have (in the ARIN region) signed a LRSA, > but that's even been removed, in favor > of the now much more watered down RSA. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Fri Jul 19 15:34:47 2019 From: matt at netfire.net (Matt Harris) Date: Fri, 19 Jul 2019 10:34:47 -0500 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: On Fri, Jul 19, 2019 at 10:29 AM John Curran wrote: > > Matt - > > Chris is correct. Those who received IPv4 address blocks by InterNIC (or > its predecessors) prior to the inception of ARIN on 22 December 1997 are > legacy resource holders, and continue to receive those same registry > services for those blocks (Whois, reverse DNS, ability to update) without > any need for an agreement with ARIN. This has been provided without any > fee to the original registrants (or their legal successors) as recognition > of their contributions to the early Internet. > Hey John, I understand that, however my understanding is that the establishment of an ARIN RSA is required prior to the transfer of a block or a portion or a block via ARIN (such as the transfer of 44.192/10). Thus, this would mean that the 44/8 block is now governed by an (well, more than one, now that it's split) ARIN RSA (or LRSA) whereas it was not before. Is that not correct? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Jul 19 15:41:33 2019 From: jcurran at arin.net (John Curran) Date: Fri, 19 Jul 2019 15:41:33 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: On 19 Jul 2019, at 11:34 AM, Matt Harris > wrote: On Fri, Jul 19, 2019 at 10:29 AM John Curran > wrote: Matt - Chris is correct. Those who received IPv4 address blocks by InterNIC (or its predecessors) prior to the inception of ARIN on 22 December 1997 are legacy resource holders, and continue to receive those same registry services for those blocks (Whois, reverse DNS, ability to update) without any need for an agreement with ARIN. This has been provided without any fee to the original registrants (or their legal successors) as recognition of their contributions to the early Internet. Hey John, I understand that, however my understanding is that the establishment of an ARIN RSA is required prior to the transfer of a block or a portion or a block via ARIN (such as the transfer of 44.192/10). Thus, this would mean that the 44/8 block is now governed by an (well, more than one, now that it's split) ARIN RSA (or LRSA) whereas it was not before. Is that not correct? Matt - ARIN doesn’t discuss details of specific registrations publicly; you need to refer any such questions to the registrant. /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Jul 19 15:42:54 2019 From: jcurran at arin.net (John Curran) Date: Fri, 19 Jul 2019 15:42:54 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: <7F9E2B34-6CFD-46A1-ACF4-AF3EC5AF45C6@arin.net> On 19 Jul 2019, at 11:33 AM, Tom Beecher > wrote: If they choose to they could have (in the ARIN region) signed a LRSA, but that's even been removed, in favor of the now much more watered down RSA. I believe ARCD would have been required to sign an LRSA (if they had not previously) in order to transfer the block to Amazon. Also, a question for perhaps John here. Organization: Amazon Technologies Inc. (AT-88-Z) https://www.arin.net/about/corporate/agreements/rsa_faq/#legacy-resource-holder-faq How do I know if my legacy number resources are already covered under an LRSA or not? Typically, any legacy number resources that are covered under an LRSA will be associated with an Organization ID ending in a “-Z”. If you have any questions regarding your legacy resources, please contact ARIN’s Registration Services Department. You may contact the Registration Services Help Desk at +1.703.227.0660 or by submitting an Ask ARIN ticket via your ARIN Online account. Unless there was a clerical error somewhere, is this telling us that 44.192.0.0/10 remains classified as a legacy resource? I didn't think that was possible given that Amazon was not the original assignee. Tom - ARIN doesn’t discuss details of specific registrations publicly; you need to refer any such questions to the registrant. /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Fri Jul 19 15:46:22 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 19 Jul 2019 11:46:22 -0400 Subject: 44/8 In-Reply-To: <7F9E2B34-6CFD-46A1-ACF4-AF3EC5AF45C6@arin.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> <7F9E2B34-6CFD-46A1-ACF4-AF3EC5AF45C6@arin.net> Message-ID: Understood on specifics. But can you comment on the general ARIN policy on the topic? My understanding was that once a legacy resource was transferred , it was permanently removed as a legacy resource. On Fri, Jul 19, 2019 at 11:42 AM John Curran wrote: > On 19 Jul 2019, at 11:33 AM, Tom Beecher wrote: > > > If they choose to they could have (in the ARIN region) signed a LRSA, >> but that's even been removed, in favor >> of the now much more watered down RSA. >> > > I believe ARCD would have been required to sign an LRSA (if they had not > previously) in order to transfer the block to Amazon. > > Also, a question for perhaps John here. > > Organization: Amazon Technologies Inc. (AT-88-Z) >> > > > https://www.arin.net/about/corporate/agreements/rsa_faq/#legacy-resource-holder-faq > > How do I know if my legacy number resources are already covered under an >> LRSA or not? > > Typically, any legacy number resources that are covered under an LRSA will >> be associated with an Organization ID ending in a “-Z”. If you have any >> questions regarding your legacy resources, please contact ARIN’s >> Registration Services Department. You may contact the Registration Services >> Help Desk at +1.703.227.0660 or by submitting an Ask ARIN >> >> ticket via your ARIN Online account. > > > Unless there was a clerical error somewhere, is this telling us that > 44.192.0.0/10 remains classified as a legacy resource? I didn't think > that was possible given that Amazon was not the original assignee. > > > Tom - > > ARIN doesn’t discuss details of specific registrations publicly; you need > to refer any such questions to the registrant. > > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Fri Jul 19 15:50:08 2019 From: matt at netfire.net (Matt Harris) Date: Fri, 19 Jul 2019 10:50:08 -0500 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: On Fri, Jul 19, 2019 at 10:41 AM John Curran wrote: > On 19 Jul 2019, at 11:34 AM, Matt Harris wrote: > > Hey John, I understand that, however my understanding is that the > establishment of an ARIN RSA is required prior to the transfer of a block > or a portion or a block via ARIN (such as the transfer of 44.192/10). Thus, > this would mean that the 44/8 block is now governed by an (well, more than > one, now that it's split) ARIN RSA (or LRSA) whereas it was not before. Is > that not correct? > > > Matt - > > ARIN doesn’t discuss details of specific registrations publicly; you need > to refer any such questions to the registrant. > Without discussing any specific registration whatsoever, my understanding is that what I stated is the case as a matter of policy. Was just looking for confirmation that my reading of ARIN policy docs was not incorrect. :) Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Jul 19 15:52:43 2019 From: jcurran at arin.net (John Curran) Date: Fri, 19 Jul 2019 15:52:43 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> <7F9E2B34-6CFD-46A1-ACF4-AF3EC5AF45C6@arin.net> Message-ID: <1B4FF61B-86B7-40E1-B759-43B40F456274@arin.net> On 19 Jul 2019, at 11:46 AM, Tom Beecher > wrote: Understood on specifics. But can you comment on the general ARIN policy on the topic? My understanding was that once a legacy resource was transferred , it was permanently removed as a legacy resource. As noted earlier, general ARIN policy is as follows - Those who received IPv4 address blocks by InterNIC (or its predecessors) prior to the inception of ARIN on 22 December 1997 are legacy resource holders, and continue to receive those same registry services for those blocks (Whois, reverse DNS, ability to update) without any need for an agreement with ARIN. This has been provided without any fee to the original registrants (or their legal successors) as recognition of their contributions to the early Internet. Some legacy resource holders opt to sign a “legacy registration services agreement” by which ARIN provides specific and well-defined legal rights to the registrant – this is the same RSA as other ARIN customers, but ARIN caps the total annual maintenance fees that are incurred by legacy resource holders. An RSA is also required to receive services that the community has funded the developed since ARIN’s inception, such as resource certification services. Thanks! /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Fri Jul 19 15:54:22 2019 From: beecher at beecher.cc (Tom Beecher) Date: Fri, 19 Jul 2019 11:54:22 -0400 Subject: 44/8 In-Reply-To: <1B4FF61B-86B7-40E1-B759-43B40F456274@arin.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> <7F9E2B34-6CFD-46A1-ACF4-AF3EC5AF45C6@arin.net> <1B4FF61B-86B7-40E1-B759-43B40F456274@arin.net> Message-ID: Good deal. Thanks John, have a great weekend! On Fri, Jul 19, 2019 at 11:52 AM John Curran wrote: > On 19 Jul 2019, at 11:46 AM, Tom Beecher wrote: > > > Understood on specifics. But can you comment on the general ARIN policy on > the topic? My understanding was that once a legacy resource was transferred > , it was permanently removed as a legacy resource. > > > As noted earlier, general ARIN policy is as follows - > > *Those who received IPv4 address blocks by InterNIC (or its predecessors) > prior to the inception of ARIN on 22 December 1997 are legacy resource > holders, and continue to receive those same registry services for those > blocks (Whois, reverse DNS, ability to update) without any need for an > agreement with ARIN. This has been provided without any fee to the > original registrants (or their legal successors) as recognition of their > contributions to the early Internet.* > > *Some legacy resource holders opt to sign a “legacy registration services > agreement” by which ARIN provides specific and well-defined legal rights to > the registrant – this is the same RSA as other ARIN customers, but ARIN > caps the total annual maintenance fees that are incurred by legacy resource > holders. An RSA is also required to receive services that the community > has funded the developed since ARIN’s inception, such as resource > certification services. * > > > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Jul 19 15:55:31 2019 From: jcurran at arin.net (John Curran) Date: Fri, 19 Jul 2019 15:55:31 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: <99BDED6F-1026-43EB-B302-4B6BE15860EA@arin.net> On 19 Jul 2019, at 11:50 AM, Matt Harris > wrote: On Fri, Jul 19, 2019 at 10:41 AM John Curran > wrote: On 19 Jul 2019, at 11:34 AM, Matt Harris > wrote: Hey John, I understand that, however my understanding is that the establishment of an ARIN RSA is required prior to the transfer of a block or a portion or a block via ARIN (such as the transfer of 44.192/10). Thus, this would mean that the 44/8 block is now governed by an (well, more than one, now that it's split) ARIN RSA (or LRSA) whereas it was not before. Is that not correct? Matt - ARIN doesn’t discuss details of specific registrations publicly; you need to refer any such questions to the registrant. Without discussing any specific registration whatsoever, my understanding is that what I stated is the case as a matter of policy. Was just looking for confirmation that my reading of ARIN policy docs was not incorrect. :) Matt - Legacy resource holders may transfer a portion of their number resources without bringing the entire block under a registration services agreement. /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bryan at bryanfields.net Fri Jul 19 16:13:24 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Fri, 19 Jul 2019 12:13:24 -0400 Subject: 44.192.0.0/10 sale In-Reply-To: <20190719150257.GA30984@meow.BKantor.net> References: <20190719150257.GA30984@meow.BKantor.net> Message-ID: <60b87fb9-0aad-2ea8-1fe2-2288de9ef0a6@bryanfields.net> On 7/19/19 11:02 AM, Brian Kantor wrote: > Because questions have arisen here that are well answered by > a short series of postings from the 44net mailing list, at the > request of the author [Phil Karn] and others, I am reposting > them here. > - Brian Brian, You've done fuck all for ARDC for years, actively held back deployment of 44net for the better part of 20 years, and now you orchestrate this backroom deal. You and Phil have proven how corrupt you are. Do the honorable thing and resign. Phil too. For shame. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From jhellenthal at dataix.net Fri Jul 19 16:19:41 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Fri, 19 Jul 2019 11:19:41 -0500 Subject: 44.192.0.0/10 sale In-Reply-To: <60b87fb9-0aad-2ea8-1fe2-2288de9ef0a6@bryanfields.net> References: <20190719150257.GA30984@meow.BKantor.net> <60b87fb9-0aad-2ea8-1fe2-2288de9ef0a6@bryanfields.net> Message-ID: <20190719161941.5EF56513F494@DataIX.net> Well there is a very limited view On Fri, Jul 19, 2019 at 12:13:24PM -0400, Bryan Fields wrote: > On 7/19/19 11:02 AM, Brian Kantor wrote: > > Because questions have arisen here that are well answered by > > a short series of postings from the 44net mailing list, at the > > request of the author [Phil Karn] and others, I am reposting > > them here. > > - Brian > > Brian, > > You've done fuck all for ARDC for years, actively held back deployment of > 44net for the better part of 20 years, and now you orchestrate this backroom > deal. > > You and Phil have proven how corrupt you are. Do the honorable thing and > resign. Phil too. > > For shame. > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 533 bytes Desc: not available URL: From mel at beckman.org Fri Jul 19 16:21:07 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 19 Jul 2019 16:21:07 +0000 Subject: 44.192.0.0/10 sale In-Reply-To: <60b87fb9-0aad-2ea8-1fe2-2288de9ef0a6@bryanfields.net> References: <20190719150257.GA30984@meow.BKantor.net>, <60b87fb9-0aad-2ea8-1fe2-2288de9ef0a6@bryanfields.net> Message-ID: <5ECDF51C-9A95-43F3-9DD7-7E62E1CB180D@beckman.org> Bryan, I appreciate you passing on information about technical background regarding the 44/10 sale, but before this discussion goes any further down a rathole, let me point out tour vitriol is off-topic and doesn’t belong on this list. I for one don’t appreciate you airing amateur radio laundry here. Please take it off-line. -mel via cell > On Jul 19, 2019, at 9:13 AM, Bryan Fields wrote: > >> On 7/19/19 11:02 AM, Brian Kantor wrote: >> Because questions have arisen here that are well answered by >> a short series of postings from the 44net mailing list, at the >> request of the author [Phil Karn] and others, I am reposting >> them here. >> - Brian > > Brian, > > You've done fuck all for ARDC for years, actively held back deployment of > 44net for the better part of 20 years, and now you orchestrate this backroom > deal. > > You and Phil have proven how corrupt you are. Do the honorable thing and > resign. Phil too. > > For shame. > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net From ncariaga at gmail.com Fri Jul 19 16:31:53 2019 From: ncariaga at gmail.com (Nathanael Catangay Cariaga) Date: Sat, 20 Jul 2019 00:31:53 +0800 Subject: Microsoft Outlook Issue Message-ID: This might be an off topic since this is a confirmed issue with Microsoft but I'm just wondering how vast are the affected users on this issue. west coast user here. -nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Fri Jul 19 16:37:58 2019 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 19 Jul 2019 12:37:58 -0400 Subject: Microsoft Outlook Issue In-Reply-To: References: Message-ID: ....What's the issue? On Fri, Jul 19, 2019 at 12:35 PM Nathanael Catangay Cariaga < ncariaga at gmail.com> wrote: > This might be an off topic since this is a confirmed issue with Microsoft > but I'm just wondering how vast are the affected users on this issue. > > west coast user here. > > > -nathan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlists at rivervalleyinternet.net Fri Jul 19 16:40:11 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Fri, 19 Jul 2019 12:40:11 -0400 Subject: 44.192.0.0/10 sale In-Reply-To: <5ECDF51C-9A95-43F3-9DD7-7E62E1CB180D@beckman.org> References: <20190719150257.GA30984@meow.BKantor.net> <60b87fb9-0aad-2ea8-1fe2-2288de9ef0a6@bryanfields.net> <5ECDF51C-9A95-43F3-9DD7-7E62E1CB180D@beckman.org> Message-ID: This discussion has been long, and I believe I've skimmed it -- but if this was already discussed and answered I apologize... The 44/8 block was assigned, if I'm not mistaken, specifically for Amateur Radio use and Brian and all made sure that happened that way. Does not the sale of the block (or partial) violate the original covenants and such set forth. From ncariaga at gmail.com Fri Jul 19 16:41:31 2019 From: ncariaga at gmail.com (Nathanael Catangay Cariaga) Date: Sat, 20 Jul 2019 00:41:31 +0800 Subject: Microsoft Outlook Issue In-Reply-To: References: Message-ID: I got this from the O365 Health Status Page: [image: image.png] On Sat, Jul 20, 2019 at 12:38 AM Ross Tajvar wrote: > ....What's the issue? > > On Fri, Jul 19, 2019 at 12:35 PM Nathanael Catangay Cariaga < > ncariaga at gmail.com> wrote: > >> This might be an off topic since this is a confirmed issue with Microsoft >> but I'm just wondering how vast are the affected users on this issue. >> >> west coast user here. >> >> >> -nathan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncariaga at gmail.com Fri Jul 19 16:50:56 2019 From: ncariaga at gmail.com (Nathanael Catangay Cariaga) Date: Sat, 20 Jul 2019 00:50:56 +0800 Subject: Microsoft Outlook Issue In-Reply-To: References: Message-ID: Taken from MS O365 Health Portal: *Title: Can't access email User Impact: Users may be unable to connect to the Exchange Online service. More info: Other services with dependencies on Exchange Online, such as calendar access through Microsoft Teams, could also be intermittently unavailable. Current status: We're continuing to repair the communication issue between mailbox-hosting infrastructure and components that facilitate access and other users actions. In parallel, we're exploring additional potential mitigation actions to more quickly restore service. Scope of impact: This issue could potentially affect any of your users if they are routed through the affected infrastructure. Start time: Friday, July 19, 2019, at 9:30 AM UTC Root cause: A potential communication issue between service components that host the affected mailboxes and infrastructure that facilitates user connections is affecting access to Exchange Online. Next update by: Friday, July 19, 2019, at 5:30 PM UTC* On Sat, Jul 20, 2019 at 12:38 AM Ross Tajvar wrote: > ....What's the issue? > > On Fri, Jul 19, 2019 at 12:35 PM Nathanael Catangay Cariaga < > ncariaga at gmail.com> wrote: > >> This might be an off topic since this is a confirmed issue with Microsoft >> but I'm just wondering how vast are the affected users on this issue. >> >> west coast user here. >> >> >> -nathan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Fri Jul 19 17:15:05 2019 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 19 Jul 2019 13:15:05 -0400 Subject: Microsoft Outlook Issue In-Reply-To: References: Message-ID: Good to know, but this is probably better suited for the Outages mailing list. On Fri, Jul 19, 2019 at 12:51 PM Nathanael Catangay Cariaga < ncariaga at gmail.com> wrote: > Taken from MS O365 Health Portal: > > *Title: Can't access email User Impact: Users may be unable to connect to > the Exchange Online service. More info: Other services with dependencies on > Exchange Online, such as calendar access through Microsoft Teams, could > also be intermittently unavailable. Current status: We're continuing to > repair the communication issue between mailbox-hosting infrastructure and > components that facilitate access and other users actions. In parallel, > we're exploring additional potential mitigation actions to more quickly > restore service. Scope of impact: This issue could potentially affect any > of your users if they are routed through the affected infrastructure. Start > time: Friday, July 19, 2019, at 9:30 AM UTC Root cause: A potential > communication issue between service components that host the affected > mailboxes and infrastructure that facilitates user connections is affecting > access to Exchange Online. Next update by: Friday, July 19, 2019, at 5:30 > PM UTC* > > On Sat, Jul 20, 2019 at 12:38 AM Ross Tajvar wrote: > >> ....What's the issue? >> >> On Fri, Jul 19, 2019 at 12:35 PM Nathanael Catangay Cariaga < >> ncariaga at gmail.com> wrote: >> >>> This might be an off topic since this is a confirmed issue >>> with Microsoft but I'm just wondering how vast are the affected users on >>> this issue. >>> >>> west coast user here. >>> >>> >>> -nathan >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From karn at philkarn.net Fri Jul 19 17:42:44 2019 From: karn at philkarn.net (Phil Karn) Date: Fri, 19 Jul 2019 10:42:44 -0700 Subject: 44/8 In-Reply-To: <9dcbadc5-b8ba-137b-aef4-a6199c2e2fb8@bryanfields.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> <20190719035015.GC11512@puck.nether.net> <9dcbadc5-b8ba-137b-aef4-a6199c2e2fb8@bryanfields.net> Message-ID: <4298c7cb-aa95-ff33-d57e-528c1bd1a63b@philkarn.net> > And one of the principal people in the network telescope project was > KC, who > also weaseled herself onto the ARDC board without even holding an amateur > radio license.  Conflict of interest here, holy carp. You are not in possession of all the facts. KC (Kim Claffy) is KC6KCC. --Phil From swmike at swm.pp.se Fri Jul 19 18:17:19 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 19 Jul 2019 20:17:19 +0200 (CEST) Subject: 44/8 In-Reply-To: <4298c7cb-aa95-ff33-d57e-528c1bd1a63b@philkarn.net> References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> <20190719035015.GC11512@puck.nether.net> <9dcbadc5-b8ba-137b-aef4-a6199c2e2fb8@bryanfields.net> <4298c7cb-aa95-ff33-d57e-528c1bd1a63b@philkarn.net> Message-ID: On Fri, 19 Jul 2019, Phil Karn wrote: >> And one of the principal people in the network telescope project was >> KC, who also weaseled herself onto the ARDC board without even holding >> an amateur radio license.  Conflict of interest here, holy carp. > > You are not in possession of all the facts. > > KC (Kim Claffy) is KC6KCC. https://www.fccbulletin.com/callsign/?q=KC6KCC The grant date was 2018-02-21. So both of the above statements can be true at the same time since I have no idea when KC joined the ARDC board. When was that? Also, reading: http://wiki.ampr.org/wiki/ARDC "It solely manages and allocates Internet address space, subnets of network 44 (AMPRNet), to interested Amateur Radio operators." Seems ARDC does more than this nowadays. -- Mikael Abrahamsson email: swmike at swm.pp.se From mel at beckman.org Fri Jul 19 18:33:31 2019 From: mel at beckman.org (Mel Beckman) Date: Fri, 19 Jul 2019 18:33:31 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> <20190719035015.GC11512@puck.nether.net> <9dcbadc5-b8ba-137b-aef4-a6199c2e2fb8@bryanfields.net> <4298c7cb-aa95-ff33-d57e-528c1bd1a63b@philkarn.net>, Message-ID: <89D5C474-47AA-4939-A34E-58EAA2B96F90@beckman.org> Please take this off-topic argument off the Nanog list. -mel via cell > On Jul 19, 2019, at 11:17 AM, Mikael Abrahamsson wrote: > > On Fri, 19 Jul 2019, Phil Karn wrote: > >>> And one of the principal people in the network telescope project was KC, who also weaseled herself onto the ARDC board without even holding an amateur radio license. Conflict of interest here, holy carp. >> >> You are not in possession of all the facts. >> >> KC (Kim Claffy) is KC6KCC. > > https://www.fccbulletin.com/callsign/?q=KC6KCC > > The grant date was 2018-02-21. > > So both of the above statements can be true at the same time since I have no idea when KC joined the ARDC board. When was that? > > Also, reading: http://wiki.ampr.org/wiki/ARDC > > "It solely manages and allocates Internet address space, subnets of network 44 (AMPRNet), to interested Amateur Radio operators." > > Seems ARDC does more than this nowadays. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From jlewis at lewis.org Fri Jul 19 18:37:06 2019 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 19 Jul 2019 14:37:06 -0400 (EDT) Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> <20190719035015.GC11512@puck.nether.net> <9dcbadc5-b8ba-137b-aef4-a6199c2e2fb8@bryanfields.net> <4298c7cb-aa95-ff33-d57e-528c1bd1a63b@philkarn.net> Message-ID: On Fri, 19 Jul 2019, Mikael Abrahamsson wrote: > On Fri, 19 Jul 2019, Phil Karn wrote: > >>> And one of the principal people in the network telescope project was KC, >>> who also weaseled herself onto the ARDC board without even holding an >>> amateur radio license.  Conflict of interest here, holy carp. >> >> You are not in possession of all the facts. >> >> KC (Kim Claffy) is KC6KCC. > > https://www.fccbulletin.com/callsign/?q=KC6KCC > > The grant date was 2018-02-21. > > So both of the above statements can be true at the same time since I have no > idea when KC joined the ARDC board. When was that? > > Also, reading: http://wiki.ampr.org/wiki/ARDC > > "It solely manages and allocates Internet address space, subnets of network > 44 (AMPRNet), to interested Amateur Radio operators." > > Seems ARDC does more than this nowadays. Not meaning to pour fuel on the fire...but KC was affiliated with (CFO) ARDC at least as far back as 2015. Do a search for Amateur Radio Digital Communications at https://businesssearch.sos.ca.gov/CBS/Detail Also of interest, ARDC was only incorporated (in CA) in 2011, "anonymously" since the Articles of Incorporation filed with the state in 2011 are signed with no printed name, using an illegible signature. How does an organization incorporated years after 44/8 was set aside for amatuer radio use end up "owning" it enough to have the right to sell a portion of it? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From Bryan at bryanfields.net Fri Jul 19 20:01:22 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Fri, 19 Jul 2019 16:01:22 -0400 Subject: 44/9, 44.128/10 (was 44/8) In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> <20190719035015.GC11512@puck.nether.net> <9dcbadc5-b8ba-137b-aef4-a6199c2e2fb8@bryanfields.net> <4298c7cb-aa95-ff33-d57e-528c1bd1a63b@philkarn.net> Message-ID: <3fd3c7d3-0371-6c30-cdd2-e2a56b53515d@bryanfields.net> On 7/19/19 2:17 PM, Mikael Abrahamsson wrote: > On Fri, 19 Jul 2019, Phil Karn wrote: > >>> And one of the principal people in the network telescope project was >>> KC, who also weaseled herself onto the ARDC board without even holding >>> an amateur radio license.  Conflict of interest here, holy carp. >> >> You are not in possession of all the facts. >> >> KC (Kim Claffy) is KC6KCC. > > https://www.fccbulletin.com/callsign/?q=KC6KCC > > The grant date was 2018-02-21. That is of that callsign, she was KM6PUK before she got KC6KCC, and KM6PUK was granted 01/31/2018, assuming she took the Tech exam with Greater Los Angeles Amateur Radio Group VEC some time before that. > So both of the above statements can be true at the same time since I have > no idea when KC joined the ARDC board. When was that? I was critical of this since at least 2012. John Gilmore was also on the board and was unlicensed at the time. > https://web.archive.org/web/20150505073655/http://www.ampr.org/people.html> https://web.archive.org/web/20160504045206/https://www.ampr.org/about/who-we-are/ This is a moot point as having a valid amateur license is about the lowest bar any board member should have. 90% of this list can take the exam and pass without studying. The bigger question is what have any of the board members done in the time they've been on the board. Certainly not reach out to the users of the resource. There has been no communication from them until now. >From an operational standpoint, RDNS for many subnets is still broken. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From dmitry at deineka.net Fri Jul 19 19:28:42 2019 From: dmitry at deineka.net (Dmitry A.Deineka) Date: Fri, 19 Jul 2019 22:28:42 +0300 Subject: AS3549 NOC contacts? Another BGP hijack Message-ID: Greetings, Unfortunately, ncc at gblx.net is not accepting emails anymore. Someone from AS3549 announced one of our network (more specific route) 46.28.67.0/24. It's not major impact but it's like that at least RIPE whois has outdated contact information about responsive persons. Can someone kindly share contact email of AS3549 (Centurylink?) NOC or other direct contacts? Regards, Dmitry -- Dmitry A.Deineka ITLDC -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikebolitho at gmail.com Fri Jul 19 21:32:44 2019 From: mikebolitho at gmail.com (Mike Bolitho) Date: Fri, 19 Jul 2019 14:32:44 -0700 Subject: AS3549 NOC contacts? Another BGP hijack In-Reply-To: References: Message-ID: NOC is 877-453-8353. That will get you the legacy Global Crossing (Level 3) teams. On Fri, Jul 19, 2019, 2:12 PM Dmitry A.Deineka wrote: > Greetings, > > Unfortunately, ncc at gblx.net is not accepting emails anymore. Someone from > AS3549 announced one of our network (more specific route) 46.28.67.0/24. > > It's not major impact but it's like that at least RIPE whois has outdated > contact information about responsive persons. > > Can someone kindly share contact email of AS3549 (Centurylink?) NOC or > other direct contacts? > > Regards, > Dmitry > > -- > Dmitry A.Deineka > ITLDC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Sat Jul 20 00:51:51 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Sat, 20 Jul 2019 03:51:51 +0300 Subject: Bgpmon alternatives? In-Reply-To: <1c78bd41-a877-5f5f-8bed-3ecfbfa6694d@efes.iucc.ac.il> References: <3b092fdc-7d40-e0e2-9e8c-a8d6d2a361c0@he.net> <20190616094827.GA34940@meow.BKantor.net> <6429449a-e076-b4db-62f0-1eb5fc43454f@he.net> <20190616112050.GA35876@meow.BKantor.net> <67F895A2-1F69-4442-AA0D-7BF415FBA893@as397444.net> <1c78bd41-a877-5f5f-8bed-3ecfbfa6694d@efes.iucc.ac.il> Message-ID: On Thu, Jul 18, 2019 at 12:44 PM Hank Nussbacher wrote: > On 18/07/2019 08:44, Töma Gavrichenkov wrote: > > Qrator guy there. > > Real-time notifications are there but are only available on a > > commercial basis, because basically real time is expensive to compute. > > The rest is free. > > What about once a day notification of BGP hijack? Is that also > expensive to compute? That's in the works, but honestly we see no user demand for that. Either it's real time, or it's not needed. Therefore, it's not a high priority. > I have an account and cannot find any > documentation of realtime notifications nor its cost. All I found was > this - https://qrator.net/en/pricing . Can you send links to the BGP > hijack notification service and its cost? This is basically a noncommercial service, so there's really no price list. Depends on an IP prefix count, but around $500/mo./ASN would be about enough for us to cover our expenses and to afford a couple beers at the end of the month. -- Töma From owen at delong.com Sat Jul 20 01:02:18 2019 From: owen at delong.com (Owen DeLong) Date: Fri, 19 Jul 2019 18:02:18 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: I think there is a key misconception here. The original IANA delegation to “Amateur Radio Digital Communication” was not to any organization with such a name, but was a statement of the purpose of the delegation. An individual who initiated the process took on the administration of the block in trust on behalf of the global amateur radio community. At the time of this allocation, there was only one global IP address registry and no such thing as an RIR. The subsequent formation of an organization by that name and transfer of administrative control into that organization went largely without objection by the amateur radio community because: 1. Most of us probably didn’t even know it happened. 2. Those that did likely expected this organization to continue as previous administrators in trust on behalf of the community. From my perspective, the delegation of a large block to CAIDA for an unrelated purpose now looks like an initial test of “can we get away with this”. I honestly don’t know who is behind ARDC (the organization), but some of the names bandied about are people I know and believe to be deserving of the benefit of the doubt. As such, I’m still trying to learn more before I go full tilt hostile on this, but it seems to me that something is definitely rotten in the state here. Once I have a few more facts (or believe I’m unlikely to be able to get them), I’ll be filing a fraud report with ARIN. I encourage others with any relevant information or knowledge of the history of 44/8 to do the same. Owen > On Jul 19, 2019, at 08:34, Matt Harris wrote: > >> On Fri, Jul 19, 2019 at 10:29 AM John Curran wrote: > >> >> Matt - >> >> Chris is correct. Those who received IPv4 address blocks by InterNIC (or its predecessors) prior to the inception of ARIN on 22 December 1997 are legacy resource holders, and continue to receive those same registry services for those blocks (Whois, reverse DNS, ability to update) without any need for an agreement with ARIN. This has been provided without any fee to the original registrants (or their legal successors) as recognition of their contributions to the early Internet. > > Hey John, I understand that, however my understanding is that the establishment of an ARIN RSA is required prior to the transfer of a block or a portion or a block via ARIN (such as the transfer of 44.192/10). Thus, this would mean that the 44/8 block is now governed by an (well, more than one, now that it's split) ARIN RSA (or LRSA) whereas it was not before. Is that not correct? > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat Jul 20 02:38:09 2019 From: bill at herrin.us (William Herrin) Date: Fri, 19 Jul 2019 19:38:09 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <20190719031324.GA11512@puck.nether.net> <20190719034012.GB11512@puck.nether.net> Message-ID: On Fri, Jul 19, 2019 at 6:02 PM Owen DeLong wrote: > I honestly don’t know who is behind ARDC (the organization), but some of > the names bandied about are people I know and believe to be deserving of > the benefit of the doubt. As such, I’m still trying to learn more before I > go full tilt hostile on this, but it seems to me that something is > definitely rotten in the state here. > Personally I've never heard of ARDC. The name I hear is ARRL, the American Radio Relay League. The name I'll hear when I go to the Hamfest (Ham Radio swap meet) in Chehalis tomorrow morning is ARRL. It's the same name I heard at the big annual meet in Dayton and the smaller hamfests I went to back in Virginia and Maryland. If a /8 was allocated for amateur radio and someone was needed to formally administer it, I'm not clear why it wouldn't happen under the umbrella of ARRL. Their side of the story is at https://www.ampr.org/amprnet/ The nutshell is, "It was our unanimous decision to place one quarter of the AMPRNet address space on the market and to prudently invest the proceeds of that sale in what we hope will be a perpetual endowment." Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cabo at tzi.org Sat Jul 20 02:51:26 2019 From: cabo at tzi.org (Carsten Bormann) Date: Fri, 19 Jul 2019 22:51:26 -0400 Subject: netstat -s In-Reply-To: References: Message-ID: <1CD09B99-B6A9-4C76-B2FA-4FB06164953C@tzi.org> On Jul 17, 2019, at 20:54, Randy Bush wrote: > > do folk use `netstat -s` to help diagnose on routers/switches? I have used netstat -s on hosts to look at error counters if a switch or router was suspect. But that was a while ago (anyone remember when NFS corrupted all your files if one of your routers or the NIC had a bit error outside the protection provided by the Ethernet CRC?). Today, I have the problem that netstat -s doesn’t seem to work right on macOS. Many counter values are nonsensical, or simply zero. I was guessing this was due to NIC offload, but I haven’t analyzed further. If anyone knows more about recent macOS netstat -s, I’d love to hear more details. (Oh, and if there are recent (< 2 years old) statistics of ECT penetration in real networks, I’d love to know, too.) Grüße, Carsten From nanog at radu-adrian.feurdean.net Sat Jul 20 13:01:39 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Sat, 20 Jul 2019 15:01:39 +0200 Subject: netstat -s In-Reply-To: References: Message-ID: <2c176c3f-468c-4783-be5c-245f12bc74b5@www.fastmail.com> On Thu, Jul 18, 2019, at 02:55, Randy Bush wrote: > do folk use `netstat -s` to help diagnose on routers/switches? > > randy Before today, I've never heard on anyone using it on routers/switches. Only on servers. `netstat -s` not very often. `netstat` (all options included) - less ans less often (due to updated tools and data collection methods). Personally, I still consider it a tools to know about. From joelja at bogus.com Sat Jul 20 22:14:22 2019 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 20 Jul 2019 15:14:22 -0700 Subject: netstat -s In-Reply-To: References: Message-ID: On 7/17/19 17:54, Randy Bush wrote: > do folk use `netstat -s` to help diagnose on routers/switches? I suspect there's an unstated question here of should metrics reported by netstat -s  which includes metrics from the kernel should include metrics derived from from the asic counters. I do / have occasionally used netstat or the values exposed to it from the kernel which are generally also exposed via other metrics methods. I would find it a little odd for ip counters in netstat for example to include packets that do not hit the  kernel control plane, though I could imagine someone wanting that. > randy > -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1757 bytes Desc: not available URL: From jared at puck.nether.net Sat Jul 20 22:22:46 2019 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 20 Jul 2019 18:22:46 -0400 Subject: netstat -s In-Reply-To: References: Message-ID: <26EDDFE6-C224-4E55-96E3-BEA3C1A5DD0D@puck.nether.net> > On Jul 20, 2019, at 6:14 PM, Joel Jaeggli wrote: > > On 7/17/19 17:54, Randy Bush wrote: > >> do folk use `netstat -s` to help diagnose on routers/switches? > > I suspect there's an unstated question here of should metrics reported > by netstat -s which includes metrics from the kernel should include > metrics derived from from the asic counters. > > I do / have occasionally used netstat or the values exposed to it from > the kernel which are generally also exposed via other metrics methods. > > I would find it a little odd for ip counters in netstat for example to > include packets that do not hit the kernel control plane, though I > could imagine someone wanting that. Yeah, I avoided jumping in until now, I think the key thing is (and why some people like GUI routers/devices eg: UBNT has a decent http(s) U/I) is a device can have a lot of interfaces and traffic both in the control and data plane that don’t hit a common set of counters/interfaces. When I look at UBNT devices, I can get a sense quickly of traffic rates and information to understand how my network is working. When on a device with 60 or 160 interfaces, it’s much trickier. If I’m on a 16 or 32 port device, a terminal window can tell me decent info, after that I need a summarization system, and this is where streaming telemetry stuff can come into play. That is the aggregation layer for the information vs netstat -s, monitor interface, show | match rate, show | include bits or whatever other commands/data you want/need. XR/JunOS have curses interface monitoring commands that work well, but in most of my cases I really would prefer to have software watch vs a human. “monitor interface” on a Juniper for example doesn’t have separators or human readable elements. I don’t measure my interfaces in bits per seconds these days but in gigs as my base unit and it doesn’t give me common visuals or right justified numbers to delineate if i bumped out an order of magnitude. When I’ve used netstat -s or netstat -i the units often don’t make sense. Similar to other commands like vmstat or similar, what used to be a big number in context switches may not be relevant with 8 cpus each with 8 cores. - Jared From jra at baylink.com Sun Jul 21 04:25:48 2019 From: jra at baylink.com (Jay R. Ashworth) Date: Sun, 21 Jul 2019 04:25:48 +0000 (UTC) Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> Message-ID: <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "William Herrin" > Personally I've never heard of ARDC. Amateur Radio Digital Communications is the name that's been on 44/8 every time I've ever looked at the /8 list, which goes back 2 decades or more. I never assumed it was an organization at the time. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From mehmet at akcin.net Sun Jul 21 07:48:50 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 21 Jul 2019 08:48:50 +0100 Subject: Anycast operators Message-ID: hey there, I am looking to talk to anycast based service operators dns and non-dns service operators to understand how virtualization is used in new generation anycast deployments. if you are running anycast based service (root-servers, tlds, etc.) please contact me offlist. mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sun Jul 21 11:32:19 2019 From: bill at herrin.us (William Herrin) Date: Sun, 21 Jul 2019 04:32:19 -0700 Subject: 44/8 In-Reply-To: <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: On Sat, Jul 20, 2019 at 9:26 PM Jay R. Ashworth wrote: > ----- Original Message ----- > > From: "William Herrin" > > > Personally I've never heard of ARDC. > > Amateur Radio Digital Communications is the name that's been on 44/8 every > time I've ever looked at the /8 list, which goes back 2 decades or more. > > I never assumed it was an organization at the time. > Yeah... It just seems like holding an asset in trust for a population and selling that asset without consulting that population (or at least consulting the organizations the population commonly understands to represent them) is very fishy business. Having read their explanation, I think the folks involved had good reasons and the best intentions but this stinks like fraud to me. Worse, it looks like ARIN was complicit in the fraud -- encouraging and then supporting the folks involved as they established a fiefdom of their own rather than integrating with the organizations that existed. The "appearance of impropriety" is then magnified by ARIN deeming the matter a private transaction between it and the alleged registrants to which the pubic is not entitled to a detailed accounting. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aled.w.morris at googlemail.com Sun Jul 21 11:48:39 2019 From: aled.w.morris at googlemail.com (Aled Morris) Date: Sun, 21 Jul 2019 12:48:39 +0100 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: The biggest tragedy here is that Amazon now have yet another block of IPv4 which means the migration to IPv6 will be further delayed by them and people who "can't see the need" because their AWS server instance can get an IPv4 address. All of this puts more pressure on the access networks to keep IPv4 running and inflates the price of the remaining IPv4 addresses. We need to be pulling together to make https://ipv4flagday.net/ a reality. No more IPv4. Aled On Sun, 21 Jul 2019 at 12:35, William Herrin wrote: > On Sat, Jul 20, 2019 at 9:26 PM Jay R. Ashworth wrote: > >> ----- Original Message ----- >> > From: "William Herrin" >> >> > Personally I've never heard of ARDC. >> >> Amateur Radio Digital Communications is the name that's been on 44/8 >> every >> time I've ever looked at the /8 list, which goes back 2 decades or more. >> >> I never assumed it was an organization at the time. >> > > Yeah... It just seems like holding an asset in trust for a population and > selling that asset without consulting that population (or at least > consulting the organizations the population commonly understands to > represent them) is very fishy business. > > Having read their explanation, I think the folks involved had good reasons > and the best intentions but this stinks like fraud to me. Worse, it looks > like ARIN was complicit in the fraud -- encouraging and then supporting the > folks involved as they established a fiefdom of their own rather than > integrating with the organizations that existed. The "appearance of > impropriety" is then magnified by ARIN deeming the matter a private > transaction between it and the alleged registrants to which the pubic is > not entitled to a detailed accounting. > > Regards, > Bill Herrin > > -- > William Herrin > bill at herrin.us > https://bill.herrin.us/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bryan at bryanfields.net Sun Jul 21 18:39:33 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Sun, 21 Jul 2019 14:39:33 -0400 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: <990f43c0-2451-7b13-ade9-cd363004ffad@bryanfields.net> On 7/21/19 7:32 AM, William Herrin wrote: > Yeah... It just seems like holding an asset in trust for a population and > selling that asset without consulting that population (or at least > consulting the organizations the population commonly understands to > represent them) is very fishy business. This is the major problem, lack of community involvement. It's a world wide resource, but it's use has been hamstrung by the people in charge for years. > Having read their explanation, I think the folks involved had good reasons > and the best intentions but this stinks like fraud to me. Worse, it looks > like ARIN was complicit in the fraud -- encouraging and then supporting the > folks involved as they established a fiefdom of their own rather than > integrating with the organizations that existed. The "appearance of > impropriety" is then magnified by ARIN deeming the matter a private > transaction between it and the alleged registrants to which the pubic is > not entitled to a detailed accounting. You know what they say about good intentions. https://imgflip.com/i/362r0m -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From sabri at cluecentral.net Sun Jul 21 19:28:25 2019 From: sabri at cluecentral.net (Sabri Berisha) Date: Sun, 21 Jul 2019 12:28:25 -0700 (PDT) Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: <1031724380.138665.1563737305128.JavaMail.zimbra@cluecentral.net> ----- On Jul 21, 2019, at 4:48 AM, nanog nanog at nanog.org wrote: Hi, > All of this puts more pressure on the access networks to keep IPv4 running and > inflates the price of the remaining IPv4 addresses. Exactly. Which means that the problem will solve itself. Why is it taking so long to get IPv6 adopted? I'll tell you why: because the cost does not outweigh the benefits at this time. To /you/ they may, but to the average corporate bean counter they don't. Money and resources spent on an IPv6 study and migration project today, will not provide an ROI tomorrow. They will /maybe/ provide a modest ROI in a few years from now, if any. So why would an SVP of Platform Engineering spend his budget on IPv6? Only when it becomes cheaper to go IPv6 than to use legacy V4 will V6 be adopted by large corporations. Well, the ones that are governed by beancounters instead of engineers. And by that time, I'll be charging $500/hr to assist $CORP with their IPv6 migration plans. Thanks, Sabri JNCIE #261 From jcurran at arin.net Mon Jul 22 13:01:47 2019 From: jcurran at arin.net (John Curran) Date: Mon, 22 Jul 2019 13:01:47 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: On 21 Jul 2019, at 7:32 AM, William Herrin wrote: > > Having read their explanation, I think the folks involved had good reasons and the best intentions but this stinks like fraud to me. Worse, it looks like ARIN was complicit in the fraud -- encouraging and then supporting the folks involved as they established a fiefdom of their own rather than integrating with the organizations that existed. Bill - ARIN routinely deals situations where the point of contact for a number resource did not have a formal organization at the time of issuance of the IP address block, and we are quite careful to make sure that the appropriate pedigree is maintained. It is important to realize that ARIN doesn’t automatically consider the responsible contact to be authoritative for an early assignment for any change requested (i.e. an early administrative contact cannot simply usurp an address block for any purpose they desire) but we do indeed recognize organization changes (such as incorporation) that are consistent with the original listed registrant and supported by the current administrative contact for the resource. As you are aware, there are individuals and businesses who operate as a “Doing Business As/DBA" or on behalf on an unincorporated organization at the time of issuance; it is a more common occurrence than one might imagine, and we have to deal with the early registrations appropriately based on the particular circumstance. ARIN promptly put processes in place so that such registrations, having been made on behalf of a particular purpose or organization, do not get misappropriated to become rights solely of the point of contact held for personal gain – indeed, there are cases where organizations are created with similar names for the purposes of hijacking number resources, but such cases don’t generally involve principles who were involved in the administration of the resources since issuance nor do they involve formalization of the registrant into a public benefit not-for-profit organization. Despite your assertions, it is not for ARIN to judge whether a given early number resource was issued to the “best” responsible contact/organization for the job; it is our job to simply maintain the registry according the policies set by the IETF and this community – to do anything else would result in haphazard administration and undermine the stability of the entire registry. > The "appearance of impropriety" is then magnified by ARIN deeming the matter a private transaction between it and the alleged registrants to which the pubic is not entitled to a detailed accounting. As you are aware, Bill, number resource requests to ARIN are private, but the results end up quite visible in the public registry and there is a reporting process if you believe that any change has been made based on fraudulent information. If the folks would like number resource requests (such as transfer requests) to be public when submitted to ARIN, that is also possible, but would require very specific policy directing us accordingly. I do not know if the community would support such a change, but if you are interested in proposing such then you should review for instructions on submission of a policy proposal. Thanks, /John John Curran President and CEO American Registry for Internet Numbers From Anthony.DeLaCruz at CenturyLink.com Mon Jul 22 14:52:10 2019 From: Anthony.DeLaCruz at CenturyLink.com (Delacruz, Anthony B) Date: Mon, 22 Jul 2019 14:52:10 +0000 Subject: AS3549 NOC contacts? Another BGP hijack In-Reply-To: References: Message-ID: <398B250423578A4E97AFE1B8B67C686C65337810@PDDCWMBXEX503.ctl.intranet> Our info is up to date on the whois with ARIN where the issuance is from https://whois.arin.net/rest/asn/AS3549/pft?s=3549 Preferred is ipadmin at centurylink.com From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Bolitho Sent: Friday, July 19, 2019 4:33 PM To: Dmitry A.Deineka Cc: nanog at nanog.org Subject: Re: AS3549 NOC contacts? Another BGP hijack NOC is 877-453-8353. That will get you the legacy Global Crossing (Level 3) teams. On Fri, Jul 19, 2019, 2:12 PM Dmitry A.Deineka > wrote: Greetings, Unfortunately, ncc at gblx.net is not accepting emails anymore. Someone from AS3549 announced one of our network (more specific route) 46.28.67.0/24. It's not major impact but it's like that at least RIPE whois has outdated contact information about responsive persons. Can someone kindly share contact email of AS3549 (Centurylink?) NOC or other direct contacts? Regards, Dmitry -- Dmitry A.Deineka ITLDC This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon Jul 22 17:16:55 2019 From: bill at herrin.us (William Herrin) Date: Mon, 22 Jul 2019 10:16:55 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: On Mon, Jul 22, 2019 at 6:02 AM John Curran wrote: > On 21 Jul 2019, at 7:32 AM, William Herrin wrote: > > Having read their explanation, I think the folks involved had good > > reasons and the best intentions but this stinks like fraud to me. Worse, > > it looks like ARIN was complicit in the fraud -- encouraging and then > > supporting the folks involved as they established a fiefdom of their own > >rather than integrating with the organizations that existed. > > As you are aware, there are individuals and businesses who operate as >a “Doing Business As/DBA" or on behalf on an unincorporated organization >at the time of issuance; it is a more common occurrence than one might imagine, >and we have to deal with the early registrations appropriately based on the >particular circumstance. ARIN promptly put processes in place so that such >registrations, having been made on behalf of a particular purpose or organization, >do not get misappropriated to become rights solely of the point of contact held for >personal gain – indeed, there are cases where organizations are created with >similar names for the purposes of hijacking number resources, but such cases >don’t generally involve principles who were involved in the administration of the >resources since issuance nor do they involve formalization of the registrant into >a public benefit not-for-profit organization. Respectfully John, this wasn't a DBA or an individual figuring the org name field on the old email template couldn't be blank. A class-A was allocated to a _purpose_. You've not only allowed but encouraged that valuable resource to be reassigned to an organization, this ARDC, and then treated the organization as a proxy for the purpose. No one asked you to do that. Nothing in the publicly vetted policies demanded that you attach organizations to the purpose-based allocations and certainly nothing demanded that you grant such organizations identical control over the resources as the control possessed by folks who were the intended direct recipients of assignments. I guess you thought that would avoid having ARIN make judgement calls each time about whether the registrant for a purpose-based allocation was acting in the best interest of the purpose? It doesn't. It just makes ARIN look like a party to fraud. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Mon Jul 22 17:24:30 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 22 Jul 2019 10:24:30 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: <721b9f34-487a-f637-9018-da24a796e533@rollernet.us> On 7/22/19 10:16 AM, William Herrin wrote: > > Respectfully John, this wasn't a DBA or an individual figuring the org > name field on the old email template couldn't be blank. A class-A was > allocated to a _purpose_. You've not only allowed but encouraged that > valuable resource to be reassigned to an organization, this ARDC, and > then treated the organization as a proxy for the purpose. No one asked > you to do that. Nothing in the publicly vetted policies demanded that > you attach organizations to the purpose-based allocations and certainly > nothing demanded that you grant such organizations identical control > over the resources as the control possessed by folks who were the > intended direct recipients of assignments. From the outside it kind of looks like someone created an org that didn't exist before but matched the name in whois and said "oh yeah that's ours, says so right there". From mack1412 at gmail.com Mon Jul 22 02:36:35 2019 From: mack1412 at gmail.com (Mike M) Date: Sun, 21 Jul 2019 22:36:35 -0400 Subject: Contact for Crown Media in California Message-ID: Hi, Looking for a contact number for Crown Media in Studio City, CA. Need access for a technician into that location. Thanks Mike Mackley Crown Castle Fiber -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at theneutral.net Mon Jul 22 11:18:31 2019 From: joe at theneutral.net (Joe Carroll) Date: Mon, 22 Jul 2019 07:18:31 -0400 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: I’ll add to this in saying that I’m a qualified amateur radio licensed Two issues: I’ve been denied access to the space twice. Commercial entities are advertising within the space that are not amateur related. The fish smell permeates.... On Sun, Jul 21, 2019 at 07:34 William Herrin wrote: > On Sat, Jul 20, 2019 at 9:26 PM Jay R. Ashworth wrote: > >> ----- Original Message ----- >> > From: "William Herrin" >> >> > Personally I've never heard of ARDC. >> >> Amateur Radio Digital Communications is the name that's been on 44/8 >> every >> time I've ever looked at the /8 list, which goes back 2 decades or more. >> >> I never assumed it was an organization at the time. >> > > Yeah... It just seems like holding an asset in trust for a population and > selling that asset without consulting that population (or at least > consulting the organizations the population commonly understands to > represent them) is very fishy business. > > Having read their explanation, I think the folks involved had good reasons > and the best intentions but this stinks like fraud to me. Worse, it looks > like ARIN was complicit in the fraud -- encouraging and then supporting the > folks involved as they established a fiefdom of their own rather than > integrating with the organizations that existed. The "appearance of > impropriety" is then magnified by ARIN deeming the matter a private > transaction between it and the alleged registrants to which the pubic is > not entitled to a detailed accounting. > > Regards, > Bill Herrin > > -- > William Herrin > bill at herrin.us > https://bill.herrin.us/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.brant at me.com Mon Jul 22 17:39:49 2019 From: andrew.brant at me.com (andrew.brant) Date: Mon, 22 Jul 2019 12:39:49 -0500 Subject: 44/8 In-Reply-To: Message-ID: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> Whatever happened to the entire class E block? I know it's reserved for future use, but sounds like that future is now given that we've exhausted all existing allocations.Sent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: William Herrin Date: 7/22/19 12:16 PM (GMT-06:00) To: John Curran Cc: North American Network Operators' Group Subject: Re: 44/8 On Mon, Jul 22, 2019 at 6:02 AM John Curran wrote:> On 21 Jul 2019, at 7:32 AM, William Herrin wrote:> > Having read their explanation, I think the folks involved had good > > reasons and the best intentions but this stinks like fraud to me. Worse,> > it looks like ARIN was complicit in the fraud -- encouraging and then > > supporting the folks involved as they established a fiefdom of their own> >rather than integrating with the organizations that existed.>> As you are aware, there are individuals and businesses who operate as>a “Doing Business As/DBA" or on behalf on an unincorporated organization>at the time of issuance; it is a more common occurrence than one might imagine,>and we have to deal with the early registrations appropriately based on the>particular circumstance.   ARIN promptly put processes in place so that such>registrations, having been made on behalf of a particular purpose or organization,>do not get misappropriated to become rights solely of the point of contact held for>personal gain – indeed, there are cases where organizations are created with>similar names for the purposes of hijacking number resources, but such cases>don’t generally involve principles who were involved in the administration of the>resources since issuance nor do they involve formalization of the registrant into>a public benefit not-for-profit organization.Respectfully John, this wasn't a DBA or an individual figuring the org name field on the old email template couldn't be blank. A class-A was allocated to a _purpose_. You've not only allowed but encouraged that valuable resource to be reassigned to an organization, this ARDC, and then treated the organization as a proxy for the purpose. No one asked you to do that. Nothing in the publicly vetted policies demanded that you attach organizations to the purpose-based allocations and certainly nothing demanded that you grant such organizations identical control over the resources as the control possessed by folks who were the intended direct recipients of assignments.I guess you thought that would avoid having ARIN make judgement calls each time about whether the registrant for a purpose-based allocation was acting in the best interest of the purpose? It doesn't. It just makes ARIN look like a party to fraud.Regards,Bill Herrin-- William Herrinbill at herrin.ushttps://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon Jul 22 19:04:49 2019 From: bill at herrin.us (William Herrin) Date: Mon, 22 Jul 2019 12:04:49 -0700 Subject: 44/8 In-Reply-To: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Mon, Jul 22, 2019 at 11:56 AM andrew.brant via NANOG wrote: > Whatever happened to the entire class E block? I know it's reserved for > future use, but sounds like that future is now given that we've exhausted > all existing allocations. > The IPv6 loonies killed all IETF proposals to convert it to unicast space. It remains reserved/unusable. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon Jul 22 19:07:40 2019 From: bill at herrin.us (William Herrin) Date: Mon, 22 Jul 2019 12:07:40 -0700 Subject: 44/8 In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Mon, Jul 22, 2019 at 12:04 PM William Herrin wrote: > On Mon, Jul 22, 2019 at 11:56 AM andrew.brant via NANOG > wrote: > >> Whatever happened to the entire class E block? I know it's reserved for >> future use, but sounds like that future is now given that we've exhausted >> all existing allocations. >> > > The IPv6 loonies killed all IETF proposals to convert it to unicast space. > It remains reserved/unusable. > I should clarify: I see IPv6 advocates and IPv6 loonies. The difference between the advocates and the loonies is that the loonies want to force-fail IPv4 to "encourage" the move to IPv6. -Bill -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Mon Jul 22 19:15:23 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Mon, 22 Jul 2019 19:15:23 +0000 Subject: 44/8 In-Reply-To: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <21bcd8c1664140e8938597439f49d19b@medline.com> I think the Class E block has been covered before. There were two reasons to not re-allocate it. 1. A lot of existing code base does not know how to handle those addresses and may refuse to route them or will otherwise mishandle them. 2. It was decided that squeezing every bit of space out of the v4 allocations only served to delay the desired v6 deployment. This is my recollection and might be flawed. Steven Naslund Chicago IL >Whatever happened to the entire class E block? I know it's reserved for future use, but sounds like that future is now given that we've exhausted all existing >allocations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattlists at rivervalleyinternet.net Mon Jul 22 19:18:40 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Mon, 22 Jul 2019 15:18:40 -0400 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: <2F73EA7C-BEAC-4057-BD96-123D858E4CCA@rivervalleyinternet.net> The agreement in using the space specifically has you agree you were not using it for commercial purposes. Don’t be quick to jump to assumptions, we are an ISP but applied for a/24 so that we could advertise it out because we have a large number of amateur radio repeaters another amateur radio devices on our network. > On Jul 22, 2019, at 7:18 AM, Joe Carroll wrote: > > I’ll add to this in saying that I’m a qualified amateur radio licensed > > Two issues: > > I’ve been denied access to the space twice. > > Commercial entities are advertising within the space that are not amateur related. > > The fish smell permeates.... > >> On Sun, Jul 21, 2019 at 07:34 William Herrin wrote: >>> On Sat, Jul 20, 2019 at 9:26 PM Jay R. Ashworth wrote: >>> ----- Original Message ----- >>> > From: "William Herrin" >>> >>> > Personally I've never heard of ARDC. >>> >>> Amateur Radio Digital Communications is the name that's been on 44/8 every >>> time I've ever looked at the /8 list, which goes back 2 decades or more. >>> >>> I never assumed it was an organization at the time. >> >> Yeah... It just seems like holding an asset in trust for a population and selling that asset without consulting that population (or at least consulting the organizations the population commonly understands to represent them) is very fishy business. >> >> Having read their explanation, I think the folks involved had good reasons and the best intentions but this stinks like fraud to me. Worse, it looks like ARIN was complicit in the fraud -- encouraging and then supporting the folks involved as they established a fiefdom of their own rather than integrating with the organizations that existed. The "appearance of impropriety" is then magnified by ARIN deeming the matter a private transaction between it and the alleged registrants to which the pubic is not entitled to a detailed accounting. >> >> Regards, >> Bill Herrin >> >> -- >> William Herrin >> bill at herrin.us >> https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Jul 22 19:24:08 2019 From: jcurran at arin.net (John Curran) Date: Mon, 22 Jul 2019 19:24:08 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: On 22 Jul 2019, at 1:16 PM, William Herrin wrote: > > Respectfully John, this wasn't a DBA or an individual figuring the org name field on the old email template couldn't be blank. A class-A was allocated to a _purpose_. Bill - The block in question is a /8 research assignment made with a particular network name and a particular responsible technical contact, just as so many other research networks during that period; indeed, if that is what you meant by “purpose”, then you are correct. Like so many of those early research networks, the evolution of the block over time was under control of the contact listed in the registry, and resulted in some being returned, some ending up with commercial firms, some with not-for-profit entities, etc. In the case of AMRPNET, in 2011 ARIN did approve update of the registration to a public benefit not-for-profit at the request of the registered contact. > You've not only allowed but encouraged that valuable resource to be reassigned to an organization, this ARDC, and then treated the organization as a proxy for the purpose. No one asked you to do that. Again, ARIN was specifically requested to do exactly that by the authoritative contact, and it was correct to proceed given that the IP block was a general purpose IP address block absent any other policy guidance. > Nothing in the publicly vetted policies demanded that you attach organizations to the purpose-based allocations You’ve suggested that this network was some special “purpose-based” allocation, but failed to point to any actual policy guidance that distinguishes it in that manner. Note that we do have many such documents that identify a variety of purpose-based allocations – for example, RFC 5737 ("IPv4 Address Blocks Reserved for Documentation”), RFC 6598 for 'Shared Address Space' for CGN, etc. If you do have a IETF or IANA policy document applicable to AMPRNET that somehow has been overlooked, please provide it to ARIN as part of an Internet number resource fraud report, and we will promptly review and investigate. In the meantime, if you are curious about the actual IPv4 special-purpose assignments, you can find the complete list here: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml – there’s quite a few, but AMPRNET is not one of them. Thanks, /John John Curran President and CEO American Registry for Internet Numbers From bill at herrin.us Mon Jul 22 19:35:02 2019 From: bill at herrin.us (William Herrin) Date: Mon, 22 Jul 2019 12:35:02 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: On Mon, Jul 22, 2019 at 12:24 PM John Curran wrote: > > Nothing in the publicly vetted policies demanded that you attach > organizations to the purpose-based allocations > > You’ve suggested that this network was some special “purpose-based” > allocation, but failed to point to any actual policy guidance that > distinguishes it in that manner. John, As admitted at https://www.ampr.org/amprnet/, Hank Magnuski and Jon Postel thought it was a swell idea and simply did it. If you have a different interpretation of that history, one that involves Hank Magnuski and his successors having some kind of ownership of the block independent of its purpose, I'd love to hear it. As I recall, you were specifically asked to provide such an interpretation earlier in this thread but explained that ARIN doesn't comment on individual assignments. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Jul 22 19:47:00 2019 From: jcurran at arin.net (John Curran) Date: Mon, 22 Jul 2019 19:47:00 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: <1F39F2D2-638D-4334-997D-F2DDED6978D3@arin.net> On 22 Jul 2019, at 3:35 PM, William Herrin > wrote: On Mon, Jul 22, 2019 at 12:24 PM John Curran > wrote: > Nothing in the publicly vetted policies demanded that you attach organizations to the purpose-based allocations You’ve suggested that this network was some special “purpose-based” allocation, but failed to point to any actual policy guidance that distinguishes it in that manner. John, As admitted at https://www.ampr.org/amprnet/, Hank Magnuski and Jon Postel thought it was a swell idea and simply did it. Bill - In which case, I’d recommend contacting Hank Magnuski to obtain documentation of your particular interpretation, as there are no published policy documents which indicate anything other than an allocation from the general purpose IPv4 space for an "amateur packet radio" research network (and in particular nothing that would indicate that stewardship over the allocation should rest with any party other than the assigned contact for the block.) Thanks! /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From beecher at beecher.cc Mon Jul 22 20:06:13 2019 From: beecher at beecher.cc (Tom Beecher) Date: Mon, 22 Jul 2019 16:06:13 -0400 Subject: 44/8 In-Reply-To: <1F39F2D2-638D-4334-997D-F2DDED6978D3@arin.net> References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> <1F39F2D2-638D-4334-997D-F2DDED6978D3@arin.net> Message-ID: So wall of text, but here is the RFC chain. Hank Magnuski was the original person marked as the 'reference', which is interpreted as 'responsible individual' in these documents. This changed in 1987, when Philip R. Karn was now reflected in that field. The last RFC I can find that explicitly calls out 44.0.0.0/8 was 1166 , July 1990, again with Phil Karn as the reference, or responsible individual. ========== Original assignment of 44 in RFC 790 : Sept 1981 https://tools.ietf.org/html/rfc790 ... 044.rrr.rrr.rrr AMPRNET Amature Radio Experiment Net [HM] 044.rrr.rrr.rrr-126.rrr.rrr.rrr Unassigned [JBP] ... [HM] Hank Magnuski --- JOSE at PARC-MAXC ========== Ambiguity corrected in RFC 820: https://tools.ietf.org/html/rfc820 ... R 044.rrr.rrr.rrr AMPRNET Amateur Radio Experiment Net[HM] R 045.rrr.rrr.rrr T C3-PR Testbed Development PRNET [BG5] ... [HM] Hank Magnuski --- JOSE at PARC-MAXC ========== Maintains references to "Amateur Radio Experiment Net" through multiple RFCs: 870 900 923 943 960 990 997 ========== Reference field changes from [HM] to [PK28] in RFC 1020 : Nov 1987 https://tools.ietf.org/html/rfc1020 [PK28] Philip R. Karn, Jr. BCR Karn at FLASH.BELLCORE.COM ========== "Amateur Radio Experiment Net" disappears, only AMPRNET listed in RFC 1166 : https://tools.ietf.org/html/rfc1166 ... R*43.rrr.rrr.rrr JAPAN-A [JM292] R 44.rrr.rrr.rrr AMPRNET [PK28] 45.rrr.rrr.rrr Reserved [NIC] ... ========== RFC 1166 Updated by RFC 5737, creation of documentation blocks. No references to 44/8. https://tools.ietf.org/html/rfc5737 ========== On Mon, Jul 22, 2019 at 3:49 PM John Curran wrote: > On 22 Jul 2019, at 3:35 PM, William Herrin wrote: > > > On Mon, Jul 22, 2019 at 12:24 PM John Curran wrote: > >> > Nothing in the publicly vetted policies demanded that you attach >> organizations to the purpose-based allocations >> >> You’ve suggested that this network was some special “purpose-based” >> allocation, but failed to point to any actual policy guidance that >> distinguishes it in that manner. > > > John, > > As admitted at https://www.ampr.org/amprnet/, Hank Magnuski and Jon > Postel thought it was a swell idea and simply did it. > > > Bill - > > In which case, I’d recommend contacting Hank Magnuski to obtain > documentation of your particular interpretation, as there are no published > policy documents which indicate anything other than an allocation from the > general purpose IPv4 space for an "amateur packet radio" research network > (and in particular nothing that would indicate that stewardship over the > allocation should rest with any party other than the assigned contact for > the block.) > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Mon Jul 22 20:17:47 2019 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 22 Jul 2019 13:17:47 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: The change in character/purpose of the network has operational impacts to me, and as such should have been done as an IANA action (as the original purpose was arguably also set by IANA action, when IANA was Jon Postel, and simply not documented very well): I am the network administrator for a 501(c)(3) amateur radio club that operates a digital microwave network licensed via FCC Part 101 (commercial microwave), FCC Part 15 ("unlicensed" ISM) and FCC Part 97 (amateur radio). The Part 97 links are, by law, restricted to amateur radio uses. One way to ensure this is to filter based on the fact that 44.0.0.0/8 is for international amateur radio use only. That has changed as a result of ARIN's consent to a "transfer" to an entity that will not be using these for the originally stated purpose. We have a /23 allocated within 44.0.0.0/8 and it is likely that as we expand we will need additional address space, so the transfer of some of the unallocated space is of concern for that reason as well. What *should* have happened at the time of the formation of ARIN and the other regional registries is that either 1) the 44.0.0.0/8 block have been delegated to a special-purpose RIR incorporated to manage the amateur radio allocations within this block (which is what ampr.org has been doing, but not as an IANA-recognized community-managed RIR); or 2) the 44.0.0.0/8 block have been delegated to another RIR (e.g., ARIN) that could have special policies applicable only to that block and managed by the community. I would guess that in either case, the odds that the community would have decided to peel off 1/4 of the space and sell it to a commercial entity would have been low, and that the odds that IANA would have agreed to go along with such a thing at least as low. Instead we're here, because ARIN treated "Amateur Radio Digital Communications" not as a purpose (that happened to not be documented well via RFC or other process) but as an organization name that anyone could adopt, given sufficient documentation. Despite the fact that the block was already being used in a way that you'd expect an RIR to be behaving, not the way the organization has behaved. Again, I'm sure that this was all well-intentioned... but nobody from ARDC asked any of the hams like me who've been sending TCP/IP over ham radio since it was possible, and have active allocations within the 44 net what we thought about this idea. And nobody from ARIN asked us if we thought ARDC was a suitable proxy for our interests in the special use of the space either when the registration was transferred to the corporation or when the registration stopped being used solely for its original purpose. That's why a real RIR for this space would have had a policy development process where *the community* could weigh in on ideas like "sell of 1/4 of it so we can have a big endowment". Which, heck, we might have all agreed to... if there was some transparency. Matthew Kaufman On Mon, Jul 22, 2019 at 12:26 PM John Curran wrote: > On 22 Jul 2019, at 1:16 PM, William Herrin wrote: > > > > Respectfully John, this wasn't a DBA or an individual figuring the org > name field on the old email template couldn't be blank. A class-A was > allocated to a _purpose_. > > Bill - > > The block in question is a /8 research assignment made with a particular > network name and a particular responsible technical contact, just as so > many other research networks during that period; indeed, if that is what > you meant by “purpose”, then you are correct. Like so many of those early > research networks, the evolution of the block over time was under control > of the contact listed in the registry, and resulted in some being returned, > some ending up with commercial firms, some with not-for-profit entities, > etc. > > In the case of AMRPNET, in 2011 ARIN did approve update of the > registration to a public benefit not-for-profit at the request of the > registered contact. > > > You've not only allowed but encouraged that valuable resource to be > reassigned to an organization, this ARDC, and then treated the organization > as a proxy for the purpose. No one asked you to do that. > > Again, ARIN was specifically requested to do exactly that by the > authoritative contact, and it was correct to proceed given that the IP > block was a general purpose IP address block absent any other policy > guidance. > > > Nothing in the publicly vetted policies demanded that you attach > organizations to the purpose-based allocations > > You’ve suggested that this network was some special “purpose-based” > allocation, but failed to point to any actual policy guidance that > distinguishes it in that manner. Note that we do have many such > documents that identify a variety of purpose-based allocations – for > example, RFC 5737 ("IPv4 Address Blocks Reserved for Documentation”), RFC > 6598 for 'Shared Address Space' for CGN, etc. If you do have a IETF or > IANA policy document applicable to AMPRNET that somehow has been > overlooked, please provide it to ARIN as part of an Internet number > resource fraud report, and we will promptly review and investigate. > > In the meantime, if you are curious about the actual IPv4 special-purpose > assignments, you can find the complete list here: > https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml > – there’s quite a few, but AMPRNET is not one of them. > > Thanks, > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Mon Jul 22 20:22:06 2019 From: randy at psg.com (Randy Bush) Date: Mon, 22 Jul 2019 16:22:06 -0400 Subject: 44/8 Message-ID: my deep sympathies go out to those folk with real work to do whose mail user agents do not have a `delete thread` key sequence. From jcurran at arin.net Mon Jul 22 20:36:40 2019 From: jcurran at arin.net (John Curran) Date: Mon, 22 Jul 2019 20:36:40 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: On 22 Jul 2019, at 4:17 PM, Matthew Kaufman > wrote: The change in character/purpose of the network has operational impacts to me, and as such should have been done as an IANA action (as the original purpose was arguably also set by IANA action, when IANA was Jon Postel, and simply not documented very well): I am the network administrator for a 501(c)(3) amateur radio club that operates a digital microwave network licensed via FCC Part 101 (commercial microwave), FCC Part 15 ("unlicensed" ISM) and FCC Part 97 (amateur radio). The Part 97 links are, by law, restricted to amateur radio uses. One way to ensure this is to filter based on the fact that 44.0.0.0/8 is for international amateur radio use only. That has changed as a result of ARIN's consent to a "transfer" to an entity that will not be using these for the originally stated purpose. We have a /23 allocated within 44.0.0.0/8 and it is likely that as we expand we will need additional address space, so the transfer of some of the unallocated space is of concern for that reason as well. What *should* have happened at the time of the formation of ARIN and the other regional registries is that either 1) the 44.0.0.0/8 block have been delegated to a special-purpose RIR incorporated to manage the amateur radio allocations within this block (which is what ampr.org has been doing, but not as an IANA-recognized community-managed RIR); or 2) the 44.0.0.0/8 block have been delegated to another RIR (e.g., ARIN) that could have special policies applicable only to that block and managed by the community. There is no such creature as a “special purpose” RIR; Regional Internet Registries serve the general community in a particular geographic regions as described by ICANN ICP-2. I would note that ARIN’s original “region” was actually fairly broad (everything not in the RIPE or APNIC regions, just as InterNIC had served), and this included numerous “unusual" allocations to various international projects such as research stations, global airline networks, consortia, and other purposes both of formal legal structure and otherwise. In all cases, the entities successfully administer subassignments based on their own unique policies; it is not necessary for the IANA or an RIR to be involved in such special purpose networks, so long as there is a party appropriately administering the sub assignments for the network on behalf of the particular community. I would guess that in either case, the odds that the community would have decided to peel off 1/4 of the space and sell it to a commercial entity would have been low, and that the odds that IANA would have agreed to go along with such a thing at least as low. Instead we're here, because ARIN treated "Amateur Radio Digital Communications" not as a purpose (that happened to not be documented well via RFC or other process) but as an organization name that anyone could adopt, given sufficient documentation. Despite the fact that the block was already being used in a way that you'd expect an RIR to be behaving, not the way the organization has behaved. Matthew - It is completely incorrect that all it took was "an organization name that anyone could adopt, given sufficient documentation” –≈ the organization name is not sufficient; you need to have the authorized contact for IP address block make such a request – as administration of the block was entrusted to the contact, and the party requesting needs to be the original registrant or their designated successor in a clear chain of authority. Again, I'm sure that this was all well-intentioned... but nobody from ARDC asked any of the hams like me who've been sending TCP/IP over ham radio since it was possible, and have active allocations within the 44 net what we thought about this idea. ... That's why a real RIR for this space would have had a policy development process where *the community* could weigh in on ideas like "sell of 1/4 of it so we can have a big endowment". Which, heck, we might have all agreed to... if there was some transparency. Those are excellent questions for ADCR regarding its governance and accountability plans, but again, none of that requires any special “RIR” magic to accomplish; it simply takes a not-for-profit organization that serves its community – such entities are quite common but they require an active and engaged community and appropriate governance structures. Thanks, /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddunder at gmail.com Mon Jul 22 20:37:18 2019 From: toddunder at gmail.com (Todd Underwood) Date: Mon, 22 Jul 2019 16:37:18 -0400 Subject: 44/8 In-Reply-To: References: Message-ID: silently deleting the thread isn't noise. posting that was, randy. t On Mon, Jul 22, 2019 at 4:23 PM Randy Bush wrote: > my deep sympathies go out to those folk with real work to do whose mail > user agents do not have a `delete thread` key sequence. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Mon Jul 22 20:40:42 2019 From: matt at netfire.net (Matt Harris) Date: Mon, 22 Jul 2019 15:40:42 -0500 Subject: 44/8 In-Reply-To: <1F39F2D2-638D-4334-997D-F2DDED6978D3@arin.net> References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> <1F39F2D2-638D-4334-997D-F2DDED6978D3@arin.net> Message-ID: On Mon, Jul 22, 2019 at 2:47 PM John Curran wrote: > > In which case, I’d recommend contacting Hank Magnuski to obtain > documentation of your particular interpretation, as there are no published > policy documents which indicate anything other than an allocation from the > general purpose IPv4 space for an "amateur packet radio" research network > (and in particular nothing that would indicate that stewardship over the > allocation should rest with any party other than the assigned contact for > the block.) > I would point out here that "stewardship" and "ownership" are two very different things. "Stewardship" refers to the day to day care and feeding of something and generally does not confer the right to dispose of that thing. An example might be amateur radio spectrum. The ARRL is given some degree of stewardship over our spectrum here in the US, which is a community resource issued by the powers that be (globally the ITU, and in the case of the US specifically, the FCC) for those who take the time to get licensed. They can set limitations on its use, but they cannot sell it to Verizon. Thus, the ARRL is a steward of our amateur spectrum, which is not "owned" by any entity but rather is held in trust as a community resource by the FCC which allows for stewardship of that resource by the ARRL. Ownership would, of course, infer the right to dispose of that thing, including by selling it in whole or in part to a third party. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Mon Jul 22 20:44:49 2019 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 22 Jul 2019 13:44:49 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: On Mon, Jul 22, 2019 at 1:36 PM John Curran wrote: > On 22 Jul 2019, at 4:17 PM, Matthew Kaufman wrote: > > ... > > That's why a real RIR for this space would have had a policy development > process where *the community* could weigh in on ideas like "sell of 1/4 of > it so we can have a big endowment". Which, heck, we might have all agreed > to... if there was some transparency. > > > Those are excellent questions for ADCR regarding its governance and > accountability plans, but again, none of that requires any special “RIR” > magic to accomplish; it simply takes a not-for-profit organization that > serves its community – such entities are quite common but they require an > active and engaged community and appropriate governance structures. > > > There's a bit of magic. If ARIN's board of directors decided to up and start taking people's existing IPv4 allocations and selling them to Amazon to beef up the ARIN scholarship fund, the recourse would include going to IANA and noting that ARIN was no longer behaving as a responsible registrar for the global community it serves. Here the amateur radio community has noted that ARDC's board of directors has decided to up and start taking people's existing IPv4 allocations (including a /15 in use by the German amateur radio community) and selling them to Amazon to beef up the ARDC grant fund (without engaging with the global community of radio amateurs who thought that net 44 was being held in trust for them, or engaging with even those entities/individuals who'd already been allocated address space in the block). But because ARDC isn't actually an IP address registrar of global IP space for its community as delegated by IANA, we're left with grasping at ARIN for some accountability here. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at satchell.net Mon Jul 22 20:51:28 2019 From: list at satchell.net (Stephen Satchell) Date: Mon, 22 Jul 2019 13:51:28 -0700 Subject: 44/8 In-Reply-To: <21bcd8c1664140e8938597439f49d19b@medline.com> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> Message-ID: On 7/22/19 12:15 PM, Naslund, Steve wrote: > 1. A lot of existing code base does not know how to handle those > addresses and may refuse to route them or will otherwise mishandle > them. Not to mention all the legacy devices that barely do IPv4 at all, and know nothing about IPv6. Legacy devices that are orphaned by their developing companies going out of busiess or dropping all support for the products. I'm looking at YOU, MasterSwitch. From jcurran at arin.net Mon Jul 22 21:03:38 2019 From: jcurran at arin.net (John Curran) Date: Mon, 22 Jul 2019 21:03:38 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: <0AFD6753-6210-47D0-8914-B60FD0BBBCB8@arin.net> On 22 Jul 2019, at 4:44 PM, Matthew Kaufman wrote: > ... > There's a bit of magic. If ARIN's board of directors decided to up and start taking people's existing IPv4 allocations and selling them to Amazon to beef up the ARIN scholarship fund, the recourse would include going to IANA and noting that ARIN was no longer behaving as a responsible registrar for the global community it serves. Hmm – a rather interesting thought exercise. Rather than belabor the point, I shall simply suggest that in such circumstances you might find yourself far better making use of mechanisms available both in the ARIN bylaws (and under Virginia state law for a non-stock membership organization) to address such a matter, but that’s based on my perhaps imperfect knowledge of the situation... > Here the amateur radio community has noted that ARDC's board of directors has decided to up and start taking people's existing IPv4 allocations (including a /15 in use by the German amateur radio community) and selling them to Amazon to beef up the ARDC grant fund (without engaging with the global community of radio amateurs who thought that net 44 was being held in trust for them, or engaging with even those entities/individuals who'd already been allocated address space in the block). But because ARDC isn't actually an IP address registrar of global IP space for its community as delegated by IANA, we're left with grasping at ARIN for some accountability here. It is both touching (and somewhat disquieting) that you view the RIR system being the only available source of community accountability, but it is not correct – ARDC has significant obligations as non-profit public benefit corporation in order to remain a valid legal entity. I imagine that there is now significantly more engagement between the amateur radio community and that organization, and one hopes it can be positively directed to further digital communication by the amateur radio community. Thanks, /John John Curran President and CEO American Registry for Internet Numbers From fredbaker.ietf at gmail.com Mon Jul 22 22:17:02 2019 From: fredbaker.ietf at gmail.com (Fred Baker) Date: Mon, 22 Jul 2019 18:17:02 -0400 Subject: 44/8 In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> The fundamental reason given, from several sources, was that our experience with IPv4 address trading says that no matter how many IPv4 addresses we create or recover, we won't obviate the need for a replacement protocol. The reasons for that are two: (1) IPv4 isn't forward compatible with anything (if it had a TLV or equivalent for the address, we could have simply extended the address), and (2) 2^32 is a finite number less than the number of addressable entities in the world. Yes, it would be interesting to use Class E as unicast space. The instant we make it possible, it will be bought up by companies and countries desperate to delay their IPv6 deployment - and we will then, once again, be out of IPv4 space. We even had a guy write five internet drafts about how it is possible to enumerate more than 2^n entities with an n bit number. Speaking for myself, I don't see the point. It doesn't solve anything, and I'm not sure it even meaningfully delays anything. The time has come to move to a protocol that allows us to enumerate the set of addressable objects without losing our minds. > On Jul 22, 2019, at 3:04 PM, William Herrin wrote: > > On Mon, Jul 22, 2019 at 11:56 AM andrew.brant via NANOG wrote: > Whatever happened to the entire class E block? I know it's reserved for future use, but sounds like that future is now given that we've exhausted all existing allocations. > > The IPv6 loonies killed all IETF proposals to convert it to unicast space. It remains reserved/unusable. > > Regards, > Bill Herrin > > > -- > William Herrin > bill at herrin.us > https://bill.herrin.us/ From paul at telcodata.us Mon Jul 22 22:33:17 2019 From: paul at telcodata.us (Paul Timmins) Date: Mon, 22 Jul 2019 18:33:17 -0400 Subject: 44/8 In-Reply-To: <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> Message-ID: <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> And after 75 messages, nobody has asked the obvious question. When is ARDC going to acquire IPv6 resources on our behalf? Instead being all worried about legacy resources we're highly underutilizing. Ham Radio is supposed to be about pushing the art forward. Let's do that. -KC8QAY On 7/22/19 6:17 PM, Fred Baker wrote: > The fundamental reason given, from several sources, was that our experience with IPv4 address trading says that no matter how many IPv4 addresses we create or recover, we won't obviate the need for a replacement protocol. The reasons for that are two: (1) IPv4 isn't forward compatible with anything (if it had a TLV or equivalent for the address, we could have simply extended the address), and (2) 2^32 is a finite number less than the number of addressable entities in the world. Yes, it would be interesting to use Class E as unicast space. The instant we make it possible, it will be bought up by companies and countries desperate to delay their IPv6 deployment - and we will then, once again, be out of IPv4 space. > > We even had a guy write five internet drafts about how it is possible to enumerate more than 2^n entities with an n bit number. > > Speaking for myself, I don't see the point. It doesn't solve anything, and I'm not sure it even meaningfully delays anything. The time has come to move to a protocol that allows us to enumerate the set of addressable objects without losing our minds. > >> On Jul 22, 2019, at 3:04 PM, William Herrin wrote: >> >> On Mon, Jul 22, 2019 at 11:56 AM andrew.brant via NANOG wrote: >> Whatever happened to the entire class E block? I know it's reserved for future use, but sounds like that future is now given that we've exhausted all existing allocations. >> >> The IPv6 loonies killed all IETF proposals to convert it to unicast space. It remains reserved/unusable. >> >> Regards, >> Bill Herrin >> >> >> -- >> William Herrin >> bill at herrin.us >> https://bill.herrin.us/ From michel.py at tsisemi.com Mon Jul 22 22:33:42 2019 From: michel.py at tsisemi.com (Michel Py) Date: Mon, 22 Jul 2019 22:33:42 +0000 Subject: 44/8 In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: >> William Herrin wrote : >> The IPv6 loonies killed all IETF proposals to convert it to unicast space. It remains reserved/unusable. +1 > Fred Baker wrote : > Speaking for myself, I don't see the point. It doesn't solve anything, As an extension of RFC1918, it would have solved the questionable and nevertheless widespread squatting of 30/8 and other un-announced DoD blocks because 10/8 is not big enough for some folks. Michel TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From jerry at jtcloe.net Mon Jul 22 23:00:42 2019 From: jerry at jtcloe.net (=?utf-8?Q?Jerry_Cloe?=) Date: Mon, 22 Jul 2019 18:00:42 -0500 Subject: 44/8 In-Reply-To: References: Message-ID: There's already widespread use (abuse ?) of DOD /8's. T-Mobile commonly assigns 26/8 space (and others) to customers and nat's it.   -----Original message----- From:Michel Py Sent:Mon 07-22-2019 05:36 pm Subject:RE: 44/8 To:William Herrin ; CC:North American Network Operators‘ Group ; As an extension of RFC1918, it would have solved the questionable and nevertheless widespread squatting of 30/8 and other un-announced DoD blocks because 10/8 is not big enough for some folks. Michel -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Mon Jul 22 23:12:17 2019 From: cb.list6 at gmail.com (Ca By) Date: Mon, 22 Jul 2019 16:12:17 -0700 Subject: 44/8 In-Reply-To: References: Message-ID: On Mon, Jul 22, 2019 at 4:02 PM Jerry Cloe wrote: > There's already widespread use (abuse ?) of DOD /8's. T-Mobile commonly > assigns 26/8 space (and others) to customers and nat's it. > > My understanding is that is not currently commonly the case https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-MobileUSA.png > > > -----Original message----- > *From:* Michel Py > *Sent:* Mon 07-22-2019 05:36 pm > *Subject:* RE: 44/8 > *To:* William Herrin ; > *CC:* North American Network Operators‘ Group ; > > As an extension of RFC1918, it would have solved the questionable and > nevertheless widespread squatting of 30/8 and other un-announced DoD blocks > because 10/8 is not big enough for some folks. > > Michel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Mon Jul 22 23:27:27 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 22 Jul 2019 16:27:27 -0700 Subject: 44/8 Message-ID: <20190722162727.43D8FC85@m0117164.ppops.net> From:Michel Py As an extension of RFC1918, it would have solved the questionable and nevertheless widespread squatting of 30/8 and other un-announced DoD blocks because 10/8 is not big enough for some folks. --- jerry at jtcloe.net wrote: From: Jerry Cloe There's already widespread use (abuse ?) of DOD /8's. T-Mobile commonly assigns 26/8 space (and others) to customers and nat's it. -------------------------------------------------- I participated in cutting Verizon Hawaii's assets into a standalone network for Hawaiian Telcom in 2005. They used 113/8 all over the place. I worked at HT for 5 years after that, left for nine years and am now back and I am STILL dealing with that crap! scott From surfer at mauigateway.com Mon Jul 22 23:30:58 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 22 Jul 2019 16:30:58 -0700 Subject: 44/8 Message-ID: <20190722163058.43D8FCA5@m0117164.ppops.net> On Mon, Jul 22, 2019 at 4:02 PM Jerry Cloe wrote: > There's already widespread use (abuse ?) of DOD /8's. > T-Mobile commonly assigns 26/8 space (and others) to > customers and nat's it. --- cb.list6 at gmail.com wrote: From: Ca By My understanding is that is not currently commonly the case https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-MobileUSA.png --------------------------------------------------- Did they renumber (IPv4) out of that space? Or are they just not continuing to expand into it? scott From brandon at rd.bbc.co.uk Mon Jul 22 23:58:50 2019 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Tue, 23 Jul 2019 00:58:50 +0100 Subject: 44/8 In-Reply-To: <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> Message-ID: <20190722235850.GA26953@sunf10.rd.bbc.co.uk> On Mon Jul 22, 2019 at 06:33:17PM -0400, Paul Timmins wrote: > And after 75 messages, nobody has asked the obvious question. When is > ARDC going to acquire IPv6 resources on our behalf? Instead being all > worried about legacy resources we're highly underutilizing. I didn't want to spoil a good history dig but did think why not sell the lot. With over 4x as much money it should be able to pay to replace all the legacy kit/software using 44 with stuff doing v6. When the regulator takes spectrum away for others often the others pay the cost of clearing incumbents off. However I've become a v6 idiot as I'd rather we stop dragging this out and get everyone on v6 sooner. Recycling v4 is just time wasting for the convenience of a few rich people and transferring operational problem of scarce v4 onto the less well funded. brandon (G1OZZ and provider of uk 44 gateway through GB7BBC and friends from 1995 to 2006) From michel.py at tsisemi.com Tue Jul 23 00:23:11 2019 From: michel.py at tsisemi.com (Michel Py) Date: Tue, 23 Jul 2019 00:23:11 +0000 Subject: 44/8 In-Reply-To: References: Message-ID: <59f5f318f2394a93b292a942ac1bf27c@CRA114.am.necel.com> >> Michel Py wrote : >> As an extension of RFC1918, it would have solved the questionable and nevertheless widespread squatting of 30/8 and other un-announced DoD blocks because 10/8 is not big enough for some folks. > Jerry Cloe wrote : > There's already widespread use (abuse ?) of DOD /8's. T-Mobile commonly assigns 26/8 space (and others) to customers and nat's it. They are not the only ones; would probably be faster to count who does not squat than who does. Which makes my point : if we had done it 15 years ago and allocated 240/4 as private unicast, these 268 million addresses would have been enough for most to avoid squatting DoD. This is the last attempt that I remember : https://tools.ietf.org/html/draft-wilson-class-e-02 Not problem, because IPv6 is going to be deployed in the next two years, right ? that's what I have been hearing for 20 years now. Michel TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... From cb.list6 at gmail.com Tue Jul 23 00:24:44 2019 From: cb.list6 at gmail.com (Ca By) Date: Mon, 22 Jul 2019 17:24:44 -0700 Subject: 44/8 In-Reply-To: <20190722163058.43D8FCA5@m0117164.ppops.net> References: <20190722163058.43D8FCA5@m0117164.ppops.net> Message-ID: On Mon, Jul 22, 2019 at 4:31 PM Scott Weeks wrote: > > > > On Mon, Jul 22, 2019 at 4:02 PM Jerry Cloe wrote: > > > There's already widespread use (abuse ?) of DOD /8's. > > T-Mobile commonly assigns 26/8 space (and others) to > > customers and nat's it. > > > --- cb.list6 at gmail.com wrote: > From: Ca By > > My understanding is that is not currently commonly the > case > > > https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-MobileUSA.png > --------------------------------------------------- > > > Did they renumber (IPv4) out of that space? Or are they > just not continuing to expand into it? > > scott They stopped using ipv4 assigned for handsets for most cases with 464xlat https://www.internetsociety.org/resources/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/ BT did similar https://www.ipv6.org.uk/wp-content/uploads/2018/11/Nick-Heatley_BT_EE_Update_UKv6Council_201801207.pdf And Telstra https://blog.apnic.net/2017/01/13/telstras-five-year-mobile-ipv6-plan-becomes-reality/ And SK https://blog.apnic.net/2019/06/03/ipv6-deployment-and-challenges-at-sk-telecom/ And Rogers, Telus, and others > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Tue Jul 23 00:39:08 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 22 Jul 2019 17:39:08 -0700 Subject: 44/8 Message-ID: <20190722173908.43D8FEA8@m0117164.ppops.net> > On Mon, Jul 22, 2019 at 4:02 PM Jerry Cloe wrote: > > > There's already widespread use (abuse ?) of DOD /8's. > > T-Mobile commonly assigns 26/8 space (and others) to > > customers and nat's it. > --- cb.list6 at gmail.com wrote: > From: Ca By > > My understanding is that is not currently commonly the > case > https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-MobileUSA.png > --------------------------------------------------- On Mon, Jul 22, 2019 at 4:31 PM Scott Weeks wrote: > Did they renumber (IPv4) out of that space? Or are > they just not continuing to expand into it? --- cb.list6 at gmail.com wrote: From: Ca By They stopped using ipv4 assigned for handsets for most cases with 464xlat -------------------------------------- Ah, OK. I didn't realize they were just using it for handsets. I thought the address space was used elsewhere. When orgs do this the ugliness of squatting sticks to the org seemingly forever like stink on sh!+ scott From valdis.kletnieks at vt.edu Tue Jul 23 00:47:59 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Mon, 22 Jul 2019 20:47:59 -0400 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: <6262.1563842879@turing-police> On Mon, 22 Jul 2019 20:36:40 -0000, John Curran said: > There is no such creature as a ���special purpose��� RIR; Regional Internet > Registries serve the general community in a particular geographic regions as > described by ICANN ICP-2. OK, I'll bite then. Which RIR allocates address space to trans-national interests such as the UN or NATO? Given that Matthew Kaufman states a /15 out of 44/8 was allocated to a German organization, it certainly sounds like we're well into transnational territory here. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From owen at delong.com Tue Jul 23 00:54:13 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Jul 2019 17:54:13 -0700 Subject: 44/8 In-Reply-To: <1031724380.138665.1563737305128.JavaMail.zimbra@cluecentral.net> References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> <1031724380.138665.1563737305128.JavaMail.zimbra@cluecentral.net> Message-ID: > On Jul 21, 2019, at 12:28 , Sabri Berisha wrote: > > ----- On Jul 21, 2019, at 4:48 AM, nanog nanog at nanog.org wrote: > > Hi, > >> All of this puts more pressure on the access networks to keep IPv4 running and >> inflates the price of the remaining IPv4 addresses. > > Exactly. Which means that the problem will solve itself. > > Why is it taking so long to get IPv6 adopted? I'll tell you why: because the cost does not outweigh the benefits at this time. To /you/ they may, but to the average corporate bean counter they don't. Money and resources spent on an IPv6 study and migration project today, will not provide an ROI tomorrow. They will /maybe/ provide a modest ROI in a few years from now, if any. So why would an SVP of Platform Engineering spend his budget on IPv6? > > Only when it becomes cheaper to go IPv6 than to use legacy V4 will V6 be adopted by large corporations. Well, the ones that are governed by beancounters instead of engineers. And by that time, I'll be charging $500/hr to assist $CORP with their IPv6 migration plans. I can guarantee you that Akamai is very much run by beancounters in addition to engineers. I have first hand experience with that. I can also assure you that it’s quite unlikely that any of Comcast, Netflix, Facebook, Google, AT&T, T-Mobile, or Verizon just to name a few of the biggest are managed without due consideration of input from the bean counters. (I’d bet at each of those companies, the day that engineer beats beancounter in a disagreement is rare, indeed). Each and every one of those large companies has deployed IPv6. Some to a greater extent than others. Facebook and T-Mo stand out as the prime examples, having gone all-IPv6 in as much of their network as practicable today. The problem with the approach you are taking to IPv6 cost-benefit analysis is that your claim of no ROI doesn’t actually hold true. The cost savings from a full-on deployment of IPv6 and moving to IPv4 as a service at the edge can be significant. They are hard to capture without very good cost accounting and the problem really tends to be that engineers are lousy cost-accountants and good cost accountants have a hard time understanding what IPv6 brings to the table. It’s also true that some fraction (though now diminishing) of the ROI from a v6 deployment cannot be realized until some other parties also deploy IPv6, but there’s good news on that front, too… More and more of those parties are realizing the need to deploy IPv6. Owen From owen at delong.com Tue Jul 23 01:05:43 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Jul 2019 18:05:43 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: <822B49BC-214D-45AE-979D-BFE0B540F55F@delong.com> > On Jul 22, 2019, at 10:16 , William Herrin wrote: > > On Mon, Jul 22, 2019 at 6:02 AM John Curran > wrote: > > On 21 Jul 2019, at 7:32 AM, William Herrin > wrote: > > > Having read their explanation, I think the folks involved had good > > > reasons and the best intentions but this stinks like fraud to me. Worse, > > > it looks like ARIN was complicit in the fraud -- encouraging and then > > > supporting the folks involved as they established a fiefdom of their own > > >rather than integrating with the organizations that existed. > > > > As you are aware, there are individuals and businesses who operate as > >a “Doing Business As/DBA" or on behalf on an unincorporated organization > >at the time of issuance; it is a more common occurrence than one might imagine, > >and we have to deal with the early registrations appropriately based on the > >particular circumstance. ARIN promptly put processes in place so that such > >registrations, having been made on behalf of a particular purpose or organization, > >do not get misappropriated to become rights solely of the point of contact held for > >personal gain – indeed, there are cases where organizations are created with > >similar names for the purposes of hijacking number resources, but such cases > >don’t generally involve principles who were involved in the administration of the > >resources since issuance nor do they involve formalization of the registrant into > >a public benefit not-for-profit organization. > > Respectfully John, this wasn't a DBA or an individual figuring the org name field on the old email template couldn't be blank. A class-A was allocated to a _purpose_. You've not only allowed but encouraged that valuable resource to be reassigned to an organization, this ARDC, and then treated the organization as a proxy for the purpose. No one asked you to do that. Nothing in the publicly vetted policies demanded that you attach organizations to the purpose-based allocations and certainly nothing demanded that you grant such organizations identical control over the resources as the control possessed by folks who were the intended direct recipients of assignments. This is a rare day, indeed, but I find myself largely agreeing with Bill here. The only thing I dispute here is that I’m pretty sure that the principals of ARDC did request ARIN to make ARDC the controlling organization of the resource. The question here is whether or not it was appropriate or correct for ARIN to do so. IMHO, it was not. IMHO, ARIN should have recognized that this particular block was issued for a purpose and not to an organization or individual. That contacts were volunteers from the community that agreed to take on a task. Even if the block ended up contactless, it should not have been open to claim and certainly not to 8.3 or 8.4 partial transfer to another organization away from that purpose. Unfortunately, the incremental way in which this was done probably rendered ARIN staff into a situation similar to the proverbial (and apocryphal) frog in a pot of water. At each step, it probably seemed on the edge, but still appropriate. This was, of course exacerbated by the fact that the community didn’t really notice anything amiss until this last step, because the individuals in question were, by and large, trusted members of the community that appeared to be continuing to act in the community’s interest. Honestly, I doubt most of the community was aware of (I certainly wasn’t) the incorporation of ARDC and the subsequent transfer of control of 44.0.0.0/8 to ARDC — The Enterprise vs. ARDC — The purpose. Had I been aware of that move at the time, I certainly would have scrutinized the governance process for ARDC and likely cried foul on that basis. That’s where I believe ARIN erred most grievously in this process and that’s where I believe these resources were hijacked to the detriment of the amateur radio community. I have no doubt that the board of ARDC (most of whom i consider friends) believed they were doing the right thing at each and every step. Unfortunately, they fell victim to an insidious form of scope creep and lost track of the fact that this allocation was for a purpose and not for an organization, no matter how well intentioned said organization may be. These addresses should be considered non-transferrable and the transfer should be reversed. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Jul 23 01:09:42 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Jul 2019 18:09:42 -0700 Subject: 44/8 In-Reply-To: <21bcd8c1664140e8938597439f49d19b@medline.com> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> Message-ID: > On Jul 22, 2019, at 12:15 , Naslund, Steve wrote: > > I think the Class E block has been covered before. There were two reasons to not re-allocate it. > > 1. A lot of existing code base does not know how to handle those addresses and may refuse to route them or will otherwise mishandle them. > 2. It was decided that squeezing every bit of space out of the v4 allocations only served to delay the desired v6 deployment. Close, but there is a subtle error… 2. It was decided that the effort to modify each and every IP stack in order to facilitate use of this relatively small block (16 /8s being evaluated against a global run rate at the time of roughly 2.5 /8s per month, mostly to RIPE and APNIC) vs. putting that same effort into modifying each and every IP stack to support IPv6 was an equation of very small benefit for slightly smaller cost. (Less than 8 additional months of IPv4 free pool vs. hopefully making IPv6 deployable before IPv4 ran out). Owen > > This is my recollection and might be flawed. > > Steven Naslund > Chicago IL > > >Whatever happened to the entire class E block? I know it's reserved for future use, but sounds like that future is now given that we've exhausted all existing >allocations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Jul 23 01:18:11 2019 From: jcurran at arin.net (John Curran) Date: Tue, 23 Jul 2019 01:18:11 +0000 Subject: 44/8 In-Reply-To: <6262.1563842879@turing-police> References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> <6262.1563842879@turing-police> Message-ID: <4D1792EF-7A1B-458E-A57A-D9B6569AB3D3@arin.net> On 22 Jul 2019, at 8:47 PM, Valdis Klētnieks wrote: > > On Mon, 22 Jul 2019 20:36:40 -0000, John Curran said: > >> There is no such creature as a “special purpose” RIR; Regional Internet >> Registries serve the general community in a particular geographic regions as >> described by ICANN ICP-2. > > OK, I'll bite then. Which RIR allocates address space to trans-national interests > such as the UN or NATO? Given that Matthew Kaufman states a /15 out of 44/8 > was allocated to a German organization, it certainly sounds like we're well into > transnational territory here. Valdis - International organizations today get IP address blocks generally from the RIR which serves their headquarters location. Prior to ARIN’s inception, international organizations who obtained address blocks often obtained them from the InterNIC (which handled IP address issuance for all parties not in the RIPE or APNIC regions.) ARIN continued to serve these early registrations upon its formation, and most of those registrations were moved to the appropriate RIR in 2002 as part of the "ERX - Early Registration Transfer Project” Hope this helps clarify things somewhat - thanks for asking! /John John Curran President and CEO American Registry for Internet Numbers -------------- 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 sabri at cluecentral.net Tue Jul 23 01:40:46 2019 From: sabri at cluecentral.net (Sabri Berisha) Date: Mon, 22 Jul 2019 18:40:46 -0700 (PDT) Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> <1031724380.138665.1563737305128.JavaMail.zimbra@cluecentral.net> Message-ID: <1047657702.141866.1563846046489.JavaMail.zimbra@cluecentral.net> ----- On Jul 22, 2019, at 5:54 PM, Owen DeLong owen at delong.com wrote: Hi Owen, >> On Jul 21, 2019, at 12:28 , Sabri Berisha wrote: >> Only when it becomes cheaper to go IPv6 than to use legacy V4 will V6 be adopted >> by large corporations. Well, the ones that are governed by beancounters instead >> of engineers. And by that time, I'll be charging $500/hr to assist $CORP with >> their IPv6 migration plans. > > I can guarantee you that Akamai is very much run by beancounters in addition to > engineers. I have first hand experience with that. > > I can also assure you that it’s quite unlikely that any of Comcast, Netflix, > Facebook, Google, AT&T, T-Mobile, or Verizon just to name a few of the biggest > are managed without due consideration of input from the bean counters. (I’d bet > at each of those companies, the day that engineer beats beancounter in a > disagreement is rare, indeed). Sure! Facebook and Google were (are, I can only presume) still dominated by engineers, not beancounters. The other companies you mentioned have little choice; they are consumer ISPs and are faced with a simple truth: IPv6 or a line-item for "IPv4 purchase" on the budget. > The problem with the approach you are taking to IPv6 cost-benefit analysis is > that your claim of no ROI doesn’t actually hold true. It does, it just depends on the organization. And don't get me wrong, you're preaching to the choir here. I am very much in favor of deploying v6. I just have had and still have a hard time getting the resources to do so. As long as the vast majority eyeballs have IPv4, whether via NAT or native, non-subscriber platforms will be able to function. deploying IPv6 is seen as one of the "cool" projects, not a "business critical" one. Facebook and Google were founded at a time where IPv6 was hot and on engineers' radar. Their networks were built from scratch with IPv6 and scalability in mind, and beancounters don't rule those orgs. Here is how I imagine things go at Comcast etc: Comcast Engineer: we need IPv6, will cost $bagsofmoney. Comcast Beancounter: impossible. What's the justification? Comcast Engineer: we will run out of IPv4 and will be unable to add subscribers, and thus grow, and thus increase our marketshare. Comcast Beancounter: approved. Here is how things go in my experience: Content Engineer: we need IPv6, will cost $bagsofmoney. Content Beancounter: impossible. What's the justification? Content Engineer: well, sometime in the future someone will deprecate IPv4 and all eyeballs will only have IPv6. Content Beancounter: when is that going to happen? Content Engineer: I don't know, for now they're using dual stack and all kinds of translation mechanisms. Content Beancounter: come back when it becomes a necessity instead of a luxury. I had that conversation in multiple organizations. According to Google, https://www.google.com/intl/en/ipv6/statistics.html, even today among the eyeballs the adoption rate is a poor 30%. And that graph is not looking like a hockey stick either. It's still very much a chicken and egg problem, in a lot of networks. Unless we come up with a real hard deadline (like we had with y2k), there will always be organizations that won't make the investment. It's either that or wait for a natural tech-refresh, like we've been doing for the last 20 years. Sad, but so far this has been my experience. And again, I wish that things were different. Let's pick 6/6/2026 as IPv4 shutdown day. Thanks, Sabri JNCIE #261 From jcurran at arin.net Tue Jul 23 01:54:45 2019 From: jcurran at arin.net (John Curran) Date: Tue, 23 Jul 2019 01:54:45 +0000 Subject: 44/8 In-Reply-To: <822B49BC-214D-45AE-979D-BFE0B540F55F@delong.com> References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> <822B49BC-214D-45AE-979D-BFE0B540F55F@delong.com> Message-ID: <05BD65C0-4584-4D7D-B8FA-2DF668CF3D32@arin.net> On 22 Jul 2019, at 9:05 PM, Owen DeLong wrote: > ... > The only thing I dispute here is that I’m pretty sure that the principals of ARDC did request ARIN to make ARDC the controlling organization of the resource. The question here is whether or not it was appropriate or correct for ARIN to do so. > > IMHO, it was not. IMHO, ARIN should have recognized that this particular block was issued for a purpose and not to an organization or individual. Owen - All IP address blocks were issued for some purpose, and this includes quite a variety of early networks that were issued for various research purposes. There are also blocks that were issued (or made available via community process) for special purposes; as noted, you can find that registry here - https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml > That contacts were volunteers from the community that agreed to take on a task. Even if the block ended up contactless, it should not have been open to claim and certainly not to 8.3 or 8.4 partial transfer to another organization away from that purpose. > > Unfortunately, the incremental way in which this was done probably rendered ARIN staff into a situation similar to the proverbial (and apocryphal) frog in a pot of water. Not at all. > At each step, it probably seemed on the edge, but still appropriate. This was, of course exacerbated by the fact that the community didn’t really notice anything amiss until this last step, because the individuals in question were, by and large, trusted members of the community that appeared to be continuing to act in the community’s interest. Actually, the change in 2011 to ARDC was perfectly appropriate then, and would be approved if received today – AMPRnet was assigned for Amateur Packet Radio Experimentation (a /8 research assignment) with Hank Magnuski (or his designated successor) to determine how that was to be accomplished. It is presently registered to ARDC, a public benefit not-for-profit whose purposes are “to support, promote, and enhance digital communication and broader communication science and technology, to promote Amateur Radio, scientific research, experimentation, education, development, open access, and innovation in information and communication technology”, and this change was made by a designated successor (Brian Kantor.) You might not like ARDC’s administration due to their apparent lack of engagement with the community, but it remains quite clear that any of the contacts in the lineage of the block could have requested the same update. The change was compliant with the purpose of original issuance, and has been allowed for other projects/activities which similarly formalized their structure over time. > Honestly, I doubt most of the community was aware of (I certainly wasn’t) the incorporation of ARDC and the subsequent transfer of control of 44.0.0.0/8 to ARDC — The Enterprise vs. ARDC — The purpose. Had I been aware of that move at the time, I certainly would have scrutinized the governance process for ARDC and likely cried foul on that basis. That’s where I believe ARIN erred most grievously in this process and that’s where I believe these resources were hijacked to the detriment of the amateur radio community. The resources were registered to a not-for-profit entity of similar purpose per the direction of the authorized contact. In addition to the current contact, the organization’s board also contains those who were the authorized contact for the number block in the past and have contributed heavily to the amateur radio community. If the same request to update the registration were to arrive today, it would be approved, as to do otherwise would require that ARIN unilaterally impose policy constraints on an address block that are neither documented nor are the output of any community process for the definition of a special assignment at the IETF. As for whether the recent transfer of a /10 portion was “to the detriment of the amateur radio community”, that is likely a topic that the amateur radio community should discuss with ARDC, and (as noted earlier) may not be particularly relevant to this mailing list or its subscribers. Thanks, /John John Curran President and CEO American Registry for Internet Numbers From owen at delong.com Tue Jul 23 02:09:02 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Jul 2019 19:09:02 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: <80DC8FCF-DF10-4307-AFB1-852E4601E8A0@delong.com> > On Jul 22, 2019, at 13:36 , John Curran wrote: > > On 22 Jul 2019, at 4:17 PM, Matthew Kaufman > wrote: >> >> The change in character/purpose of the network has operational impacts to me, and as such should have been done as an IANA action (as the original purpose was arguably also set by IANA action, when IANA was Jon Postel, and simply not documented very well): >> >> I am the network administrator for a 501(c)(3) amateur radio club that operates a digital microwave network licensed via FCC Part 101 (commercial microwave), FCC Part 15 ("unlicensed" ISM) and FCC Part 97 (amateur radio). The Part 97 links are, by law, restricted to amateur radio uses. One way to ensure this is to filter based on the fact that 44.0.0.0/8 is for international amateur radio use only. That has changed as a result of ARIN's consent to a "transfer" to an entity that will not be using these for the originally stated purpose. We have a /23 allocated within 44.0.0.0/8 and it is likely that as we expand we will need additional address space, so the transfer of some of the unallocated space is of concern for that reason as well. >> >> What *should* have happened at the time of the formation of ARIN and the other regional registries is that either 1) the 44.0.0.0/8 block have been delegated to a special-purpose RIR incorporated to manage the amateur radio allocations within this block (which is what ampr.org has been doing, but not as an IANA-recognized community-managed RIR); or 2) the 44.0.0.0/8 block have been delegated to another RIR (e.g., ARIN) that could have special policies applicable only to that block and managed by the community. > > There is no such creature as a “special purpose” RIR; Regional Internet Registries serve the general community in a particular geographic regions as described by ICANN ICP-2. > > I would note that ARIN’s original “region” was actually fairly broad (everything not in the RIPE or APNIC regions, just as InterNIC had served), and this included numerous “unusual" allocations to various international projects such as research stations, global airline networks, consortia, and other purposes both of formal legal structure and otherwise. In all cases, the entities successfully administer subassignments based on their own unique policies; it is not necessary for the IANA or an RIR to be involved in such special purpose networks, so long as there is a party appropriately administering the sub assignments for the network on behalf of the particular community. The key word here is “appropriately”. Until a few days ago, (and the reason the prior actions went largely unchallenged/unnoticed), ARDC (the organization, not the purpose) had not yet acted inappropriately in their administration of the sub assignments for the network on behalf of the community. A few days ago, with ARIN complicit in the process, they took an inappropriate action not related to administering the sub assignments (or sub allocations in some cases) on behalf of the community and, instead, disposed of a significant fraction of the resources to enrich one particular organization without significant any vetting of the community in terms of their fitness for that purpose or the community’s willingness to part with said address space. >> I would guess that in either case, the odds that the community would have decided to peel off 1/4 of the space and sell it to a commercial entity would have been low, and that the odds that IANA would have agreed to go along with such a thing at least as low. >> >> Instead we're here, because ARIN treated "Amateur Radio Digital Communications" not as a purpose (that happened to not be documented well via RFC or other process) but as an organization name that anyone could adopt, given sufficient documentation. Despite the fact that the block was already being used in a way that you'd expect an RIR to be behaving, not the way the organization has behaved. > > Matthew - It is completely incorrect that all it took was "an organization name that anyone could adopt, given sufficient documentation” –≈ the organization name is not sufficient; you need to have the authorized contact for IP address block make such a request – as administration of the block was entrusted to the contact, and the party requesting needs to be the original registrant or their designated successor in a clear chain of authority. Yes… It took the conspiracy of those entrusted with the responsible POC status on the block changing the name of the block to match their newly formed organization in order to carry this out. Likely from their perspective it was an effort to clean up the relationship between the AMPRNET and ARIN and until this action, with proper protections in place to prevent this action, I might have even consented to or supported that process. Unfortunately, that process took place largely in secret behind NDAs and other efforts to avoid community scrutiny until it was presented to the community as Faite Accompli. What you are hearing now is a lot of the community in question telling you that this was not the will of the community and that the organization in question had no such mandate from the community it claimed to be serving. >> Again, I'm sure that this was all well-intentioned... but nobody from ARDC asked any of the hams like me who've been sending TCP/IP over ham radio since it was possible, and have active allocations within the 44 net what we thought about this idea. > ... >> That's why a real RIR for this space would have had a policy development process where *the community* could weigh in on ideas like "sell of 1/4 of it so we can have a big endowment". Which, heck, we might have all agreed to... if there was some transparency. > > Those are excellent questions for ADCR regarding its governance and accountability plans, but again, none of that requires any special “RIR” magic to accomplish; it simply takes a not-for-profit organization that serves its community – such entities are quite common but they require an active and engaged community and appropriate governance structures. That would be ARDC, not ADCR, but here’s the problem… As far as most of us are concerned, it was inappropriate for ARIN to hand them control of the block in the first place. We were fine with them doing the record keeping and providing POC services, but we never expected them to be so bold as to simply steal community resources to enrich an organization we never vetted, no matter how well intended. Owen > > > Thanks, > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Jul 23 02:22:48 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Jul 2019 19:22:48 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> Message-ID: <89E2915E-9C38-41CB-8927-DA2E6F18162B@delong.com> > On Jul 22, 2019, at 12:24 , John Curran wrote: > > On 22 Jul 2019, at 1:16 PM, William Herrin wrote: >> >> Respectfully John, this wasn't a DBA or an individual figuring the org name field on the old email template couldn't be blank. A class-A was allocated to a _purpose_. > > Bill - > > The block in question is a /8 research assignment made with a particular network name and a particular responsible technical contact, just as so many other research networks during that period; indeed, if that is what you meant by “purpose”, then you are correct. Like so many of those early research networks, the evolution of the block over time was under control of the contact listed in the registry, and resulted in some being returned, some ending up with commercial firms, some with not-for-profit entities, etc. > > In the case of AMRPNET, in 2011 ARIN did approve update of the registration to a public benefit not-for-profit at the request of the registered contact. > >> You've not only allowed but encouraged that valuable resource to be reassigned to an organization, this ARDC, and then treated the organization as a proxy for the purpose. No one asked you to do that. > > Again, ARIN was specifically requested to do exactly that by the authoritative contact, and it was correct to proceed given that the IP block was a general purpose IP address block absent any other policy guidance. > >> Nothing in the publicly vetted policies demanded that you attach organizations to the purpose-based allocations > > You’ve suggested that this network was some special “purpose-based” allocation, but failed to point to any actual policy guidance that distinguishes it in that manner. Note that we do have many such documents that identify a variety of purpose-based allocations – for example, RFC 5737 ("IPv4 Address Blocks Reserved for Documentation”), RFC 6598 for 'Shared Address Space' for CGN, etc. If you do have a IETF or IANA policy document applicable to AMPRNET that somehow has been overlooked, please provide it to ARIN as part of an Internet number resource fraud report, and we will promptly review and investigate. John, Here’s a decent history of it: https://en.wikipedia.org/wiki/AMPRNet Note that Hank obtained the allocation from Jon in the 1970s and Jon apparently officially recorded it in September 1981, very early in the days of the IANA. This is one of the oldest IP address allocations. The page has already been updated by someone to reflect the transfer in question. I’ve been advised that the part about CAIDA network telescope is somewhat in error. It’s true that CAIDA receives the background traffic that doesn’t have more specifics, but that this is done as part of advertising the full block for purposes of AMPRNET tunnels to those who have legitimate allocations and don’t have their own BGP arrangements for advertising their blocks. Here is a discussion by amateurs of failures in the ability to properly use this block for its intended purpose dating back to 2012: https://www.reddit.com/r/amateurradio/comments/ohi7j/did_you_know_that_there_is_a_classa_16777216/ An early RFC (820) shows it as Amateur Radio Experiment Network and shows HM (Hank Magnuski, KA6M) under the column Reference. (not Administrative or Technical contact, but “Reference”). In the people section, Hank is the only one who doesn’t have an organization code between his name and email, showing only “---“ instead. This is mirrored in RFC900. Also in RFC1020, RFC1062, RFC1117, RFC1166, except that HM has been replaced by PK28 (Phil Karn, KA9Q) in the “Reference” column. Another very good history is here: http://www.jdunman.com/ww/AmateurRadio/Networking/amprnet.htm There is a difference between designation for a purpose and “special use”. You’ll note that each of the “special use” address ranges is for some particular use that is special to the internet, not for some particular research, educational, or other purpose outside of IANA. Nonetheless, the fact remains that from the perspective of amateur radio operators, 44.0.0.0/8 belongs to Amateur Radio in general and Hank and his successors are/were merely stewards without the authority to act outside of the maintenance of the registration in good standing with the IANA or its successor (ARIN in this case). Unfortunately, while I have met Phil (who is complicit in this process), I do not know Hank and am probably unknown to him. I have no idea how to reach him in order to try and get a statement of his intent in obtaining the block and/or his feelings about this transaction. Of course, it would be even harder to get additional information from Jon at this time for obvious reasons. Owen From owen at delong.com Tue Jul 23 02:24:52 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Jul 2019 19:24:52 -0700 Subject: 44/8 In-Reply-To: <0AFD6753-6210-47D0-8914-B60FD0BBBCB8@arin.net> References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> <0AFD6753-6210-47D0-8914-B60FD0BBBCB8@arin.net> Message-ID: <1C0F3B36-9E82-4189-A9EF-8D9CD198804B@delong.com> > On Jul 22, 2019, at 14:03 , John Curran wrote: > > On 22 Jul 2019, at 4:44 PM, Matthew Kaufman wrote: >> ... >> There's a bit of magic. If ARIN's board of directors decided to up and start taking people's existing IPv4 allocations and selling them to Amazon to beef up the ARIN scholarship fund, the recourse would include going to IANA and noting that ARIN was no longer behaving as a responsible registrar for the global community it serves. > > Hmm – a rather interesting thought exercise. Rather than belabor the point, I shall simply suggest that in such circumstances you might find yourself far better making use of mechanisms available both in the ARIN bylaws (and under Virginia state law for a non-stock membership organization) to address such a matter, but that’s based on my perhaps imperfect knowledge of the situation... > >> Here the amateur radio community has noted that ARDC's board of directors has decided to up and start taking people's existing IPv4 allocations (including a /15 in use by the German amateur radio community) and selling them to Amazon to beef up the ARDC grant fund (without engaging with the global community of radio amateurs who thought that net 44 was being held in trust for them, or engaging with even those entities/individuals who'd already been allocated address space in the block). But because ARDC isn't actually an IP address registrar of global IP space for its community as delegated by IANA, we're left with grasping at ARIN for some accountability here. > > > It is both touching (and somewhat disquieting) that you view the RIR system being the only available source of community accountability, but it is not correct – ARDC has significant obligations as non-profit public benefit corporation in order to remain a valid legal entity. I imagine that there is now significantly more engagement between the amateur radio community and that organization, and one hopes it can be positively directed to further digital communication by the amateur radio community. Perhaps, but as I understand it: 1. ARDC cannot undo the transaction. 2. Even if ARDC is forced into non-existence, that does not restore the resources to the Amateur Radio Community. 3. Eliminating ARDC at this point only makes the future of those funds even less likely to serve any valid Amateur Radio Purpose. Thus, ARIN, which runs the registry and does have the ability to invalidate the transaction for fraud upon realizing that ARDC really didn’t have the backing of the community in it’s claim of ownership of the block and the coincidence of the contacts deciding to turn this into a structure they could enrich (and possibly draw a salary from, though I do not know if that is anyone’s intent), and knowing just how to move it through the ARIN process through a rather long game still constitutes a fraudulent misappropriation of the resources in question vs. the community interest in said resources. Owen From owen at delong.com Tue Jul 23 02:39:01 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Jul 2019 19:39:01 -0700 Subject: 44/8 In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <40B0A5D6-5CF7-4E01-8662-BC448F4F71B9@delong.com> > On Jul 22, 2019, at 15:33 , Michel Py wrote: > >>> William Herrin wrote : >>> The IPv6 loonies killed all IETF proposals to convert it to unicast space. It remains reserved/unusable. > > +1 > >> Fred Baker wrote : >> Speaking for myself, I don't see the point. It doesn't solve anything, > > As an extension of RFC1918, it would have solved the questionable and nevertheless widespread squatting of 30/8 and other un-announced DoD blocks because 10/8 is not big enough for some folks. s/would/might/ s/questionable/objectionable to some/ > TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!... Oh, please… You posted it to a public mailing list. TSI’s lawyers need a reality check. Owen From mattlists at rivervalleyinternet.net Tue Jul 23 03:04:07 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Mon, 22 Jul 2019 23:04:07 -0400 Subject: 44/8 In-Reply-To: <40B0A5D6-5CF7-4E01-8662-BC448F4F71B9@delong.com> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <40B0A5D6-5CF7-4E01-8662-BC448F4F71B9@delong.com> Message-ID: So the elephant in the room: now that Precedent has been set - how do I purchase some of the 44 block? :) From swmike at swm.pp.se Tue Jul 23 03:14:52 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 23 Jul 2019 05:14:52 +0200 (CEST) Subject: 240/4 (Re: 44/8) In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> Message-ID: On Mon, 22 Jul 2019, Owen DeLong wrote: > 2. It was decided that the effort to modify each and every IP stack in order to facilitate use of this relatively small block (16 /8s being evaluated against a global > run rate at the time of roughly 2.5 /8s per month, mostly to RIPE and APNIC) vs. putting that same effort into modifying each and every IP stack to support > IPv6 was an equation of very small benefit for slightly smaller cost. (Less than 8 additional months of IPv4 free pool vs. hopefully making IPv6 deployable > before IPv4 ran out). Well, people are working on making 240/4 usable in IP stacks: https://raw.githubusercontent.com/dtaht/unicast-extensions/master/rfcs/draft-gilmore-taht-v4uniext.txt There have been patches accepted into some BSDs and into Linux tools/kernel and other operating systems to make 240/4 configurable and working as unicast space. I don't expect it to show up in DFZ anytime soon, but some people have dilligently been working on removing any obstacles to using 240/4 in most common operating systems. For controlled environments, it's probably deployable today with some caveats. I think it'd be fine as a compliment to RFC1918 space for some internal networks. -- Mikael Abrahamsson email: swmike at swm.pp.se From Bryan at bryanfields.net Tue Jul 23 03:25:45 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Mon, 22 Jul 2019 23:25:45 -0400 Subject: 44/8 RDNS is still broken! In-Reply-To: <80DC8FCF-DF10-4307-AFB1-852E4601E8A0@delong.com> References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> <80DC8FCF-DF10-4307-AFB1-852E4601E8A0@delong.com> Message-ID: <383ac276-42df-79e1-7e37-5c94e0ddec2d@bryanfields.net> On 7/22/19 10:09 PM, Owen DeLong wrote: > That would be ARDC, not ADCR, but here’s the problem… As far as most of us > are concerned, it was inappropriate for ARIN to hand them control of the > block in the first place. We were fine with them doing the record keeping > and providing POC services, but we never expected them to be so bold as to > simply steal community resources to enrich an organization we never vetted, > no matter how well intended. Well here is the rub. ARDC is not technically competent to manage the blocks in the first place. One can see how they bungled the RDNS for 44.0.0.0/9 and 44.128.0.0/10 after the sale causing a world wide 22+ hour outage. Several /16 allocations are still down, over 5 days later due to lame delegation. > $ dig +trace -x 44.25.12.1 > ; <<>> DiG 9.8.3-P1 <<>> +trace -x 44.25.12.1 > ;; global options: +cmd > . 3600000 IN NS J.ROOT-SERVERS.NET. > . 3600000 IN NS E.ROOT-SERVERS.NET. > . 3600000 IN NS G.ROOT-SERVERS.NET. > . 3600000 IN NS F.ROOT-SERVERS.NET. > . 3600000 IN NS A.ROOT-SERVERS.NET. > . 3600000 IN NS K.ROOT-SERVERS.NET. > . 3600000 IN NS B.ROOT-SERVERS.NET. > . 3600000 IN NS D.ROOT-SERVERS.NET. > . 3600000 IN NS M.ROOT-SERVERS.NET. > . 3600000 IN NS L.ROOT-SERVERS.NET. > . 3600000 IN NS C.ROOT-SERVERS.NET. > . 3600000 IN NS I.ROOT-SERVERS.NET. > . 3600000 IN NS H.ROOT-SERVERS.NET. > ;; Received 492 bytes from 192.168.8.200#53(192.168.8.200) in 1454 ms > > in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa. > in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa. > ;; Received 417 bytes from 2001:7fd::1#53(2001:7fd::1) in 1837 ms > > 44.in-addr.arpa. 86400 IN NS x.arin.net. > 44.in-addr.arpa. 86400 IN NS z.arin.net. > 44.in-addr.arpa. 86400 IN NS r.arin.net. > ;; Received 112 bytes from 2001:dd8:6::101#53(2001:dd8:6::101) in 839 ms > > 25.44.in-addr.arpa. 86400 IN NS ampr.org. > 25.44.in-addr.arpa. 86400 IN NS a.coreservers.uk. > 25.44.in-addr.arpa. 86400 IN NS munnari.oz.au. > 25.44.in-addr.arpa. 86400 IN NS ampr-dns.in-berlin.de. > 25.44.in-addr.arpa. 86400 IN NS ns2.threshinc.com. > ;; Received 186 bytes from 2001:500:13::63#53(2001:500:13::63) in 5508 ms > > 25.44.in-addr.arpa. 3600 IN NS c.ns.hamwan.net. > 25.44.in-addr.arpa. 3600 IN NS b.ns.hamwan.net. > 25.44.in-addr.arpa. 3600 IN NS a.ns.hamwan.net. > ;; BAD (HORIZONTAL) REFERRAL > ;; Received 102 bytes from 2a00:ed40:4001:1::10#53(2a00:ed40:4001:1::10) in 579 ms > > 1.12.25.44.in-addr.arpa. 3600 IN PTR loopback0.r1.triangle.hamwan.net. > ;; Received 87 bytes from 44.24.245.2#53(44.24.245.2) in 99 ms Someone, anyone, want to get this fixed? The road to hell is paved in good intentions. Hey mama, look at me, I'm on my way to the promised land, whoo! -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From owen at delong.com Tue Jul 23 03:45:06 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Jul 2019 20:45:06 -0700 Subject: 44/8 In-Reply-To: <05BD65C0-4584-4D7D-B8FA-2DF668CF3D32@arin.net> References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> <822B49BC-214D-45AE-979D-BFE0B540F55F@delong.com> <05BD65C0-4584-4D7D-B8FA-2DF668CF3D32@arin.net> Message-ID: <4E9EC27D-BFF0-4843-8E45-1C88B1475E69@delong.com> > On Jul 22, 2019, at 18:54 , John Curran wrote: > > On 22 Jul 2019, at 9:05 PM, Owen DeLong wrote: >> ... >> The only thing I dispute here is that I’m pretty sure that the principals of ARDC did request ARIN to make ARDC the controlling organization of the resource. The question here is whether or not it was appropriate or correct for ARIN to do so. >> >> IMHO, it was not. IMHO, ARIN should have recognized that this particular block was issued for a purpose and not to an organization or individual. > > Owen - > > All IP address blocks were issued for some purpose, and this includes quite a variety of early networks that were issued for various research purposes. There are also blocks that were issued (or made available via community process) for special purposes; as noted, you can find that registry here - https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml All address blocks were issued for some purpose, but most were issued TO individuals or organizations FOR that purpose. In the case of 44.0.0.0/8, it was arguably issued TO the purpose as well as FOR the purpose and the “Reference” contact was just the person currently serving as POC for the address space, not an “owner” of the registration record. > >> That contacts were volunteers from the community that agreed to take on a task. Even if the block ended up contactless, it should not have been open to claim and certainly not to 8.3 or 8.4 partial transfer to another organization away from that purpose. >> >> Unfortunately, the incremental way in which this was done probably rendered ARIN staff into a situation similar to the proverbial (and apocryphal) frog in a pot of water. > > Not at all. Oh? Do tell… > >> At each step, it probably seemed on the edge, but still appropriate. This was, of course exacerbated by the fact that the community didn’t really notice anything amiss until this last step, because the individuals in question were, by and large, trusted members of the community that appeared to be continuing to act in the community’s interest. > > Actually, the change in 2011 to ARDC was perfectly appropriate then, and would be approved if received today – No doubt… > AMPRnet was assigned for Amateur Packet Radio Experimentation (a /8 research assignment) with Hank Magnuski (or his designated successor) to determine how that was to be accomplished. It is presently registered to ARDC, a public benefit not-for-profit whose purposes are “to support, promote, and enhance digital communication and broader communication science and technology, to promote Amateur Radio, scientific research, experimentation, education, development, open access, and innovation in information and communication technology”, and this change was made by a designated successor (Brian Kantor.) I’m aware. > You might not like ARDC’s administration due to their apparent lack of engagement with the community, but it remains quite clear that any of the contacts in the lineage of the block could have requested the same update. > The change was compliant with the purpose of original issuance, and has been allowed for other projects/activities which similarly formalized their structure over time. I admit there’s a valid case for this particular change. This particular change is the cold water stage of the above analogy. >> Honestly, I doubt most of the community was aware of (I certainly wasn’t) the incorporation of ARDC and the subsequent transfer of control of 44.0.0.0/8 to ARDC — The Enterprise vs. ARDC — The purpose. Had I been aware of that move at the time, I certainly would have scrutinized the governance process for ARDC and likely cried foul on that basis. That’s where I believe ARIN erred most grievously in this process and that’s where I believe these resources were hijacked to the detriment of the amateur radio community. > > The resources were registered to a not-for-profit entity of similar purpose per the direction of the authorized contact. In addition to the current contact, the organization’s board also contains those who were the authorized contact for the number block in the past and have contributed heavily to the amateur radio community. If the same request to update the registration were to arrive today, it would be approved, as to do otherwise would require that ARIN unilaterally impose policy constraints on an address block that are neither documented nor are the output of any community process for the definition of a special assignment at the IETF. > > As for whether the recent transfer of a /10 portion was “to the detriment of the amateur radio community”, that is likely a topic that the amateur radio community should discuss with ARDC, and (as noted earlier) may not be particularly relevant to this mailing list or its subscribers. There seem to be a good many participants besides just myself who consider it relevant. Owen From owen at delong.com Tue Jul 23 03:48:23 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Jul 2019 20:48:23 -0700 Subject: 240/4 (Re: 44/8) In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> Message-ID: <063A66E3-EF32-40DC-B181-9F44A329443C@delong.com> > On Jul 22, 2019, at 20:14 , Mikael Abrahamsson wrote: > > On Mon, 22 Jul 2019, Owen DeLong wrote: > >> 2. It was decided that the effort to modify each and every IP stack in order to facilitate use of this relatively small block (16 /8s being evaluated against a global >> run rate at the time of roughly 2.5 /8s per month, mostly to RIPE and APNIC) vs. putting that same effort into modifying each and every IP stack to support >> IPv6 was an equation of very small benefit for slightly smaller cost. (Less than 8 additional months of IPv4 free pool vs. hopefully making IPv6 deployable >> before IPv4 ran out). > > Well, people are working on making 240/4 usable in IP stacks: > > https://raw.githubusercontent.com/dtaht/unicast-extensions/master/rfcs/draft-gilmore-taht-v4uniext.txt > > There have been patches accepted into some BSDs and into Linux tools/kernel and other operating systems to make 240/4 configurable and working as unicast space. > > I don't expect it to show up in DFZ anytime soon, but some people have dilligently been working on removing any obstacles to using 240/4 in most common operating systems. > > For controlled environments, it's probably deployable today with some caveats. I think it'd be fine as a compliment to RFC1918 space for some internal networks. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se I guess people can do whatever they want. I personally consider it to be a sad sad waste of time that could be better spent deploying IPv6 to more places. Owen From george.herbert at gmail.com Tue Jul 23 04:02:07 2019 From: george.herbert at gmail.com (George Herbert) Date: Mon, 22 Jul 2019 21:02:07 -0700 Subject: 240/4 (Re: 44/8) In-Reply-To: <063A66E3-EF32-40DC-B181-9F44A329443C@delong.com> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> <063A66E3-EF32-40DC-B181-9F44A329443C@delong.com> Message-ID: Most importantly, if you're running out of 1918 space is a totally different problem than running out of global routable space. If you patch common OSes for 240/4 usability but a significant fraction of say unpatched OSes, IOT, consumer routers, old random net cruft necessary for infrastructure aren't patched... it's not actually globally routable. At some point you can write off the few stragglers but... really, get IPv6 everywhere. On Mon, Jul 22, 2019 at 8:50 PM Owen DeLong wrote: > > > > On Jul 22, 2019, at 20:14 , Mikael Abrahamsson wrote: > > > > On Mon, 22 Jul 2019, Owen DeLong wrote: > > > >> 2. It was decided that the effort to modify each and every IP > stack in order to facilitate use of this relatively small block (16 /8s > being evaluated against a global > >> run rate at the time of roughly 2.5 /8s per month, mostly > to RIPE and APNIC) vs. putting that same effort into modifying each and > every IP stack to support > >> IPv6 was an equation of very small benefit for slightly > smaller cost. (Less than 8 additional months of IPv4 free pool vs. > hopefully making IPv6 deployable > >> before IPv4 ran out). > > > > Well, people are working on making 240/4 usable in IP stacks: > > > > > https://raw.githubusercontent.com/dtaht/unicast-extensions/master/rfcs/draft-gilmore-taht-v4uniext.txt > > > > There have been patches accepted into some BSDs and into Linux > tools/kernel and other operating systems to make 240/4 configurable and > working as unicast space. > > > > I don't expect it to show up in DFZ anytime soon, but some people have > dilligently been working on removing any obstacles to using 240/4 in most > common operating systems. > > > > For controlled environments, it's probably deployable today with some > caveats. I think it'd be fine as a compliment to RFC1918 space for some > internal networks. > > > > -- > > Mikael Abrahamsson email: swmike at swm.pp.se > > I guess people can do whatever they want. I personally consider it to be a > sad sad waste of time that could be better spent deploying IPv6 to more > places. > > Owen > > -- -george william herbert george.herbert at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Tue Jul 23 04:15:44 2019 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 23 Jul 2019 00:15:44 -0400 Subject: 240/4 (Re: 44/8) In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> Message-ID: > Editor's note: This draft has not been submitted to any formal > process. It may change significantly if it is ever submitted. > You are reading it because we trust you and we value your > opinions. *Please do not recirculate it.* Please join us in > testing patches and equipment! (emphasis mine) Interesting choice to host it in a public Github repo, then... On Mon, Jul 22, 2019 at 11:17 PM Mikael Abrahamsson wrote: > On Mon, 22 Jul 2019, Owen DeLong wrote: > > > 2. It was decided that the effort to modify each and every IP > stack in order to facilitate use of this relatively small block (16 /8s > being evaluated against a global > > run rate at the time of roughly 2.5 /8s per month, mostly > to RIPE and APNIC) vs. putting that same effort into modifying each and > every IP stack to support > > IPv6 was an equation of very small benefit for slightly > smaller cost. (Less than 8 additional months of IPv4 free pool vs. > hopefully making IPv6 deployable > > before IPv4 ran out). > > Well, people are working on making 240/4 usable in IP stacks: > > > https://raw.githubusercontent.com/dtaht/unicast-extensions/master/rfcs/draft-gilmore-taht-v4uniext.txt > > There have been patches accepted into some BSDs and into Linux > tools/kernel and other operating systems to make 240/4 configurable and > working as unicast space. > > I don't expect it to show up in DFZ anytime soon, but some people have > dilligently been working on removing any obstacles to using 240/4 in most > common operating systems. > > For controlled environments, it's probably deployable today with some > caveats. I think it'd be fine as a compliment to RFC1918 space for some > internal networks. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Tue Jul 23 04:29:14 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 23 Jul 2019 00:29:14 -0400 (EDT) Subject: FCC: 2019 CSRIC Working Groups Announced - Volunteers? Message-ID: The 2019 FCC Communications Security Reliability and Interoperability Council (CSRIC) has announced their new working groups for the new cycle. CSRIC is seeking volunteers to serve on various working groups. https://docs.fcc.gov/public/attachments/DA-19-689A1.pdf Working Group 1: Alert Originator Standard Operating Procedures Chair: Craig Fugate, America’s Public Television Stations Working Group 2: Managing Security Risk in the Transition to 5G Chair: Lee Thibaudeau, Nsight. Working Group 3: Managing Security Risk in Emerging 5G Implementations Chair: Farrokh Khatibi, Qualcomm Working Group 4: 911 Security Vulnerabilities During the IP Transition Chair: Mary A. Boyd, West Safety Services Working Group 5: Improving Broadcast Resiliency Chair: Pat Roberts, Florida Association of Broadcasters Working Group 6: SIP Security Vulnerabilities Chair: Danny McPherson, Verisign From SNaslund at medline.com Tue Jul 23 14:31:50 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 23 Jul 2019 14:31:50 +0000 Subject: 44/8 In-Reply-To: <822B49BC-214D-45AE-979D-BFE0B540F55F@delong.com> References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> <822B49BC-214D-45AE-979D-BFE0B540F55F@delong.com> Message-ID: <02148adc7cfe4952ac1a3c800a3cdd24@medline.com> In defense of John and ARIN, if you did not recognize that ARDC represented an authority for this resource, who would be? The complaints would have been even more shrill if ARIN took it upon themselves to “represent” the amateur radio community and had denied the request or re-allocated the assignment. IANA would have been just as out of line making decisions for the community. In my opinion the community is at fault for not recognizing the value of their assigned resource and putting mechanisms in place for its management (or maybe just not understanding the power that the ARDC represented). At the end of the day, someone has to represent an authority for an assignment and ARDC was as close as you could get. About the closest other organization would have been someone like the ARRL but even then you have a US organization representing a worldwide loosely coupled community. I suppose there is a UN basis for worldwide management but does anyone here think that any UN organization would be a trustworthy administrator. I think the decision to sell off some of the block makes sense given the size and current usage. After all, by definition amateur radio is about advancing the state of the art and experimenting, v6 allocations are not scarce at all. The problem here is that the amateur radio community does appear to think they were well represented by the ARDC which I would have to say is their fault. The original allocation was made a long time ago when there was so much space that it had no real value. What everyone seems to be bent out of shape about is that there was a value to this block and someone got paid for it. This does not seem to put the community in peril of running out of space. How you share in the dividends of this sale is another unsolvable problem. How do you allocate this dividend to a worldwide community with no centralized membership database? The original assignment of this block seems to have been a couple of people with an idea that was forward looking. The fact that the authority for something like that was somewhat murky is not at all surprising. In general, a lot of older assignments become clouded and disputable through numerous acquisitions and changes in control especially at a time that those assignment were not seen as having real value. ARIN is in a sticky position here no matter what call they make. I don’t envy John’s job in the least ☺ Steven Naslund Chicago IL >Respectfully John, this wasn't a DBA or an individual figuring the org name field on the old email template couldn't be blank. A class-A was >allocated to a _purpose_. You've not only allowed but encouraged that valuable resource to be reassigned to an organization, this ARDC, and then >treated the organization as a proxy for the purpose. No one asked you to do that. Nothing in the publicly vetted policies demanded that you attach >organizations to the purpose-based allocations and certainly nothing demanded that you grant such organizations identical control over the >resources as the control possessed by folks who were the intended direct recipients of assignments. > >This is a rare day, indeed, but I find myself largely agreeing with Bill here. > >The only thing I dispute here is that I’m pretty sure that the principals of ARDC did request ARIN to make ARDC the controlling organization of the resource. >The question here is whether or not it was appropriate or correct for ARIN to do so. > >IMHO, it was not. IMHO, ARIN should have recognized that this particular block was issued for a purpose and not to an organization or individual. That contacts >were volunteers from the community that agreed to take on a task. Even if the block ended up contactless, it should not have been open to claim and certainly not >to 8.3 or 8.4 partial transfer to another organization away from that purpose. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Tue Jul 23 14:47:34 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 23 Jul 2019 14:47:34 +0000 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> <1031724380.138665.1563737305128.JavaMail.zimbra@cluecentral.net> Message-ID: <0856c8d3541941f9995ab2df858ca249@medline.com> >I can guarantee you that Akamai is very much run by beancounters in addition to engineers. I have first hand experience with that. > >I can also assure you that it’s quite unlikely that any of Comcast, Netflix, Facebook, Google, AT&T, T-Mobile, or Verizon just to name a few of the biggest are managed without >due consideration of input from the bean counters. (I’d bet at each of those companies, the day that engineer beats beancounter in a disagreement is rare, indeed). > >Each and every one of those large companies has deployed IPv6. Some to a greater extent than others. Facebook and T-Mo stand out as the prime examples, having gone all->IPv6 in as much of their network as practicable today. > >The problem with the approach you are taking to IPv6 cost-benefit analysis is that your claim of no ROI doesn’t actually hold true. > >The cost savings from a full-on deployment of IPv6 and moving to IPv4 as a service at the edge can be significant. They are hard to capture without very good cost accounting >and the problem really tends to be that engineers are lousy cost-accountants and good cost accountants have a hard time understanding what IPv6 brings to the table. > >It’s also true that some fraction (though now diminishing) of the ROI from a v6 deployment cannot be realized until some other parties also deploy IPv6, but there’s good news >on that front, too… More and more of those parties are realizing the need to deploy IPv6. > >Owen The common denominator for all of the companies listed is the size of their deployment. The carriers needed to handle very large scale mobile networks that they could not possibly get a large enough allocation for. The alternative CGN gear would have doubtless been extremely expensive as well. They also have the engineering and financial horsepower to hold their suppliers to the fire to make all of the devices together well with v6. Another advantage they have is that the lifespan of a mobile device and it's infrastructure is pretty short so they are not dealing with a lot of legacy devices. It helped a lot that the v4 allocations were drying up at around the same time that the mobile networks were in full upgrade mode deploying 4G and LTE. Facebook, Google, and Netflix deployed v6 mostly because there were so many mobile devices using it that it could not be ignored. These are all market/financial forces at work, not some pioneering engineering drive. In the corporate world we have to provide a reason to spend money so unless there is a business drive to deploy v6, it's not going to happen. That pressure is mounting but not at a breaking point yet. The two main pressures would be the cost of expanding into more v4 space and what your customers want. The move to cloud based services means that the corporate demand for v4 space is actually decreasing since they are not hosting as many Internet facing applications as they once were. They don't need to move to v6 since their cloud providers are doing it for them. There is also a move in a lot of corporate networks to get away from dedicated circuits and use the Internet as transport. As this happens, the corporate network does not even care that the service provider is using v6 transport to carry a tunnel. V4 vs v6 becomes a non-issue over time and the pressure to change everything over to v6 goes away since the v4 space is not growing. Steven Naslund Chicago IL From SNaslund at medline.com Tue Jul 23 14:56:16 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 23 Jul 2019 14:56:16 +0000 Subject: 44/8 In-Reply-To: <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> Message-ID: How about this? If you guys think your organization (club, group of friends, neighborhood association, whatever...) got screwed over by the ARDC, then why not apply for your own v6 allocation. You would then have complete control over its handling and never have to worry about it again. If you are not sure how to get started, visit ARINs website. It is not that difficult or expensive and it would not be hard to justify. Steven Naslund Chicago IL >And after 75 messages, nobody has asked the obvious question. When is ARDC going to acquire IPv6 resources on our behalf? Instead being all worried about legacy resources >we're highly underutilizing. > >Ham Radio is supposed to be about pushing the art forward. Let's do that. > >-KC8QAY From mattlists at rivervalleyinternet.net Tue Jul 23 14:58:24 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Tue, 23 Jul 2019 10:58:24 -0400 Subject: 44/8 In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> Message-ID: <2b08260e-df3c-1275-3749-bee4212eac0d@rivervalleyinternet.net> I really just want to know how I can purchase some more of that 44. space :) On 7/23/19 10:56 AM, Naslund, Steve wrote: > How about this? If you guys think your organization (club, group of friends, neighborhood association, whatever...) got screwed over by the ARDC, then why not apply for your own v6 allocation. You would then have complete control over its handling and never have to worry about it again. If you are not sure how to get started, visit ARINs website. It is not that difficult or expensive and it would not be hard to justify. > > Steven Naslund > Chicago IL > >> And after 75 messages, nobody has asked the obvious question. When is ARDC going to acquire IPv6 resources on our behalf? Instead being all worried about legacy resources >we're highly underutilizing. >> >> Ham Radio is supposed to be about pushing the art forward. Let's do that. >> >> -KC8QAY > From SNaslund at medline.com Tue Jul 23 15:01:30 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 23 Jul 2019 15:01:30 +0000 Subject: 44/8 In-Reply-To: <2b08260e-df3c-1275-3749-bee4212eac0d@rivervalleyinternet.net> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> <2b08260e-df3c-1275-3749-bee4212eac0d@rivervalleyinternet.net> Message-ID: <5a81c49772664220bc5aaafffd7b5122@medline.com> Why bother purchasing space? CGNAT or v6 would both be better ways to go and future proof. The v4 space you purchase today will be essentially worthless. Steven Naslund Chicago IL >I really just want to know how I can purchase some more of that 44. >space :) From Nathan.Brookfield at simtronic.com.au Tue Jul 23 15:01:49 2019 From: Nathan.Brookfield at simtronic.com.au (Nathan Brookfield) Date: Tue, 23 Jul 2019 15:01:49 +0000 Subject: 44/8 In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us>, Message-ID: <5C607B2E-A741-4C6D-84CB-8DB95FE0C8AC@simtronic.com.au> Yeah because v6 only is the answer plus tour assuming all of these clubs have routers and BGP and the money to get an allocation and ASN.... On 23 Jul 2019, at 22:59, Naslund, Steve wrote: How about this? If you guys think your organization (club, group of friends, neighborhood association, whatever...) got screwed over by the ARDC, then why not apply for your own v6 allocation. You would then have complete control over its handling and never have to worry about it again. If you are not sure how to get started, visit ARINs website. It is not that difficult or expensive and it would not be hard to justify. Steven Naslund Chicago IL > And after 75 messages, nobody has asked the obvious question. When is ARDC going to acquire IPv6 resources on our behalf? Instead being all worried about legacy resources >we're highly underutilizing. > > Ham Radio is supposed to be about pushing the art forward. Let's do that. > > -KC8QAY From matt at netfire.net Tue Jul 23 15:18:07 2019 From: matt at netfire.net (Matt Harris) Date: Tue, 23 Jul 2019 10:18:07 -0500 Subject: 44/8 In-Reply-To: <5C607B2E-A741-4C6D-84CB-8DB95FE0C8AC@simtronic.com.au> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> <5C607B2E-A741-4C6D-84CB-8DB95FE0C8AC@simtronic.com.au> Message-ID: On Tue, Jul 23, 2019 at 10:05 AM Nathan Brookfield < Nathan.Brookfield at simtronic.com.au> wrote: > Yeah because v6 only is the answer plus tour assuming all of these clubs > have routers and BGP and the money to get an allocation and ASN.... > If any amateur radio folks want to use a v6 block that's been allocated to them for amateur radio/digital comms/etc purposes, there are probably plenty of folks who already have routers/bgp sessions/ASNs who'd be happy to announce their space for them at no cost. If someone doing so were to ask me nicely, I really can't think of a reason not to. It doesn't really cost me anything and no one's pushing enough traffic on ham bands to amount to enough to even think about the bandwidth usage under most circumstances. There's plenty of overlap between hams and people who want to support the hobby, and network operators with resources to spare. And if things don't work out, since it's your own space, you can take it and go elsewhere if needed - it can't be sold out from under you. Additionally, one can run their own bgp with extremely inexpensive gear these days. Ubiquiti's edgerouters will do it (around $100 USD), or a whitebox running pfsense or any number of other FOSS operating systems. You don't need multiple full tables from several providers plus a half-dozen IX sessions to announce a /48 for ham radio use. That same low-cost gear can tunnel the space to wherever you need it, too, if needed. Remember, we're almost always talking about very very low bandwidth applications here on amateur spectrum. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SNaslund at medline.com Tue Jul 23 16:43:04 2019 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 23 Jul 2019 16:43:04 +0000 Subject: 44/8 In-Reply-To: <5C607B2E-A741-4C6D-84CB-8DB95FE0C8AC@simtronic.com.au> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us>, <5C607B2E-A741-4C6D-84CB-8DB95FE0C8AC@simtronic.com.au> Message-ID: <61f353cd1f4e45199b52b669a2e70ccc@medline.com> So, if ARIN allocates a v6 assignment to ARDC how do you plan to use it without a router or BGP. Whether it's v4 or v6 you need to route it somewhere. If you have a PC, you can have a router and if you don't have a PC you probably don't need to worry about any of this. If your club can't afford the address allocation then you are probably in too expensive a hobby. That is one of the cheaper things you need to get to do radio data. Steven Naslund Chicago IL >Yeah because v6 only is the answer plus tour assuming all of these clubs have routers and BGP and the money to get an allocation and ASN.... From bill at herrin.us Tue Jul 23 17:43:25 2019 From: bill at herrin.us (William Herrin) Date: Tue, 23 Jul 2019 10:43:25 -0700 Subject: 44/8 In-Reply-To: <02148adc7cfe4952ac1a3c800a3cdd24@medline.com> References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> <822B49BC-214D-45AE-979D-BFE0B540F55F@delong.com> <02148adc7cfe4952ac1a3c800a3cdd24@medline.com> Message-ID: On Tue, Jul 23, 2019 at 7:32 AM Naslund, Steve wrote: > In defense of John and ARIN, if you did not recognize that ARDC > represented an authority for this resource, who would be? > The American Radio Relay League (ARRL) is THE organization which represents Hams in regulatory matters in the U.S. and is well known to Hams worldwide. You don't have to look very far. Just ask any ham. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Tue Jul 23 18:05:34 2019 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 23 Jul 2019 13:05:34 -0500 Subject: 44/8 In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> Message-ID: On Tue, Jul 23, 2019 at 9:57 AM Naslund, Steve wrote: > How about this? If you guys think your organization (club, group of friends, > neighborhood association, whatever...) got screwed over by the ARDC, then > why not apply for your own v6 allocation. You would then have complete They could likely just use Link-Local V6 space if they wanted. Digital linking using space from the 44/8 block would very likely often be at 1200 or 9600 baud for many uses. Each bit of overhead expensive, and IPv6 with its much greater overhead would seem uniquely Unsuitable and not a viable replacement for IPv4 usage in cases. I'm curious how does a "Point of Contact" change from a Point of Contact to the general organization, to "Owner of a resource"? My general assumption is one does not follow from the other --- for example, Amazon might designate an Admin POC for their /10, But by no means does that confer a right to that individual to auction Amazon's /10, sell the block, and decide how the sales proceeds will be used. Its not even that the registry should allow this and say "Well, Amazon, tough.. if you didn't want it sold by $POC or their successor against your wishes, then you should have appointed a better POC." I would anticipate the registry requiring legal documents from $OrgName signed by however many people to verify complete agency over $OrgName or someone making a representation; not just sending an e-mail or pushing a button. And if there is no organization name, then it may just be that there isn't a single person in the world who has been vested with authorization to represent an item registered "for use by a community" or "the public in general" in matters like that. And why should any one organization get to monetize AMPRnet and decide the use of any funds for monetization? They may be a public benefit, but how do you establish they are the _right_ and _only_ public benefit, that the public deems the most proper for advancing development for the greatest public good in IP/digital networking communications? The mention of "Scholarships" and "Grants" to be decided by the board of the entity that seemed to unilaterally decide to "Sell" a shared resource that was provided for free - Sounds like an idea biased towards "academics" and certain kinds of researchers -- as in more most likely university academics --- sounds suspect. Perhaps Scholarships mostly benefit an individual, and Grants could be decided by an entity more well-known and reputable to the community such as one vetted by IARU or ARRL, anyways. Usage from the 44/8 space chosen is not necessarily co-ordinated with nor were AMPR networks created within 44/8 ever required to be approved or co-ordinated by any central registry contacts that were shown for the block, and the AMPR users can simply continue ignoring any IANA changes to 44/8; just like you probably would if some random contact on a registry record decided they were owner, and auctioned off "192.168.0.0/17" reducing the shared 192.168 allocation to 192.168.128.0/17 only. They may simply go by the decisions of whichever user, vendor, or experimenter makes the linking technology in question for deciding the IP address co-ordination --- For example, the Icom or Yaesu network may designate their own addressing authority for users of their digital linking system, and there is a good chance they already do. I think there is a false belief here in the first place that the community in question which is separate from the internet relies upon IANA or ARIN registry information to continue existing or using address space; Or that the contact has any "ownership", "resource holdership", or "network management" purpose, for anything related to 44/8 other than a purpose of co-ordination for a SUBSET of the likely AMPRnet 44/8 users when considering CERTAIN applications of AMPRnet where interoperability with internet was a goal. And 44/8 commonly for discrete isolated networks; similar to RFC1918, But predating RFC1918 by almost two decades. Consider that 10.0.0.0/8 COULD have been a substitute for many 44/8 applications. My understanding is this 44/8 allocation predates the public internet; and its normal everyday usage is completely separate from public internet IP having been actually utilized on this space first. People sought an allocation from IANA originally, but that does not give IANA nor any contact listed by IANA "ownership" or "management" authority over usage of this IP address space outside of their registry which is supposed to accurately cover the internet: but the AMPRnet is Not a block of networks on the internet, and not under the purview of IETF or IANA, anyways --- its just a community that uses TCP/IP mostly in isolated discrete networks which can be neither allocated, nor managed, nor get their individual assignments within 44/8 from any central authority. Although ARDC provides an option to do so --- these users co-ordinating their assignments already get them from ARDC, so the users requiring internet interoperability already stipulate to ARDC's co-ordination. Few projects would likely muster BGP access anyways, and would most likely be NAT'ing any 44/8 space if tunneling over the internet. I'm not sure any change to this ever listed by IANA should actually be recognized by. _other_ AMPRnet users, since there is no impact to isolated networks using this space --- anyone impacted will probably just choose to ignore the registry change and don't really care what "the internet" Whois says about the 44/8. In a way; it just means the IANA registry data became corrupted/Less accurate Due to IANA's failure to clearly state a policy for the maintenance of the allocations and/or ARDC "converting" ownership or being allowed to take up a false pretense of ownership of the registry allocation. -- -JH From ryan.g at atwgpc.net Wed Jul 24 00:04:42 2019 From: ryan.g at atwgpc.net (Ryan Gelobter) Date: Tue, 23 Jul 2019 19:04:42 -0500 Subject: CenturyLink/Level3 feedback In-Reply-To: References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> <20190705191013.GU29202@tamriel.snowman.net> <3ae63f9a-6fba-a071-be3e-89c17ac355a0@seacom.mu> <92781b46-6e63-d650-30a4-290efed1a3ea@ufl.edu> Message-ID: I wish CenturyLink would better manage both the legacy level3 portal and the current centurylink portal. The fact that I cant just go into 1 place and see all of my circuits now is annoying. On Wed, Jul 10, 2019 at 10:52 AM Cummings, Chris wrote: > I was always taught that “if you can't say anything nice, don't say > nothing at all”—That being said, my last CenturyLink turnup was worse than > my last AT&T turnup. Take that for what it is worth. > > > > /chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sfrost at snowman.net Wed Jul 24 00:12:45 2019 From: sfrost at snowman.net (Stephen Frost) Date: Tue, 23 Jul 2019 20:12:45 -0400 Subject: CenturyLink/Level3 feedback In-Reply-To: References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> <20190705191013.GU29202@tamriel.snowman.net> <3ae63f9a-6fba-a071-be3e-89c17ac355a0@seacom.mu> <92781b46-6e63-d650-30a4-290efed1a3ea@ufl.edu> Message-ID: <20190724001245.GV29202@tamriel.snowman.net> Since there was a comment on this again, I figure I'll provide an update ('just' the facts...)- it's now been two more weeks with no evidence of any progress being made, the equipment's been just sitting there, with CL going a week without providing any update until prodded and then it was "let me get back to you"... So, no idea when/if this circuit is going to actually get turned up... * Ryan Gelobter (ryan.g at atwgpc.net) wrote: > I wish CenturyLink would better manage both the legacy level3 portal and > the current centurylink portal. The fact that I cant just go into 1 place > and see all of my circuits now is annoying. > > On Wed, Jul 10, 2019 at 10:52 AM Cummings, Chris > wrote: > > > I was always taught that “if you can't say anything nice, don't say > > nothing at all”—That being said, my last CenturyLink turnup was worse than > > my last AT&T turnup. Take that for what it is worth. > > > > > > > > /chris > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From owen at delong.com Wed Jul 24 01:44:39 2019 From: owen at delong.com (Owen DeLong) Date: Tue, 23 Jul 2019 18:44:39 -0700 Subject: 44/8 In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> Message-ID: Not entirely true. A lot of 44/8 subnets are used for transporting amateur radio information across the internet and/or for certain limited applications linking amateur radio and the internet. Owen > On Jul 23, 2019, at 11:05, Jimmy Hess wrote: > >> On Tue, Jul 23, 2019 at 9:57 AM Naslund, Steve wrote: >> How about this? If you guys think your organization (club, group of friends, >> neighborhood association, whatever...) got screwed over by the ARDC, then >> why not apply for your own v6 allocation. You would then have complete > > They could likely just use Link-Local V6 space if they wanted. > Digital linking using space from the 44/8 block would very likely > often be at 1200 or 9600 baud for many uses. Each bit of overhead > expensive, and IPv6 with its much greater overhead would seem > uniquely Unsuitable and not a viable replacement for IPv4 usage in cases. > > I'm curious how does a "Point of Contact" change from a Point of Contact > to the general organization, to "Owner of a resource"? > My general assumption is one does not follow from the other --- for > example, Amazon might designate an Admin POC for their /10, But > by no means does that confer a right to that individual to auction > Amazon's /10, sell the block, and decide how the sales proceeds will be used. > > Its not even that the registry should allow this and say "Well, Amazon, > tough.. if you didn't want it sold by $POC or their successor against your > wishes, then you should have appointed a better POC." > I would anticipate the registry requiring legal documents from $OrgName > signed by however many people to verify complete agency over $OrgName > or someone making a representation; not just sending an e-mail > or pushing a button. > > And if there is no organization name, then it may just be that > there isn't a single person in the world who has been vested > with authorization to represent an item registered "for use by a community" > or "the public in general" in matters like that. > > > And why should any one organization get to monetize AMPRnet and > decide the use of any funds for monetization? They may be a public > benefit, but how do you establish they are the _right_ and _only_ > public benefit, that the public deems the most proper for advancing > development for the greatest public good in IP/digital networking > communications? > > The mention of "Scholarships" and "Grants" to be decided by the > board of the entity that seemed to unilaterally decide to "Sell" a > shared resource that was provided for free - Sounds like an > idea biased towards "academics" and certain kinds of researchers > -- as in more most likely university academics --- sounds suspect. > Perhaps Scholarships mostly benefit an individual, and Grants could > be decided by an entity more well-known and reputable to the > community such as one vetted by IARU or ARRL, anyways. > > Usage from the 44/8 space chosen is not necessarily co-ordinated with nor > were AMPR networks created within 44/8 ever required to be approved or > co-ordinated by any central registry contacts that were shown for the block, > and the AMPR users can simply continue ignoring any IANA changes to 44/8; > just like you probably would if some random contact on a registry record > decided they were owner, and auctioned off "192.168.0.0/17" reducing > the shared 192.168 allocation to 192.168.128.0/17 only. > > They may simply go by the decisions of whichever user, vendor, or > experimenter makes the linking technology in question for deciding the > IP address co-ordination --- For example, the Icom or Yaesu network > may designate their own addressing authority for users of their digital > linking system, and there is a good chance they already do. > > I think there is a false belief here in the first place that the community > in question which is separate from the internet relies upon IANA or ARIN > registry information to continue existing or using address space; Or that the > contact has any "ownership", "resource holdership", or "network management" > purpose, for anything related to 44/8 other than a purpose of > co-ordination for > a SUBSET of the likely AMPRnet 44/8 users when considering > CERTAIN applications of AMPRnet where interoperability with internet was > a goal. > > And 44/8 commonly for discrete isolated networks; similar to RFC1918, > But predating RFC1918 by almost two decades. Consider that > 10.0.0.0/8 COULD have been a substitute for many 44/8 applications. > > My understanding is this 44/8 allocation predates the public internet; > and its normal everyday usage is completely separate from public internet > IP having been actually utilized on this space first. People sought an > allocation from IANA originally, but that does not give IANA nor > any contact listed by IANA "ownership" or "management" authority > over usage of this IP address space outside of their registry which > is supposed to accurately cover the internet: but the AMPRnet is Not > a block of networks on the internet, and not under the purview > of IETF or IANA, anyways --- its just a community that uses > TCP/IP mostly in isolated discrete networks which can be neither > allocated, nor managed, nor get their individual assignments > within 44/8 from any central authority. > > Although ARDC provides an option to do so --- these users > co-ordinating their assignments already get them from ARDC, > so the users requiring internet interoperability already stipulate > to ARDC's co-ordination. > > Few projects would likely muster BGP access anyways, and would > most likely be NAT'ing any 44/8 space if tunneling over the internet. > > I'm not sure any change to this ever listed by IANA should actually > be recognized by. _other_ AMPRnet users, since there is no impact to > isolated networks using this space --- anyone impacted will > probably just choose to ignore the registry change and > don't really care what "the internet" Whois says about the 44/8. > > In a way; it just means the IANA registry data became > corrupted/Less accurate Due to IANA's failure to clearly > state a policy for the maintenance of the allocations and/or > ARDC "converting" ownership or being allowed to take > up a false pretense of ownership of the registry allocation. > > -- > -JH From nanog at as397444.net Wed Jul 24 02:09:31 2019 From: nanog at as397444.net (Matt Corallo) Date: Wed, 24 Jul 2019 02:09:31 +0000 Subject: CenturyLink/Level3 feedback In-Reply-To: <20190724001245.GV29202@tamriel.snowman.net> References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> <20190705191013.GU29202@tamriel.snowman.net> <3ae63f9a-6fba-a071-be3e-89c17ac355a0@seacom.mu> <92781b46-6e63-d650-30a4-290efed1a3ea@ufl.edu> <20190724001245.GV29202@tamriel.snowman.net> Message-ID: <90728861-7e4b-139c-8a91-44afaca8a941@bluematt.me> Two weeks? We're at two months and counting. Honestly about to walk away from the contract at this point, fees or no. Matt On 7/24/19 12:12 AM, Stephen Frost wrote: > Since there was a comment on this again, I figure I'll provide an update > ('just' the facts...)- it's now been two more weeks with no evidence of > any progress being made, the equipment's been just sitting there, with > CL going a week without providing any update until prodded and then it > was "let me get back to you"... > > So, no idea when/if this circuit is going to actually get turned up... > > * Ryan Gelobter (ryan.g at atwgpc.net) wrote: >> I wish CenturyLink would better manage both the legacy level3 portal and >> the current centurylink portal. The fact that I cant just go into 1 place >> and see all of my circuits now is annoying. >> >> On Wed, Jul 10, 2019 at 10:52 AM Cummings, Chris >> wrote: >> >>> I was always taught that “if you can't say anything nice, don't say >>> nothing at all”—That being said, my last CenturyLink turnup was worse than >>> my last AT&T turnup. Take that for what it is worth. >>> >>> >>> >>> /chris >>> From egon at egon.cc Wed Jul 24 04:32:06 2019 From: egon at egon.cc (James Downs) Date: Tue, 23 Jul 2019 21:32:06 -0700 Subject: 44/8 In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> Message-ID: > On Jul 23, 2019, at 18:44, Owen DeLong wrote: > > Not entirely true. A lot of 44/8 subnets are used for transporting amateur radio information across the internet and/or for certain limited applications linking amateur radio and the internet. In the mid 90's we (an ISP) announced the space for WI's packet community. If it didn't need internet connectivity, you wouldn't need the IP addresses, necessarily. Also, from the AMPR website: https://www.ampr.org/about/ "We don’t sell addresses; you might consider an AMPRNet allocation to be in the nature of an extended loan of IP space, which is, of course, subject to our Terms of Service." And of course, from: https://www.ampr.org/terms-of-service/ > 5. What You may not do > > You may NOT sell, exchange, transfer, or otherwise obtain anything of value for the address(es). You are not permitted to use the address(es) for commercial purposes, nor in a manner which would be to the detriment of the AMPRNet or to Amateur Radio. > > 6. What You are agreeing to > > All address(es) licensed to You remain the sole and exclusive property of ARDC. You do not obtain any rights, title, or interest in the address(es) nor in the AMPRNet. > > You may not assign any monetary value to the addresses. ... > 8. Definitions > > “Amateur”, “ham”, “operator”, means a person or group licensed under the terms of the Amateur Radio Service as defined by the International Telecommunication Union (ITU) as implemented by their country’s government, e.g., in the USA, under 47CFR97. > > “AMPRNet” means the network 44/8; that is, all Internet IP addresses from 44.0.0.0 through 44.255.255.255. And also from: http://wiki.ampr.org/wiki/Main_Page > Since its allocation to Amateur Radio in the mid-1980's, Internet network 44 (44.0.0.0/8), known as the AMPRNet™, ... > • This page was last edited on 5 April 2014, at 04:32. They certainly seem to be claiming to have ownership of something not assigned to them, and in conflict with their own stated TOS. What seems additionally strange is that according to the addressing agreement from 1986, according to wikipedia, "The allocation plan agreed in late-1986 mandated 44.0/9 (~8 million addresses) for use within the United States, under Federal Communications Commission (FCC) regulations;[6] and mandated 44.128/9 (~8 million addresses) for the Rest-of-World deployment, outside of FCC regulations.[6]" From Rob.Wcislo at gtt.net Wed Jul 24 07:15:47 2019 From: Rob.Wcislo at gtt.net (Rob Wcislo) Date: Wed, 24 Jul 2019 07:15:47 +0000 Subject: CenturyLink/Level3 feedback In-Reply-To: References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> <20190705191013.GU29202@tamriel.snowman.net> <3ae63f9a-6fba-a071-be3e-89c17ac355a0@seacom.mu> <92781b46-6e63-d650-30a4-290efed1a3ea@ufl.edu> , Message-ID: <12E5EB73CE4D43DF.88087919-443D-4E26-A361-4899C6E30472@mail.outlook.com> GTT has this 😁 https://ethervision.gtt.net Rob Wcislo VP, Sales GTT (954)305-2289 On Tue, Jul 23, 2019 at 8:07 PM -0400, "Ryan Gelobter" > wrote: I wish CenturyLink would better manage both the legacy level3 portal and the current centurylink portal. The fact that I cant just go into 1 place and see all of my circuits now is annoying. On Wed, Jul 10, 2019 at 10:52 AM Cummings, Chris > wrote: I was always taught that “if you can't say anything nice, don't say nothing at all”—That being said, my last CenturyLink turnup was worse than my last AT&T turnup. Take that for what it is worth. /chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoffer at netravnen.de Wed Jul 24 10:43:55 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Wed, 24 Jul 2019 12:43:55 +0200 Subject: 44/8 In-Reply-To: <59f5f318f2394a93b292a942ac1bf27c@CRA114.am.necel.com> References: <59f5f318f2394a93b292a942ac1bf27c@CRA114.am.necel.com> Message-ID: On 23/07/2019 02:23, Michel Py wrote: > This is the last attempt that I remember : https://tools.ietf.org/html/draft-wilson-class-e-02 Of interest can be : https://www.netdevconf.org/0x13/session.html?talk-ipv4-unicast-expansions -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From brennanma at gmail.com Tue Jul 23 20:33:33 2019 From: brennanma at gmail.com (Matt Brennan) Date: Tue, 23 Jul 2019 16:33:33 -0400 Subject: 44/8 In-Reply-To: <61f353cd1f4e45199b52b669a2e70ccc@medline.com> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> <5C607B2E-A741-4C6D-84CB-8DB95FE0C8AC@simtronic.com.au> <61f353cd1f4e45199b52b669a2e70ccc@medline.com> Message-ID: In addition to my day job I also run IT for a 501(c)(3) ham "club" that does amateur radio based public service and emergency communications. Our annual cash donations are about $100. We could never afford an IPv6 allocation or an AS number. I wish we could because I'd love to use some of the AMPRNET space for some of our operations. Our ISP doesn't support IPv6 yet, so I won't even get into that discussion. While we don't have cash, we frequently get donations in the form of [used] equipment. Our entire network backbone is Cisco. Our radio systems are almost exclusively Motorola public safety grade hardware. Our Internet connection is paid for by a served agency. People are happy to donate their time, services, and hardware to us; just not cash. Saying that not having cash on hand means you don't have the resources to do packet radio is not necessarily true. -Matt, NM1B On Tue, Jul 23, 2019 at 12:44 PM Naslund, Steve wrote: > So, if ARIN allocates a v6 assignment to ARDC how do you plan to use it > without a router or BGP. Whether it's v4 or v6 you need to route it > somewhere. If you have a PC, you can have a router and if you don't have a > PC you probably don't need to worry about any of this. If your club can't > afford the address allocation then you are probably in too expensive a > hobby. That is one of the cheaper things you need to get to do radio data. > > Steven Naslund > Chicago IL > > >Yeah because v6 only is the answer plus tour assuming all of these clubs > have routers and BGP and the money to get an allocation and ASN.... > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apishdadi at gmail.com Wed Jul 24 01:38:54 2019 From: apishdadi at gmail.com (A. Pishdadi) Date: Tue, 23 Jul 2019 20:38:54 -0500 Subject: CenturyLink/Level3 feedback In-Reply-To: <20190724001245.GV29202@tamriel.snowman.net> References: <1A2E1F56-FCE3-4BC8-A713-B78CE8923C51@me.com> <1378889839.3472.1559746792281.JavaMail.mhammett@ThunderFuck> <20190705191013.GU29202@tamriel.snowman.net> <3ae63f9a-6fba-a071-be3e-89c17ac355a0@seacom.mu> <92781b46-6e63-d650-30a4-290efed1a3ea@ufl.edu> <20190724001245.GV29202@tamriel.snowman.net> Message-ID: We have had the worst experience in 20 years dealing with century link and turning up new transit circuits , its been over 9 months since we ordered circuits in LA Chicago and Ashburn and we still do not have our sessions up with links. Level3 has been ruined... On Tue, Jul 23, 2019 at 7:14 PM Stephen Frost wrote: > Since there was a comment on this again, I figure I'll provide an update > ('just' the facts...)- it's now been two more weeks with no evidence of > any progress being made, the equipment's been just sitting there, with > CL going a week without providing any update until prodded and then it > was "let me get back to you"... > > So, no idea when/if this circuit is going to actually get turned up... > > * Ryan Gelobter (ryan.g at atwgpc.net) wrote: > > I wish CenturyLink would better manage both the legacy level3 portal and > > the current centurylink portal. The fact that I cant just go into 1 place > > and see all of my circuits now is annoying. > > > > On Wed, Jul 10, 2019 at 10:52 AM Cummings, Chris > > wrote: > > > > > I was always taught that “if you can't say anything nice, don't say > > > nothing at all”—That being said, my last CenturyLink turnup was worse > than > > > my last AT&T turnup. Take that for what it is worth. > > > > > > > > > > > > /chris > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at nethead.com Wed Jul 24 02:18:02 2019 From: joe at nethead.com (Joe Hamelin) Date: Tue, 23 Jul 2019 19:18:02 -0700 Subject: 44/8 In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> Message-ID: On Tue, Jul 23, 2019 at 6:46 PM Owen DeLong wrote: > Not entirely true. A lot of 44/8 subnets are used for transporting amateur > radio information across the internet and/or for certain limited > applications linking amateur radio and the internet. > See HamWAN.org for the Seattle area multi-megabit ham network on 44/8 space. -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jra at baylink.com Wed Jul 24 14:23:10 2019 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 24 Jul 2019 14:23:10 +0000 (UTC) Subject: 44/8 In-Reply-To: References: Message-ID: <118967882.842939.1563978190956.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Randy Bush" > my deep sympathies go out to those folk with real work to do whose mail > user agents do not have a `delete thread` key sequence. For some people, Randy, this *is* real work, even if they're not getting paid for it. And didn't you, like, co-author procmail? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From kenny.taylor at kccd.edu Wed Jul 24 16:16:50 2019 From: kenny.taylor at kccd.edu (Kenny Taylor) Date: Wed, 24 Jul 2019 16:16:50 +0000 Subject: Traffic visibility tools Message-ID: Good morning, I hate to pull away from the 44/8 fire (KJ6BSQ here, and former AMPRnet user), but I'd like to get some advice from the community on traffic visibility tools.. We use a pair of appliances called Exinda for traffic shaping and visibility. The current appliances are end-of-support and the replacements are hugely expensive after GFI acquired Exinda. Traffic shaping is less of a concern now, as circuit speeds have caught up with our users, but visibility is still a big need. Those boxes do two things very well: 1) identification of FQDNs using SSL cert inspection on HTTPS traffic and 2) categorization of the traffic (i.e. Netflix, Youtube, etc.). We have Netflow monitoring using PRTG, but seeing something like 'ec2-34-214-76-39.us-west-2.compute.amazonaws.com' in Netflow logs isn't very useful. We're looking for something that could sit either inline or hang off a SPAN port, handle 5-10 Gbit of traffic, do the SSL cert FQDN identification, and preferably group results by site/subnet/category. What would you guys recommend? Thanks, Kenny Taylor WAN Engineer Kern Community College District -------------- next part -------------- An HTML attachment was scrubbed... URL: From joelja at bogus.com Wed Jul 24 17:14:52 2019 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 24 Jul 2019 10:14:52 -0700 Subject: Traffic visibility tools In-Reply-To: References: Message-ID: <7f22da5c-6dc6-7b4c-eb19-5a4d9d3e92c6@bogus.com> On 7/24/19 09:16, Kenny Taylor wrote: > > Good morning, > >   > > I hate to pull away from the 44/8 fire (KJ6BSQ here, and former > AMPRnet user), but I’d like to get some advice from the community on > traffic visibility tools.. > >   > > We use a pair of appliances called Exinda for traffic shaping and > visibility.  The current appliances are end-of-support and the > replacements are hugely expensive after GFI acquired Exinda.  Traffic > shaping is less of a concern now, as circuit speeds have caught up > with our users, but visibility is still a big need.  Those boxes do > two things very well:  1) identification of FQDNs using SSL cert > inspection on HTTPS traffic and 2) categorization of the traffic (i.e. > Netflix, Youtube, etc.).  We have Netflow monitoring using PRTG, but > seeing something like > ‘ec2-34-214-76-39.us-west-2.compute.amazonaws.com’ in Netflow logs > isn’t very useful. > tls 1.3 encrypted SNI  or QUIC and then DOH will eventually make https opaque. Whether this is soon or not I guess is an open question but passive inspection will probably become less useful over time. it seems likely to cause industry / monitoring product change as well. > > We’re looking for something that could sit either inline or hang off a > SPAN port, handle 5-10 Gbit of traffic, do the SSL cert FQDN > identification, and preferably group results by site/subnet/category.  > What would you guys recommend? > >   > > Thanks, > >   > > Kenny Taylor > > WAN Engineer > > Kern Community College District > >   > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1757 bytes Desc: not available URL: From drc at virtualized.org Wed Jul 24 19:43:29 2019 From: drc at virtualized.org (David Conrad) Date: Wed, 24 Jul 2019 12:43:29 -0700 Subject: Ancient history (was Re: 44/8) In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> Message-ID: <3E1A1D47-1267-4EB9-A458-15DBEE9A61C4@virtualized.org> Jimmy, I have been staying out of this particular food fight, but speaking purely in a personal capacity as someone who had a small role in early addressing stuff ages ago, I did want to clarify a couple of things: On Jul 23, 2019, at 11:05 AM, Jimmy Hess wrote: > People sought an > allocation from IANA originally, but that does not give IANA nor > any contact listed by IANA "ownership" or "management" authority > over usage of this IP address space outside of their registry which > is supposed to accurately cover the internet: but the AMPRnet is Not > a block of networks on the internet, and not under the purview > of IETF or IANA, anyways --- its just a community that uses > TCP/IP mostly in isolated discrete networks which can be neither > allocated, nor managed, nor get their individual assignments > within 44/8 from any central authority. Yes and no. There were actually a number of “class As” that Postel directed to be assigned based on layer 2 technology, e.g., 14/8 for X.25, 24/8 (I believe) for IP over CATV, 44/8 for IP over amateur radio, maybe a block assigned for IP over satellite (4/8? I don’t remember). In some cases, there was a ‘caretaker’ assigned (ARRL for 44/8 and @Home for 24/8) who acted as a pseudo-registry: they did (or at least were supposed to do) sub-assignments for entities that met (IANA- and pseudo-registry-) defined criteria. However, the informal assignments were, like all assignments of the day, based on the assumption that the addresses were supposed to be used to provide IP networking and if the addresses weren’t so used, they were to be returned to IANA. This was actually put in practice with 14/8 (which unfortunately didn’t have a ‘caretaker’ so we at IANA had to try to track down the remaining IP over X.25 users starting around 2007 or so IIRC — a bit challenging, but ultimately accomplished). I have vague memories of asking Brian Kantor (as the assignee in the IANA registry) about returning 44/8 back when we were cleaning up 14/8 but my recollection was that I was informed it would be too hard given the number, distribution, and global nature of the sub-assignments. In any event, this is largely irrelevant: there weren’t any contracts or other written agreements, it was all informal and based on folks doing the right thing, without fully agreed upon terms of what the “right thing” was (other than “for the good of the Internet” I suppose). > In a way; it just means the IANA registry data became > corrupted/Less accurate Due to IANA's failure to clearly > state a policy for the maintenance of the allocations and/or > ARDC "converting" ownership or being allowed to take > up a false pretense of ownership of the registry allocation. Err, no. It’s inappropriate to blame IANA here. IANA has a clear policy: management of IP addresses was delegated on a regional basis starting with RFC 1366/1466 around 1990, then RFC 2050 and finally RFC 7020. The existing IANA IPv4 registry largely consists of pointers to the RIRs as the delegatees of responsibility for the address space. If you have concerns with address policy, the proper place to raise those concerns is with the RIRs (and in the case of 44/8, ARIN). Regards, -drc -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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 bill at herrin.us Thu Jul 25 01:20:17 2019 From: bill at herrin.us (William Herrin) Date: Wed, 24 Jul 2019 18:20:17 -0700 Subject: Ancient history (was Re: 44/8) In-Reply-To: <3E1A1D47-1267-4EB9-A458-15DBEE9A61C4@virtualized.org> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <7485A40B-E49D-4377-9E67-0041C2D612AF@gmail.com> <34429134-fead-6313-5943-6fc4a07928ea@telcodata.us> <3E1A1D47-1267-4EB9-A458-15DBEE9A61C4@virtualized.org> Message-ID: On Wed, Jul 24, 2019 at 12:43 PM David Conrad wrote: > In some cases, there was a ‘caretaker’ assigned (ARRL for 44/8 and @Home > for 24/8) who acted as a pseudo-registry: they did (or at least were supposed > to do) sub-assignments for entities that met (IANA- and pseudo-registry-) > defined criteria. Hi David, Did you mean to say ARRL here? If you did, can you explain how 44/8 ended up with an organization unaffiliated with ARRL? One that I'll note: a. Has no public participation (unlike ARRL which has open membership and elections) b. Was established only this decade at ARIN's urging c. Is a 501(c)3 organization which has announced but not yet delivered plans for reducing its administrative overhead from 100%. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at essenz.com Thu Jul 25 13:37:57 2019 From: john at essenz.com (John Von Essen) Date: Thu, 25 Jul 2019 09:37:57 -0400 Subject: Abuse from Vodaphone AS30722 Message-ID: <9A45A560-1652-4E4B-B9D8-700D4F0A3E8E@essenz.com> Anyone from Vodaphone on list? We are experiencing a massive DDoS from three Vodafone /16’s. The DDoS is spread throughout the entire range. 2.38.0.0/16 2.39.0.0/16 188.216.0.0/16 We’ve had to block the entire ranges just to stay online. Thanks John -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ninjabadger.net Thu Jul 25 13:45:16 2019 From: tom at ninjabadger.net (Tom Hill) Date: Thu, 25 Jul 2019 14:45:16 +0100 Subject: Abuse from Vodaphone AS30722 In-Reply-To: <9A45A560-1652-4E4B-B9D8-700D4F0A3E8E@essenz.com> References: <9A45A560-1652-4E4B-B9D8-700D4F0A3E8E@essenz.com> Message-ID: On 25/07/2019 14:37, John Von Essen wrote: > We are experiencing a massive DDoS from three Vodafone /16’s. The DDoS > is spread throughout the entire range. You say *Distributed*, from that I would expect that this traffic is ingressing at multiple locations in your network? I'd be surprised if Vodafone's domestic Italian network would spread traffic to your ASN over multiple paths, and so if it is coming in from multiple ingress points, you're probably looking at spoofed-source traffic. -- Tom From gregskinner0 at icloud.com Thu Jul 25 21:41:04 2019 From: gregskinner0 at icloud.com (Greg Skinner) Date: Thu, 25 Jul 2019 14:41:04 -0700 Subject: 240/4 (Re: 44/8) In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> Message-ID: > On Jul 22, 2019, at 9:15 PM, Ross Tajvar wrote: > >> Editor's note: This draft has not been submitted to any formal >> process. It may change significantly if it is ever submitted. >> You are reading it because we trust you and we value your >> opinions. *Please do not recirculate it.* Please join us in >> testing patches and equipment! > > (emphasis mine) > > Interesting choice to host it in a public Github repo, then... > Funny, that … BTW, there are a few missing links in the References that some of you may find useful: [IEN48] Cerf, V., "The CATENET MODEL FOR INTERNETWORKING", 1978, [IETF-13] Gross, P., Bowers, K., "IETF Proceedings", 1989, [IHML] Many, T., "Internet History Mailing list", 2019, Dave Täht and John Gilmore raised issues discussed in the draft in the February 2019 and March 2019 internet-history list archives, respectively. FWIW, here are some additional resources: IPv4 Unicast Extensions Netdevconf preso, March 2019 The IPv4 Cleanup Project GitHub repo —gregbo -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscora at apnic.net Fri Jul 26 18:03:58 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 27 Jul 2019 04:03:58 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190726180358.9E8C6C44A1@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 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 27 Jul, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 762538 Prefixes after maximum aggregation (per Origin AS): 294776 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 368584 Total ASes present in the Internet Routing Table: 65002 Prefixes per ASN: 11.73 Origin-only ASes present in the Internet Routing Table: 55882 Origin ASes announcing only one prefix: 23956 Transit ASes present in the Internet Routing Table: 9120 Transit-only ASes present in the Internet Routing Table: 282 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 42 Max AS path prepend of ASN ( 27978) 31 Prefixes from unregistered ASNs in the Routing Table: 24 Number of instances of unregistered ASNs: 24 Number of 32-bit ASNs allocated by the RIRs: 28019 Number of 32-bit ASNs visible in the Routing Table: 22875 Prefixes from 32-bit ASNs in the Routing Table: 103520 Number of bogon 32-bit ASNs visible in the Routing Table: 14 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 236 Number of addresses announced to Internet: 2842092800 Equivalent to 169 /8s, 102 /16s and 229 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: 76.8 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.3 Total number of prefixes smaller than registry allocations: 253604 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 205999 Total APNIC prefixes after maximum aggregation: 61645 APNIC Deaggregation factor: 3.34 Prefixes being announced from the APNIC address blocks: 201357 Unique aggregates announced from the APNIC address blocks: 84412 APNIC Region origin ASes present in the Internet Routing Table: 9928 APNIC Prefixes per ASN: 20.28 APNIC Region origin ASes announcing only one prefix: 2741 APNIC Region transit ASes present in the Internet Routing Table: 1490 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4925 Number of APNIC addresses announced to Internet: 770811392 Equivalent to 45 /8s, 241 /16s and 166 /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-141625 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: 226807 Total ARIN prefixes after maximum aggregation: 106000 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 225724 Unique aggregates announced from the ARIN address blocks: 107079 ARIN Region origin ASes present in the Internet Routing Table: 18529 ARIN Prefixes per ASN: 12.18 ARIN Region origin ASes announcing only one prefix: 6860 ARIN Region transit ASes present in the Internet Routing Table: 1915 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2825 Number of ARIN addresses announced to Internet: 1070904448 Equivalent to 63 /8s, 212 /16s and 180 /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-399260 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, 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: 210755 Total RIPE prefixes after maximum aggregation: 100036 RIPE Deaggregation factor: 2.11 Prefixes being announced from the RIPE address blocks: 207001 Unique aggregates announced from the RIPE address blocks: 123449 RIPE Region origin ASes present in the Internet Routing Table: 26286 RIPE Prefixes per ASN: 7.87 RIPE Region origin ASes announcing only one prefix: 11623 RIPE Region transit ASes present in the Internet Routing Table: 3752 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 35 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8331 Number of RIPE addresses announced to Internet: 720794240 Equivalent to 42 /8s, 246 /16s and 114 /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-210331 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: 98293 Total LACNIC prefixes after maximum aggregation: 22726 LACNIC Deaggregation factor: 4.33 Prefixes being announced from the LACNIC address blocks: 99562 Unique aggregates announced from the LACNIC address blocks: 43931 LACNIC Region origin ASes present in the Internet Routing Table: 8657 LACNIC Prefixes per ASN: 11.50 LACNIC Region origin ASes announcing only one prefix: 2275 LACNIC Region transit ASes present in the Internet Routing Table: 1595 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 39 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 6209 Number of LACNIC addresses announced to Internet: 173525248 Equivalent to 10 /8s, 87 /16s and 201 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-270748 + 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: 20659 Total AfriNIC prefixes after maximum aggregation: 4349 AfriNIC Deaggregation factor: 4.75 Prefixes being announced from the AfriNIC address blocks: 28658 Unique aggregates announced from the AfriNIC address blocks: 9501 AfriNIC Region origin ASes present in the Internet Routing Table: 1305 AfriNIC Prefixes per ASN: 21.96 AfriNIC Region origin ASes announcing only one prefix: 457 AfriNIC Region transit ASes present in the Internet Routing Table: 253 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 27 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 585 Number of AfriNIC addresses announced to Internet: 105820416 Equivalent to 6 /8s, 78 /16s and 177 /24s AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 45/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 7545 4862 591 567 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3178 1459 31 VIETEL-AS-AP Viettel Group, VN 45899 3053 1764 110 VNPT-AS-VN VNPT Corp, VN 9808 2750 9043 63 CMNET-GD Guangdong Mobile Communication 9829 2694 1489 562 BSNL-NIB National Internet Backbone, IN 4766 2542 11119 761 KIXS-AS-KR Korea Telecom, KR 7713 2226 670 591 TELKOMNET-AS-AP PT Telekomunikasi Indon 4755 2158 429 190 TATACOMM-AS TATA Communications formerl 9498 2130 430 200 BBIL-AP BHARTI Airtel Ltd., IN 9394 2072 4898 24 CTTNET China TieTong Telecommunications 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 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3681 240 615 CABLEONE - CABLE ONE, INC., US 6327 3564 1324 90 SHAW - Shaw Communications Inc., CA 22773 3445 2974 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 3044 6390 1430 AMAZON-02 - Amazon.com, Inc., US 16625 2627 1380 1908 AKAMAI-AS - Akamai Technologies, Inc., 30036 2163 347 245 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2151 2763 524 CHARTER-20115 - Charter Communications, 18566 2094 405 107 MEGAPATH5-US - MegaPath Corporation, US 5650 2077 3073 1452 FRONTIER-FRTR - Frontier Communications 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 5507 1629 141 UNI2-AS, ES 39891 3780 219 19 ALJAWWALSTC-AS, SA 8551 3326 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2696 506 1920 AKAMAI-ASN1, US 12389 2358 2230 661 ROSTELECOM-AS, RU 34984 2115 346 547 TELLCOM-AS, TR 9009 1658 178 896 M247, GB 9121 1609 1692 18 TTNET, TR 13188 1604 100 47 TRIOLAN, UA 61317 1411 147 527 ASDETUK http://www.heficed.com, GB 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 6258 3376 592 Uninet S.A. de C.V., MX 10620 3396 536 428 Telmex Colombia S.A., CO 11830 2688 370 54 Instituto Costarricense de Electricidad 6503 1624 391 419 Axtel, S.A.B. de C.V., MX 7303 1474 1022 281 Telecom Argentina S.A., AR 28573 1152 2227 205 CLARO S.A., BR 6147 1096 377 31 Telefonica del Peru S.A.A., PE 3816 1045 526 118 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 985 480 248 Mega Cable, S.A. de C.V., MX 11172 934 112 60 Alestra, S. de R.L. de C.V., MX 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 1183 393 21 LINKdotNET-AS, EG 24835 886 634 22 RAYA-AS, EG 36903 843 424 112 MT-MPLS, MA 36992 819 1532 87 ETISALAT-MISR, EG 8452 674 1859 20 TE-AS TE-AS, EG 29571 520 68 11 ORANGE-COTE-IVOIRE, CI 37492 482 470 57 ORANGE-, TN 37342 414 32 1 MOVITEL, MZ 15399 384 45 11 WANANCHI-, KE 23889 358 231 15 MauritiusTelecom, MU 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 8151 6258 3376 592 Uninet S.A. de C.V., MX 12479 5507 1629 141 UNI2-AS, ES 7545 4862 591 567 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3780 219 19 ALJAWWALSTC-AS, SA 11492 3681 240 615 CABLEONE - CABLE ONE, INC., US 6327 3564 1324 90 SHAW - Shaw Communications Inc., CA 22773 3445 2974 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3396 536 428 Telmex Colombia S.A., CO 8551 3326 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 12479 5507 5366 UNI2-AS, ES 7545 4862 4295 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 4039 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3780 3761 ALJAWWALSTC-AS, SA 6327 3564 3474 SHAW - Shaw Communications Inc., CA 22773 3445 3289 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3326 3280 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3178 3147 VIETEL-AS-AP Viettel Group, VN 11492 3681 3066 CABLEONE - CABLE ONE, INC., US 10620 3396 2968 Telmex Colombia S.A., CO 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 260984 UNALLOCATED 45.175.186.0/23 16735 ALGAR TELECOM S/A, BR 266842 UNALLOCATED 45.238.156.0/22 265680 HNTELCO S.A, HN 64511 DOCUMENT 66.154.208.0/21 32522 MULTNOMAH-ESD - Multnomah Educ 64511 DOCUMENT 66.154.216.0/23 32522 MULTNOMAH-ESD - Multnomah Educ 64511 DOCUMENT 66.154.218.0/24 32522 MULTNOMAH-ESD - Multnomah Educ 65550 DOCUMENT 81.8.34.0/24 15924 BORUSANTELEKOM-AS, TR 65550 DOCUMENT 81.8.35.0/24 15924 BORUSANTELEKOM-AS, TR 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 64339 UNALLOCATED 143.0.108.0/22 18747 IFX18747 - IFX Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.100.7.0/24 56096 UNKNOWN 27.126.156.0/22 55827 UNKNOWN 27.126.156.0/23 55827 UNKNOWN 27.126.158.0/23 55827 UNKNOWN 36.255.24.0/24 40676 AS40676 - Psychz Networks, US 36.255.25.0/24 40676 AS40676 - Psychz Networks, US 36.255.26.0/24 40676 AS40676 - Psychz Networks, US 36.255.27.0/24 40676 AS40676 - Psychz Networks, US 41.76.136.0/22 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:10 /9:11 /10:38 /11:100 /12:294 /13:569 /14:1130 /15:1900 /16:13257 /17:8030 /18:13913 /19:25827 /20:40388 /21:47231 /22:95528 /23:77194 /24:436220 /25:898 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 4452 5507 UNI2-AS, ES 6327 3353 3564 SHAW - Shaw Communications Inc., CA 7155 3156 4064 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 3780 ALJAWWALSTC-AS, SA 11492 2885 3681 CABLEONE - CABLE ONE, INC., US 8551 2779 3326 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2677 3445 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 11830 2036 2688 Instituto Costarricense de Electricidad y Telec 18566 1989 2094 MEGAPATH5-US - MegaPath Corporation, US 30036 1914 2163 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1713 2:1071 3:6 4:21 5:3086 6:47 7:1 8:1340 9:1 12:1804 13:388 14:2078 15:41 16:7 17:259 18:80 20:56 23:2827 24:2588 25:4 27:2440 31:2012 32:106 35:38 36:883 37:3103 38:1796 39:294 40:121 41:3194 42:828 43:2076 44:157 45:9145 46:3362 47:265 49:1363 50:1105 51:337 52:1010 54:273 55:676 56:6 57:47 58:1746 59:1096 60:558 61:2179 62:1970 63:1854 64:5011 65:2227 66:4823 67:2770 68:1177 69:3577 70:1384 71:659 72:2652 74:2726 75:1295 76:571 77:1802 78:1869 79:2368 80:1840 81:1497 82:1142 83:945 84:1148 85:2307 86:547 87:1537 88:1047 89:2554 90:212 91:6595 92:1442 93:2472 94:2489 95:3333 96:948 97:340 98:962 99:806 100:88 101:1186 102:589 103:21776 104:3626 105:278 106:805 107:1783 108:696 109:3790 110:1731 111:2015 112:1535 113:1399 114:1277 115:1729 116:1756 117:1948 118:2183 119:1650 120:1056 121:1063 122:2281 123:1796 124:1502 125:2028 128:1365 129:848 130:549 131:1824 132:791 133:221 134:1087 135:251 136:589 137:789 138:2095 139:896 140:614 141:890 142:781 143:1083 144:877 145:276 146:1301 147:838 148:1756 149:1001 150:784 151:1015 152:1101 153:341 154:4416 155:892 156:1755 157:1052 158:690 159:1947 160:1601 161:957 162:2974 163:829 164:1249 165:1171 166:519 167:1423 168:3483 169:480 170:4207 171:614 172:1689 173:2220 174:1040 175:989 176:2444 177:4062 178:2564 179:1394 180:2144 181:2347 182:2754 183:1106 184:2281 185:15400 186:3664 187:2510 188:2992 189:2014 190:8205 191:1461 192:10070 193:6760 194:5524 195:4178 196:3060 197:1717 198:5937 199:5978 200:7144 201:5133 202:10403 203:10244 204:4549 205:3063 206:3225 207:3256 208:3949 209:4292 210:3936 211:2027 212:3133 213:2964 214:1133 215:55 216:5911 217:2233 218:883 219:600 220:1921 221:970 222:976 223:1396 End of report From dougb at dougbarton.us Sat Jul 27 03:57:34 2019 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 26 Jul 2019 20:57:34 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> <1013050297.821261.1563683148385.JavaMail.zimbra@baylink.com> <822B49BC-214D-45AE-979D-BFE0B540F55F@delong.com> <02148adc7cfe4952ac1a3c800a3cdd24@medline.com> Message-ID: On 2019-07-23 10:43 AM, William Herrin wrote: > On Tue, Jul 23, 2019 at 7:32 AM Naslund, Steve > wrote: > > In defense of John and ARIN, if you did not recognize that ARDC > represented an authority for this resource, who would be? > > > The American Radio Relay League (ARRL) is THE organization which > represents Hams in regulatory matters in the U.S. and is well known to > Hams worldwide. > > You don't have to look very far. Just ask any ham. The Internet, and amateur radio, both transcend the US. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Sat Jul 27 04:19:50 2019 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 26 Jul 2019 21:19:50 -0700 Subject: Feasibility of using Class E space for public unicast (was re: 44/8) In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> Message-ID: On 2019-07-22 6:09 PM, Owen DeLong wrote: >> On Jul 22, 2019, at 12:15 , Naslund, Steve > > wrote: >> >> I think the Class E block has been covered before.  There were two >> reasons to not re-allocate it. >> 1.A lot of existing code base does not know how to handle those >> addresses and may refuse to route them or will otherwise mishandle them. >> 2.It was decided that squeezing every bit of space out of the v4 >> allocations only served to delay the desired v6 deployment. > > > Close, but there is a subtle error… > > 2.It was decided that the effort to modify each and every IP stack in > order to facilitate use of this relatively small block (16 /8s being > evaluated against a global > run rate at the time of roughly 2.5 /8s per month, mostly to RIPE and > APNIC) vs. putting that same effort into modifying each and every IP > stack to support > IPv6 was an equation of very small benefit for slightly smaller cost. > (Less than 8 additional months of IPv4 free pool vs. hopefully making > IPv6 deployable > before IPv4 ran out). All of this, plus what Fred Baker said upthread. When I was running the IANA in the early 2000's we discussed this issue with many different experts, hardware company reps, etc. Not only was there a software issue that was insurmountable for all practical purposes (pretty much every TCP/IP stack has "Class E space is not unicast" built in), in the case of basically all network hardware, this limitation is also in the silicon. So even if it were possible to fix the software issue, it would not be possible to fix the hardware issue without replacing pretty much all the hardware. ... and even if some magical forces appeared and gave every open source software project, and every company, and every consumer in the developed world the means and opportunity to do all of the above; doing so would have left the developing world out in the cold, since in many cases there is reliance on older, second/third/fourth hand equipment that they could never afford to replace. So the decision was made to start tooting the IPv4 runout horns in the hopes that folks would start taking conservation of the space seriously (which happened more often than not), and accelerate the adoption of IPv6. *cough* Personally, I also pushed to bring IPv6 support from ICANN up to par, including going the last mile on putting the IPv6 addresses of the root servers in the zone, creating and socializing a long-term plan for allocating to the RIRs, etc. So no, there were exactly zero "IPv6 loons" involved in this decision. :-) Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Sat Jul 27 04:59:45 2019 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 26 Jul 2019 21:59:45 -0700 Subject: 44/8 In-Reply-To: <20190719025758.GB29374@puck.nether.net> References: <20190719025758.GB29374@puck.nether.net> Message-ID: Responding to no one in particular, and not representing views of any current or former employer ... I find all of this hullabaloo to be ... fascinating. A little background to frame my comments below. I was GM of the IANA in the early 2000's, I held a tech license from 1994 through 2004 (I gave it up because life changed, and I no longer had time; but I still have all my toys, err, I mean, gear); and I have known two of the ARDC board members and one of the advisors listed at https://www.ampr.org/amprnet/ for over fifteen years. I consider them all friends, and trust their judgement explicitly. One of them I've known for over 20 years, and consider a close and very dear friend. There have been a number of points over the past 30 years where anyone who genuinely cared about this space could have used any number of mechanisms to raise concerns over how it's been managed, and by whom. I cannot help but think that some of this current sound and fury is an excuse to express righteous indignation for its own sake. The folks involved with ARDC have been caring for the space for a long time. From my perspective, seeing the writing on the wall regarding the upcoming friction around IPv4 space as an asset with monetary value increasing exponentially, they took quite reasonable steps to create a legal framework to ensure that their ability to continue managing the space would be protected. Some of you may remember that other groups, like the IETF, were taking similar steps before during and after that same time frame. Sure, you can complain about what was done, how it was done, etc.; but where were you then? Are you sure that at least part of your anger isn't due to the fact that all of these things have happened over the last 20 years, and you had no idea they were happening? So let's talk a little about what "stewardship" means. Many folks have complained about how ARDC has not done a good job of $X function that stewards of the space should perform. Do you think having some money in the bank will help contribute to their ability to do that? Has anyone looked at how much of the space is actually being used now, and what percentage reduction in available space carving out a /10 actually represents? And nowadays when IPv6 is readily available essentially "for free," how much is the amateur community actually being affected by this? And with all due respect to Jon (and I mean that sincerely), what did it/does it really mean that "Jon gave $PERSON the space for $REASON" 30 years later? Jon was a brilliant guy, but from what I've been told would also be one of the first to admit when he made a mistake. One of which, and one that he actively campaigned to fix, was the idea of classful address space to start with, and particularly the idea that it was OK to hand out massive chunks of it to anyone who asked. As a former ham I definitely appreciate the concept of them having space to play ... errr, experiment with. But did they ever, /really, /need a /8? Historically, what percentage of that space has ever actually been used? And as Dave Conrad pointed out, given all of the "historical" allocations that have been revisited and/or repurposed already, is taking another look at 44/8 really that far out of line? Now all that said, if any of my friends had asked me how I thought news of this sale should have been handled, I would have told them that this reaction that we're seeing now is 100% predictable, and while it could never be eliminated entirely it could be limited in scope and ferocity by getting ahead of the message. At minimum when the transfer occurred. But that doesn't change anything about my opinion that the sale itself was totally reasonable, done by reasonable people, and in keeping with the concept of being good stewards of the space. hope this helps, Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat Jul 27 05:07:27 2019 From: bill at herrin.us (William Herrin) Date: Fri, 26 Jul 2019 22:07:27 -0700 Subject: Feasibility of using Class E space for public unicast (was re: 44/8) In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> Message-ID: On Fri, Jul 26, 2019 at 9:21 PM Doug Barton wrote: > When I was running the IANA in the early 2000's we discussed this issue with many different experts, hardware company reps, etc. Not only was there a software issue that was insurmountable for all practical purposes (pretty much every TCP/IP stack has "Class E space is not unicast" built in), in the case of basically all network hardware, this limitation is also in the silicon. So even if it were possible to fix the software issue, it would not be possible to fix the hardware issue without replacing pretty much all the hardware. > So the decision was made to start tooting the IPv4 runout horns in the hopes that folks would start taking conservation of the space seriously (which happened more often than not), and accelerate the adoption of IPv6. *cough* Hi Doug, That's what you wrote. Here's what I read: "We decided keep this mile of road closed because you can't drive it anywhere unless the toll road operators in the next 10 miles open their roads too. What's that you say? Your house is a quarter mile down this road?** La la la I can't hear you. Look, just use the shiny new road we built over in the next state instead. Move your house there. The roads are better." ** Not every unicast use of 240/4 would require broad adoption of the change. Your reasoning that it does is so absurd as to merit outright mockery. > So no, there were exactly zero "IPv6 loons" involved in this decision. :-) No, when I said IPv6 loonies, reasoning of this character was pretty much what I was talking about. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Sat Jul 27 05:36:30 2019 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 26 Jul 2019 22:36:30 -0700 Subject: Feasibility of using Class E space for public unicast (was re: 44/8) In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> Message-ID: <0d099667-46dd-4c89-6e1e-af4d4d5a0257@dougbarton.us> On 2019-07-26 10:07 PM, William Herrin wrote: > On Fri, Jul 26, 2019 at 9:21 PM Doug Barton > wrote: > > When I was running the IANA in the early 2000's we discussed this > issue with many different experts, hardware company reps, etc. Not > only was there a software issue that was insurmountable for all > practical purposes (pretty much every TCP/IP stack has "Class E space > is not unicast" built in), in the case of basically all network > hardware, this limitation is also in the silicon. So even if it were > possible to fix the software issue, it would not be possible to fix > the hardware issue without replacing pretty much all the hardware. > > > So the decision was made to start tooting the IPv4 runout horns in > the hopes that folks would start taking conservation of the space > seriously (which happened more often than not), and accelerate the > adoption of IPv6. *cough* > > Hi Doug, > > That's what you wrote. Here's what I read: > > "We decided keep this mile of road closed because you can't drive it > anywhere unless the toll road operators in the next 10 miles open > their roads too. What's that you say? Your house is a quarter mile > down this road?** La la la I can't hear you. Look, just use the shiny > new road we built over in the next state instead. Move your house > there. The roads are better." > > ** Not every unicast use of 240/4 would require broad adoption of the > change. Your reasoning that it does is so absurd as to merit outright > mockery. > > > So no, there were exactly zero "IPv6 loons" involved in this > decision. :-) > > No, when I said IPv6 loonies, reasoning of this character was pretty > much what I was talking about. So leaving aside how interesting I find the fact that you snipped the part of my comments that you did, the utter absurdity of your toll road analogy shows me that I will not be able to convince you of anything. So I'll just say this ... if you think that the advice I received from all of the many people I spoke to (all of whom are/were a lot smarter than me on this topic) was wrong, and that putting the same LOE into IPv6 adoption that it would have taken to make Class E usable was a better investment because we're not running out of IPv6 any time soon, then you have a golden opportunity. Go forth and prove me wrong. Go rally support from all of the people and companies that you need in order to make any part of  Class E usable for any purpose (even, as you point it, if it's not for global unicast). If you're right, and I'm wrong, your income potential is essentially limitless. Or, look at it from another perspective. If you're right, then why, in the last almost 15 years, has no one figured out how to do it yet? Including the companies whose mission is to sell us new hardware, and force us into contracts for software upgrades in order to keep said hardware on the 'net? It's easy to sit back in the cheap seats and squawk about how "they" are out to get you. I'd be far more impressed if you put your money (or time, or effort) where your mouth is. Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat Jul 27 06:01:06 2019 From: bill at herrin.us (William Herrin) Date: Fri, 26 Jul 2019 23:01:06 -0700 Subject: Feasibility of using Class E space for public unicast (was re: 44/8) In-Reply-To: <0d099667-46dd-4c89-6e1e-af4d4d5a0257@dougbarton.us> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> <0d099667-46dd-4c89-6e1e-af4d4d5a0257@dougbarton.us> Message-ID: On Fri, Jul 26, 2019 at 10:36 PM Doug Barton wrote: > So I'll just say this ... if you think that the advice I received from all of the many people I spoke to (all of whom are/were a lot smarter than me on this topic) was wrong, and that putting the same LOE into IPv6 adoption that it would have taken to make Class E usable was a better investment Doug, "Better investment?" What on earth makes you think it's a zero-sum game? "Same level of effort?" A reasonable level of effort was adding the word "unicast" to the word "reserved" in the standards. Seven letters. A space. Maybe a comma. That would have unblocked everybody else to apply however much or little effort they cared to. Here we are nearly 20 years later and had you not fumbled that ball 240/4 might be broadly enough supported to usefully replace the word "reserved" with something else. You're right about one thing: you won't be able to convince me that your conclusion was rational. No matter how many smart people say a stupid thing, it's still a stupid thing. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Sat Jul 27 18:11:40 2019 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 27 Jul 2019 11:11:40 -0700 Subject: Feasibility of using Class E space for public unicast (was re: 44/8) In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> <0d099667-46dd-4c89-6e1e-af4d4d5a0257@dougbarton.us> Message-ID: <04bb0cfd-c9dd-a6cb-8c1b-c179f5c9bfaf@dougbarton.us> On 2019-07-26 11:01 PM, William Herrin wrote: > On Fri, Jul 26, 2019 at 10:36 PM Doug Barton > wrote: > > So I'll just say this ... if you think that the advice I received > from all of the many people I spoke to (all of whom are/were a lot > smarter than me on this topic) was wrong, and that putting the same > LOE into IPv6 adoption that it would have taken to make Class E usable > was a better investment > > Doug, > > "Better investment?" What on earth makes you think it's a zero-sum game? Because for all of us there are only 24 hours in a day, and the people who would have needed to do the work to make it happen were telling me that they were going to put the work into IPv6 instead, because it has a future. As Owen pointed out, no matter how much IPv4 space you added, all it would do would be delay the inevitable. > "Same level of effort?" A reasonable level of effort was adding the > word "unicast" to the word "reserved" in the standards. Seven letters. > A space. Maybe a comma. I don't recall seeing your draft on that .... refresh my memory? > That would have unblocked everybody else to apply however much or > little effort they cared to. Here we are nearly 20 years later and had > you not fumbled that ball 240/4 might be broadly enough supported to > usefully replace the word "reserved" with something else. You give me /way /too much credit on that. I was the reed tasting the wind on this topic. I was not the wind. I (like every other IANA manager) had exactly zero authority to say, "You SHALL NOT pursue making Class E space usable for anything!" The opportunity existed then, and still exists today, for anyone to make it work. > You're right about one thing: you won't be able to convince me that > your conclusion was rational. No matter how many smart people say a > stupid thing, it's still a stupid thing. So as my last word on the topic, I return you to the point above, that whatever the discussion was 20 years ago, there is still no workable solution. If you'd like another perspective, here is a reasonably good summary: https://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/ Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Sat Jul 27 18:46:41 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Sat, 27 Jul 2019 14:46:41 -0400 Subject: Feasibility of using Class E space for public unicast (was re: 44/8) In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> Message-ID: <23868.39953.398906.559231@gargle.gargle.HOWL> On July 26, 2019 at 21:19 dougb at dougbarton.us (Doug Barton) wrote: > All of this, plus what Fred Baker said upthread. > > When I was running the IANA in the early 2000's we discussed this issue with > many different experts, hardware company reps, etc. Not only was there a > software issue that was insurmountable for all practical purposes (pretty much > every TCP/IP stack has "Class E space is not unicast" built in), in the case of > basically all network hardware, this limitation is also in the silicon. So even > if it were possible to fix the software issue, it would not be possible to fix > the hardware issue without replacing pretty much all the hardware. > Not particularly interested in arguing for using Class E space but this "not compatible" reasoning would seem to have applied to IPv6 in the early 2000s (whatever, pick an earlier date when little supported IPv6) just as well, pretty much. So in and of itself it's not a show-stopper. Just a matter of whether there's an overall positive ROI. -- -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 Sat Jul 27 19:50:54 2019 From: johnl at iecc.com (johnl at iecc.com) Date: 27 Jul 2019 19:50:54 -0000 Subject: Feasibility of using Class E space for public unicast (was re: 44/8) In-Reply-To: <23868.39953.398906.559231@gargle.gargle.HOWL> References: <21bcd8c1664140e8938597439f49d19b@medline.com> <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <20190727195054.34050.qmail@submit.iecc.com> In article <23868.39953.398906.559231 at gargle.gargle.HOWL> you write: >Not particularly interested in arguing for using Class E space but >this "not compatible" reasoning would seem to have applied to IPv6 in >the early 2000s (whatever, pick an earlier date when little supported >IPv6) just as well, pretty much. Right. A point that's been made about a hundred times already is that the effort to add class E to the IPv4 space is the same as the effort to support IPv6, so why waste time with class E? R's, John From randy at psg.com Sat Jul 27 21:18:37 2019 From: randy at psg.com (Randy Bush) Date: Sat, 27 Jul 2019 14:18:37 -0700 Subject: Feasibility of using Class E space for public unicast (was re: 44/8) In-Reply-To: <23868.39953.398906.559231@gargle.gargle.HOWL> References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> <23868.39953.398906.559231@gargle.gargle.HOWL> Message-ID: something is broken on the nanog list. usually we have this discussion twice a year. this time it may have been a couple of years gap. what broke? randy From list at satchell.net Sat Jul 27 22:07:55 2019 From: list at satchell.net (Stephen Satchell) Date: Sat, 27 Jul 2019 15:07:55 -0700 Subject: Feasibility of using Class E space for public unicast (was re: 44/8) In-Reply-To: References: <5d35f4e8.1c69fb81.63422.3838SMTPIN_ADDED_MISSING@mx.google.com> <21bcd8c1664140e8938597439f49d19b@medline.com> <23868.39953.398906.559231@gargle.gargle.HOWL> Message-ID: <60415240-0b29-d200-52a2-1efc46d7155c@satchell.net> On 7/27/19 2:18 PM, Randy Bush wrote: > something is broken on the nanog list. usually we have this discussion > twice a year. this time it may have been a couple of years gap. what > broke? 44/8. Sucked up all the oxygen. From goemon at sasami.anime.net Mon Jul 29 23:03:10 2019 From: goemon at sasami.anime.net (Dan Hollis) Date: Mon, 29 Jul 2019 16:03:10 -0700 (PDT) Subject: really amazon? Message-ID: Amazon, you really should know better. Source ip: 54.240.4.4 https://search.arin.net/rdap/?query=54.240.4.4 Source Registry ARIN Kind Group Full Name Amazon SES Abuse Handle ASA152-ARIN Email email-abuse at amazon.com >>> RCPT To: <<< 550 #5.1.0 Address rejected. 550 5.1.1 ... User unknown >>> DATA <<< 503 #5.5.1 RCPT first Jul 29 09:47:27 yuri sendmail[14067]: x6TGlQe4014062: to=, ctladdr= (500/500), delay=00:00:01, xdelay=00:00:01, mailer=esmtp92, relay=amazon-smtp.amazon.com. [207.171.188.4], dsn=5.1.1, stat=User unknown From mel at beckman.org Mon Jul 29 23:07:14 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 29 Jul 2019 23:07:14 +0000 Subject: really amazon? In-Reply-To: References: Message-ID: Dan, I don’t really have the time to parse the debug output you sent. If you want me, or most others, to pay attention to your post, please provide a more detailed explanation of what the deal is than “Really, amazon?” -mel > On Jul 29, 2019, at 4:03 PM, Dan Hollis wrote: > > Amazon, you really should know better. > > Source ip: 54.240.4.4 > > https://search.arin.net/rdap/?query=54.240.4.4 > > Source Registry ARIN > Kind Group > Full Name Amazon SES Abuse > Handle ASA152-ARIN > Email email-abuse at amazon.com > >>>> RCPT To: > <<< 550 #5.1.0 Address rejected. > 550 5.1.1 ... User unknown >>>> DATA > <<< 503 #5.5.1 RCPT first > > Jul 29 09:47:27 yuri sendmail[14067]: x6TGlQe4014062: to=, ctladdr= (500/500), delay=00:00:01, xdelay=00:00:01, mailer=esmtp92, relay=amazon-smtp.amazon.com. [207.171.188.4], dsn=5.1.1, stat=User unknown From john at essenz.com Mon Jul 29 23:11:46 2019 From: john at essenz.com (John Von Essen) Date: Mon, 29 Jul 2019 19:11:46 -0400 Subject: really amazon? In-Reply-To: References: Message-ID: <5C3450E0-BF62-49F4-8B81-D94C061890F0@essenz.com> Really??? You cant parse “User unknown”... Dan is simply pointed out how ridiculous it is that amazon lists a non-existent email address with Arin for abuse. So yeah... really amazon? Sent from my iPhone > On Jul 29, 2019, at 7:07 PM, Mel Beckman wrote: > > Dan, > > I don’t really have the time to parse the debug output you sent. If you want me, or most others, to pay attention to your post, please provide a more detailed explanation of what the deal is than “Really, amazon?” > > -mel > > >> On Jul 29, 2019, at 4:03 PM, Dan Hollis wrote: >> >> Amazon, you really should know better. >> >> Source ip: 54.240.4.4 >> >> https://search.arin.net/rdap/?query=54.240.4.4 >> >> Source Registry ARIN >> Kind Group >> Full Name Amazon SES Abuse >> Handle ASA152-ARIN >> Email email-abuse at amazon.com >> >>>>> RCPT To: >> <<< 550 #5.1.0 Address rejected. >> 550 5.1.1 ... User unknown >>>>> DATA >> <<< 503 #5.5.1 RCPT first >> >> Jul 29 09:47:27 yuri sendmail[14067]: x6TGlQe4014062: to=, ctladdr= (500/500), delay=00:00:01, xdelay=00:00:01, mailer=esmtp92, relay=amazon-smtp.amazon.com. [207.171.188.4], dsn=5.1.1, stat=User unknown > From mel at beckman.org Mon Jul 29 23:12:52 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 29 Jul 2019 23:12:52 +0000 Subject: really amazon? In-Reply-To: <5C3450E0-BF62-49F4-8B81-D94C061890F0@essenz.com> References: , <5C3450E0-BF62-49F4-8B81-D94C061890F0@essenz.com> Message-ID: <28A45BEF-E629-41E8-92CF-95F29471C29A@beckman.org> So why not just say so? -mel > On Jul 29, 2019, at 4:12 PM, John Von Essen wrote: > > Really??? You cant parse “User unknown”... > > Dan is simply pointed out how ridiculous it is that amazon lists a non-existent email address with Arin for abuse. > > So yeah... really amazon? > > Sent from my iPhone > >> On Jul 29, 2019, at 7:07 PM, Mel Beckman wrote: >> >> Dan, >> >> I don’t really have the time to parse the debug output you sent. If you want me, or most others, to pay attention to your post, please provide a more detailed explanation of what the deal is than “Really, amazon?” >> >> -mel >> >> >>> On Jul 29, 2019, at 4:03 PM, Dan Hollis wrote: >>> >>> Amazon, you really should know better. >>> >>> Source ip: 54.240.4.4 >>> >>> https://search.arin.net/rdap/?query=54.240.4.4 >>> >>> Source Registry ARIN >>> Kind Group >>> Full Name Amazon SES Abuse >>> Handle ASA152-ARIN >>> Email email-abuse at amazon.com >>> >>>>>> RCPT To: >>> <<< 550 #5.1.0 Address rejected. >>> 550 5.1.1 ... User unknown >>>>>> DATA >>> <<< 503 #5.5.1 RCPT first >>> >>> Jul 29 09:47:27 yuri sendmail[14067]: x6TGlQe4014062: to=, ctladdr= (500/500), delay=00:00:01, xdelay=00:00:01, mailer=esmtp92, relay=amazon-smtp.amazon.com. [207.171.188.4], dsn=5.1.1, stat=User unknown >> > From goemon at sasami.anime.net Mon Jul 29 23:19:15 2019 From: goemon at sasami.anime.net (Dan Hollis) Date: Mon, 29 Jul 2019 16:19:15 -0700 (PDT) Subject: really amazon? In-Reply-To: References: Message-ID: "User unknown" is pretty clear. But whatever. -Dan On Mon, 29 Jul 2019, Mel Beckman wrote: > Dan, > > I don’t really have the time to parse the debug output you sent. If you want me, or most others, to pay attention to your post, please provide a more detailed explanation of what the deal is than “Really, amazon?” > > -mel > > >> On Jul 29, 2019, at 4:03 PM, Dan Hollis wrote: >> >> Amazon, you really should know better. >> >> Source ip: 54.240.4.4 >> >> https://search.arin.net/rdap/?query=54.240.4.4 >> >> Source Registry ARIN >> Kind Group >> Full Name Amazon SES Abuse >> Handle ASA152-ARIN >> Email email-abuse at amazon.com >> >>>>> RCPT To: >> <<< 550 #5.1.0 Address rejected. >> 550 5.1.1 ... User unknown >>>>> DATA >> <<< 503 #5.5.1 RCPT first >> >> Jul 29 09:47:27 yuri sendmail[14067]: x6TGlQe4014062: to=, ctladdr= (500/500), delay=00:00:01, xdelay=00:00:01, mailer=esmtp92, relay=amazon-smtp.amazon.com. [207.171.188.4], dsn=5.1.1, stat=User unknown > > From sc at ottie.org Tue Jul 30 09:44:51 2019 From: sc at ottie.org (Scott Christopher) Date: Tue, 30 Jul 2019 12:44:51 +0300 Subject: really amazon? In-Reply-To: References: Message-ID: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> Dan Hollis wrote: > >>> RCPT To: > <<< 550 #5.1.0 Address rejected. > 550 5.1.1 ... User unknown > >>> DATA > <<< 503 #5.5.1 RCPT first Try jeff at amazon.com -- S.C. From savage at savage.za.org Tue Jul 30 09:59:35 2019 From: savage at savage.za.org (Chris Knipe) Date: Tue, 30 Jul 2019 11:59:35 +0200 Subject: really amazon? In-Reply-To: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> Message-ID: On Tue, Jul 30, 2019 at 11:45 AM Scott Christopher wrote: > Dan Hollis wrote: > > > >>> RCPT To: > > <<< 550 #5.1.0 Address rejected. > > 550 5.1.1 ... User unknown > > >>> DATA > > <<< 503 #5.5.1 RCPT first > > Try jeff at amazon.com > > -- > S.C. > Then update your ARIN records to reflect that. Fully agree with Dan on this one. -- Regards, Chris Knipe -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoffer at netravnen.de Tue Jul 30 10:19:05 2019 From: christoffer at netravnen.de (Christoffer Hansen) Date: Tue, 30 Jul 2019 12:19:05 +0200 Subject: User Unknown (WAS: really amazon?) In-Reply-To: References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> Message-ID: <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> On 30/07/2019 11:59, Chris Knipe wrote: > On Tue, Jul 30, 2019 at 11:45 AM Scott Christopher wrote: >> Dan Hollis wrote: >>> >>> RCPT To: >>> <<< 550 #5.1.0 Address rejected. >>> 550 5.1.1 ... User unknown >>> >>> DATA >>> <<< 503 #5.5.1 RCPT first >> >> Try jeff () amazon >> > Then update your ARIN records to reflect that. Fully agree with Dan on > this one. > Imagine ARIN did a take from RIPE NCC [Policy Proposal Idea?] and a policy came into effect of validating ALL 'OrgAbuseEmail' objects listed in the ARIN database. And revoked the resources from those that failed to respond after multiple attempts. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From sc at ottie.org Tue Jul 30 10:44:37 2019 From: sc at ottie.org (Scott Christopher) Date: Tue, 30 Jul 2019 13:44:37 +0300 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> Message-ID: <8fda3f1b-6e71-4bb7-9701-4b70a4813c55@www.fastmail.com> Christoffer Hansen wrote: > On 30/07/2019 11:59, Chris Knipe wrote: > > > Then update your ARIN records to reflect that. Fully agree with Dan on > > this one. > > > > Imagine ARIN did a take from RIPE NCC [Policy Proposal Idea?] and a > policy came into effect of validating ALL 'OrgAbuseEmail' objects listed > in the ARIN database. And revoked the resources from those that failed > to respond after multiple attempts. Then imagine the media attention, public outcry, corporate lawyers from Amazon, the pressure from Congress, and an ARIN that would no longer function as an independent body anymore. . . -- S.C. From mattlists at rivervalleyinternet.net Tue Jul 30 11:18:27 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Tue, 30 Jul 2019 07:18:27 -0400 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <8fda3f1b-6e71-4bb7-9701-4b70a4813c55@www.fastmail.com> References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> <8fda3f1b-6e71-4bb7-9701-4b70a4813c55@www.fastmail.com> Message-ID: <9F5D0E2F-190F-4A26-B30F-58AF79757D9D@rivervalleyinternet.net> I thought it was already a requirement that the POC info had to be validated once a year and accurate? > On Jul 30, 2019, at 6:44 AM, Scott Christopher wrote: > > Christoffer Hansen wrote: > >>> On 30/07/2019 11:59, Chris Knipe wrote: >>> >>> Then update your ARIN records to reflect that. Fully agree with Dan on >>> this one. >>> >> >> Imagine ARIN did a take from RIPE NCC [Policy Proposal Idea?] and a >> policy came into effect of validating ALL 'OrgAbuseEmail' objects listed >> in the ARIN database. And revoked the resources from those that failed >> to respond after multiple attempts. > > Then imagine the media attention, public outcry, corporate lawyers from Amazon, the pressure from Congress, and an ARIN that would no longer function as an independent body anymore. . . > > -- > S.C. From christoffer at netravnen.de Tue Jul 30 11:47:29 2019 From: christoffer at netravnen.de (Christoffer Hansen) Date: Tue, 30 Jul 2019 13:47:29 +0200 Subject: really amazon? In-Reply-To: References: Message-ID: <4266165c-cf4e-0ae1-a222-8bec09eb77b1@netravnen.de> On 30/07/2019 01:03, Dan Hollis wrote: > Jul 29 09:47:27 yuri sendmail[14067]: x6TGlQe4014062: > to=, ctladdr= > (500/500), delay=00:00:01, xdelay=00:00:01, mailer=esmtp92, > relay=amazon-smtp.amazon.com. [207.171.188.4], dsn=5.1.1, stat=User unknown ... :wondering: Works fine for me. If sending from $CORP e-mail account hosted on O365 infrastructure. Christoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From robert at mckay.com Tue Jul 30 11:56:11 2019 From: robert at mckay.com (Robert McKay) Date: Tue, 30 Jul 2019 12:56:11 +0100 Subject: really amazon? In-Reply-To: References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> Message-ID: On 2019-07-30 10:59, Chris Knipe wrote: > On Tue, Jul 30, 2019 at 11:45 AM Scott Christopher > wrote: > >> Dan Hollis wrote: >> >>>>>> RCPT To: >>> <<< 550 #5.1.0 Address rejected. >>> 550 5.1.1 ... User unknown >>>>>> DATA >>> <<< 503 #5.5.1 RCPT first >> >> Try jeff at amazon.com >> >> -- >> S.C. > > Then update your ARIN records to reflect that. Fully agree with Dan > on this one. Even if it existed it would just be an autoresponder telling you that your email wasn't read and to go resubmit the report on their website. Maybe they should change it to noreply at amazon.com. Rob From christoffer at netravnen.de Tue Jul 30 12:33:35 2019 From: christoffer at netravnen.de (Christoffer Hansen) Date: Tue, 30 Jul 2019 14:33:35 +0200 Subject: Not noreply autoresponder (WAS: really amazon?) In-Reply-To: References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> Message-ID: <2f4812f9-2af7-eb83-7279-c947b84d57e1@netravnen.de> On 30/07/2019 13:56, Robert McKay wrote: > Even if it existed it would just be an autoresponder telling you that > your email wasn't read and to go resubmit the report on their website. Both yes and now. See below:* """ We are sorry to hear that you received unwanted email through Amazon SES. Please note, this reporting address is only for mail sent via Amazon SES (emails originated from 54.240.0.0/18). If you have a complaint about other AWS abuse (e.g. EC2), please submit your complaint here: https://aws.amazon.com/forms/report-abuse If you did not provide the following information, please contact email-abuse at amazon.com again with: 1. The full headers of the objectionable email message. For examples of how to find email headers, see https://support.google.com/mail/answer/22454?hl=en . 2. The type of abuse you are experiencing. For example, you didn't sign up to receive emails from the sender, the sender doesn’t have an opt-out option, etc. Thank you for the report! Sincerely, The Amazon SES Team """ *) The contents I got back after firing Test E-mail from $CORP email account on O365 infrastructure. Christoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From ximaera at gmail.com Tue Jul 30 12:37:52 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Tue, 30 Jul 2019 15:37:52 +0300 Subject: really amazon? In-Reply-To: <28A45BEF-E629-41E8-92CF-95F29471C29A@beckman.org> References: <5C3450E0-BF62-49F4-8B81-D94C061890F0@essenz.com> <28A45BEF-E629-41E8-92CF-95F29471C29A@beckman.org> Message-ID: On Tue, Jul 30, 2019 at 2:15 AM Mel Beckman wrote: > So why not just say so? Because at the times of USENIX the very next reply to such a message would've been "what are the steps to reproduce your problem". -- Töma From jcurran at arin.net Tue Jul 30 12:55:57 2019 From: jcurran at arin.net (John Curran) Date: Tue, 30 Jul 2019 12:55:57 +0000 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <8fda3f1b-6e71-4bb7-9701-4b70a4813c55@www.fastmail.com> References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> <8fda3f1b-6e71-4bb7-9701-4b70a4813c55@www.fastmail.com> Message-ID: <9BA89F2A-6371-40E5-B7F7-2C69ABAD34EF@arin.net> On 30 Jul 2019, at 6:44 AM, Scott Christopher > wrote: On 30/07/2019 11:59, Chris Knipe wrote: Then update your ARIN records to reflect that. Fully agree with Dan on this one. Imagine ARIN did a take from RIPE NCC [Policy Proposal Idea?] and a policy came into effect of validating ALL 'OrgAbuseEmail' objects listed in the ARIN database. And revoked the resources from those that failed to respond after multiple attempts. Then imagine the media attention, public outcry, corporate lawyers from Amazon, the pressure from Congress, and an ARIN that would no longer function as an independent body anymore. . . Scott - Alas, you have a fundamental misunderstanding about the nature of ARIN… we don’t do anything other than implement policies that this community wants. If the community developed a policy to require Abuse POC’s validation, and said policy made clear that failure to do so was to result in revocation, then ARIN would indeed implement the policy (and that includes revocation for those who ignored the policy.) This is actually exactly the way the US Government asked us to operate in 1997 - "Creation of ARIN will give the users of IP numbers (mostly Internet service providers, corporations and other large institutions) a voice in the policies by which they are managed and allocated within the North American region.” . Further, this support was reiterated by the USG recently in 2012 - "The American Registry for Internet Numbers (ARIN) is the RIR for Canada, many Caribbean and North Atlantic islands, and the United States. The USG participates in the development of and is supportive of the policies, processes, and procedures agreed upon by the Internet technical community through ARIN.” We’ve see the lawyer route as well, and I have zero doubt in both the enforceability of the ARIN registration services agreements and ARIN’s ability to operate the registry according to the community policy. So, my advice is that this community not make policy that it doesn’t want to see implemented (and if you have interest or concern about ARIN policies, then I’d recommend get involved in their development – https://www.arin.net/get-involved/) i.e. the good news is that this community gets to decide how IP addresses are managed in the region (as opposed to some federal agency) – the consequence is that we really do manage the registry as directed by this community, so please try to avoid self-immolation if at all possible... Thanks! /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Tue Jul 30 13:02:58 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Tue, 30 Jul 2019 16:02:58 +0300 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> Message-ID: On Tue, Jul 30, 2019 at 1:20 PM Christoffer Hansen wrote: > Imagine ARIN did a take from RIPE NCC [Policy Proposal Idea?] and a > policy came into effect of validating ALL 'OrgAbuseEmail' objects listed > in the ARIN database. Just to be precise, such a policy (2019-04) is still in a discussion phase in RIPE and has already seen significant resistance. You can, however, point fingers at APNIC instead, where pretty much the same policy proposal from the same authors (prop-125) was already implemented in apnic-127-v006 "Internet Number Resource Policies". I think they will be planning to reach out to ARIN with the same text right after the RIPE process ends this way or another. -- Töma From jra at baylink.com Tue Jul 30 16:25:53 2019 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 30 Jul 2019 16:25:53 +0000 (UTC) Subject: really amazon? In-Reply-To: <4266165c-cf4e-0ae1-a222-8bec09eb77b1@netravnen.de> References: <4266165c-cf4e-0ae1-a222-8bec09eb77b1@netravnen.de> Message-ID: <729444261.881757.1564503953614.JavaMail.zimbra@baylink.com> ----- Original Message ----- > From: "Christoffer Hansen" > On 30/07/2019 01:03, Dan Hollis wrote: >> Jul 29 09:47:27 yuri sendmail[14067]: x6TGlQe4014062: >> to=, ctladdr= >> (500/500), delay=00:00:01, xdelay=00:00:01, mailer=esmtp92, >> relay=amazon-smtp.amazon.com. [207.171.188.4], dsn=5.1.1, stat=User unknown > > ... :wondering: Works fine for me. If sending from $CORP e-mail account > hosted on O365 infrastructure. Yup; I think that was most of his point: POC Email addresses MUST be whitelisted ahead of/through every protection device/software you deploy on incoming mail. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 From valdis.kletnieks at vt.edu Wed Jul 31 12:34:51 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 31 Jul 2019 08:34:51 -0400 Subject: User Unknown (WAS: really amazon?) In-Reply-To: References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> Message-ID: <16048.1564576491@turing-police> On Tue, 30 Jul 2019 16:02:58 +0300, T�ma Gavrichenkov said: > On Tue, Jul 30, 2019 at 1:20 PM Christoffer Hansen wrote: > > Imagine ARIN did a take from RIPE NCC [Policy Proposal Idea?] and a > > policy came into effect of validating ALL 'OrgAbuseEmail' objects listed > > in the ARIN database. > > Just to be precise, such a policy (2019-04) is still in a discussion > phase in RIPE and has already seen significant resistance. OK, I'll bite. What reasons are they giving for their resistance? (And if known, what are the *real* reasons if different?) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From ximaera at gmail.com Wed Jul 31 13:04:48 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 31 Jul 2019 16:04:48 +0300 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <16048.1564576491@turing-police> References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> <16048.1564576491@turing-police> Message-ID: On Wed, Jul 31, 2019 at 3:35 PM Valdis Klētnieks wrote: > > On Tue, 30 Jul 2019 16:02:58 +0300, Töma Gavrichenkov said: > > such a policy (2019-04) is still in a discussion > > phase in RIPE and has already seen significant resistance. > > OK, I'll bite. What reasons are they giving for their resistance? Here's a good place to start: https://ripe78.ripe.net/archives/steno/37/ ^F, "You're done", enjoy! -- Töma From ximaera at gmail.com Wed Jul 31 13:10:24 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 31 Jul 2019 16:10:24 +0300 Subject: User Unknown (WAS: really amazon?) In-Reply-To: References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> <16048.1564576491@turing-police> Message-ID: On Wed, Jul 31, 2019 at 4:04 PM Töma Gavrichenkov wrote: > > OK, I'll bite. What reasons are they giving for their resistance? > > Here's a good place to start: https://ripe78.ripe.net/archives/steno/37/ > ^F, "You're done", enjoy! P.S. Suddenly there's an important mistake in the transcript: the boiling frog argument was introduced by Piotr Strzyzewski (RIPE NCC Exec Board), not Petr Špaček (CZ.NIC). Slavic names are always a challenge for scribes (look up "grzegorz brzęczyszczykiewicz" on Youtube). -- Töma From rsk at gsp.org Wed Jul 31 13:53:04 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 31 Jul 2019 09:53:04 -0400 Subject: really amazon? In-Reply-To: References: Message-ID: <20190731135304.GA24763@gsp.org> Yes, this is egregious, but on the other hand even when the abuse reporting mechanisms are working my experience has been that they emit no response (other than -- maybe -- boilerplate) and take no action, so it's not terribly surprising. ---rsk From sc at ottie.org Wed Jul 31 14:17:34 2019 From: sc at ottie.org (Scott Christopher) Date: Wed, 31 Jul 2019 17:17:34 +0300 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <9BA89F2A-6371-40E5-B7F7-2C69ABAD34EF@arin.net> References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> <8fda3f1b-6e71-4bb7-9701-4b70a4813c55@www.fastmail.com> <9BA89F2A-6371-40E5-B7F7-2C69ABAD34EF@arin.net> Message-ID: <051f3329-e3c8-4965-93a0-c89a41731aa6@www.fastmail.com> John Curran wrote: > Scott - > > Alas, you have a fundamental misunderstanding about the nature of ARIN… we don’t do anything other than implement policies that this community wants. If the community developed a policy to require Abuse POC’s validation, and said policy made clear that failure to do so was to result in revocation, then ARIN would indeed implement the policy (and that includes revocation for those who ignored the policy.) Hello John - you are absolutely right. Since the community has shown overwhelming disapproval of Amazon's invalid abuse POC, please go ahead and revoke Amazon's resources. Maybe do this late Friday afternoon for the courtesy toward Amazon's support staff ? And since this will certainly be historic, please post an announcement to nanog-list ? Thanks, and Good luck ! S.C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SDombrosky at blackfoot.com Tue Jul 30 16:05:30 2019 From: SDombrosky at blackfoot.com (Shaun Dombrosky) Date: Tue, 30 Jul 2019 16:05:30 +0000 Subject: Estimated LTE Data Utilization in Failover Scenario Message-ID: <7E737E5CAF874540B47AAA561F038696A25CC1EA@EXCH2010.blackfoot.com> Good Morning, First time NANOG poster, apologies if I breach etiquette. Does anyone have any first-hand data on how much data a small-medium business (SMB) can expect to consume in a failover scenario over a 4G/LTE connection? Retail, under 50 head count, using PoS, maybe cloud accounting software, general internet activity, 8 hour time period. Wonder if anyone is using a Cradlepoint or SD-WAN solution that could pull a few quick numbers from a dashboard for me. I haven't had much luck in my searches. Appreciate any info anyone can provide. Thanks, Shaun Dombrosky Data Network Engineer [cid:image001.png at 01D546BC.019D2710] E: sdombrosky at blackfoot.com www.blackfoot.com Stay connected with Blackfoot: [cid:image001.png at 01D2A238.12101D80] [cid:image002.png at 01D2A238.12101D80] [cid:image003.png at 01D2A238.12101D80] [cid:image004.png at 01D2A238.12101D80] This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately reply to the sender by email notifying them of the error and delete the original and reply copies. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spointer at humdai.net Wed Jul 31 13:02:04 2019 From: spointer at humdai.net (Steve Pointer) Date: Wed, 31 Jul 2019 14:02:04 +0100 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <16048.1564576491@turing-police> References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> <16048.1564576491@turing-police> Message-ID: > OK, I'll bite. What reasons are they giving for their resistance? (And > if known, > what are the *real* reasons if different?) https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2018-October/thread.html -- Steve P From tnolen at internetpro.net Tue Jul 30 23:02:56 2019 From: tnolen at internetpro.net (Trey Nolen) Date: Tue, 30 Jul 2019 18:02:56 -0500 Subject: email delays from Google Message-ID: We have been experiencing delays / failures receiving email from domains hosted by Google and *only* domains hosted by Google. This is happening to customers for whom we host the authoritative DNS servers.   For some reason, Google is not able to look up the MX and/or A record *sometimes* from our servers. Customers are getting an error like this: --BEGIN DNS Error: 49391460 DNS type ‘mx’ lookup of responded with code NOERROR 49391460 DNS type ‘aaaa’ lookup of mail.internetpro.net . responded with code SERVFAIL 49391460 DNS type ‘a’ lookup of mail.internetpro.net . responded with code SERVFAIL --END In the above case, Google is saying they can't find our mail server.  There is no AAAA record, so that part is normal. However, we have other customers who are hosting their own mail servers or are using relay services such as Trend Micro who are also having a similar issue.  The only thing these customers have in common is our DNS and the fact that Google is trying to send email to them. I can query Google's public servers at 8.8.8.8 and 8.8.4.4 and they always give the correct answers, but it seems that internally, Google is unable to make these lookups.   Reaching out to their support agents online, the agents confirm that the correct entries are in place and that *some* of Google's servers can't do the resolution resulting in sporadic email delivery.  They suggest that we reach out to the DNS provider to find out why (Grrr) We've also had reports from customers that the failures seem to be location oriented with western US emails being held up and eastern US emails coming through.  I can't independently confirm that, though. A full 100% of the email delivery issues have been Google hosted domains.   It seems that every other ISP can do the lookups just fine, but getting in touch with someone at Google who can troubleshoot this is impossible for a small ISP like us. If anyone can point me to somone at Google who could help me out, I'd be very thankful. Trey Nolen From matt at netfire.net Wed Jul 31 14:44:06 2019 From: matt at netfire.net (Matt Harris) Date: Wed, 31 Jul 2019 09:44:06 -0500 Subject: Estimated LTE Data Utilization in Failover Scenario In-Reply-To: <7E737E5CAF874540B47AAA561F038696A25CC1EA@EXCH2010.blackfoot.com> References: <7E737E5CAF874540B47AAA561F038696A25CC1EA@EXCH2010.blackfoot.com> Message-ID: On Wed, Jul 31, 2019 at 9:21 AM Shaun Dombrosky wrote: > Good Morning, > > > > First time NANOG poster, apologies if I breach etiquette. > > > > Does anyone have any first-hand data on how much data a small-medium > business (SMB) can expect to consume in a failover scenario over a 4G/LTE > connection? Retail, under 50 head count, using PoS, maybe cloud accounting > software, general internet activity, 8 hour time period. Wonder if anyone > is using a Cradlepoint or SD-WAN solution that could pull a few quick > numbers from a dashboard for me. I haven’t had much luck in my searches. > > > > Appreciate any info anyone can provide. > > > > Thanks, > > > > *Shaun Dombrosky* > *Data Network Engineer* > > > > > > E: sdombrosky at blackfoot.com > > *www.blackfoot.com * > > > > Stay connected with Blackfoot: > > > > [image: cid:image001.png at 01D2A238.12101D80] > > [image: cid:image002.png at 01D2A238.12101D80] > > [image: cid:image003.png at 01D2A238.12101D80] > > [image: cid:image004.png at 01D2A238.12101D80] > > > > > > > *This e-mail and any files transmitted with it are confidential and are > intended solely for the use of the individual or entity to which they are > addressed. If you are not the intended recipient or the person responsible > for delivering the e-mail to the intended recipient, be advised that you > have received this e-mail in error and that any use, dissemination, > forwarding, printing, or copying of this e-mail is strictly prohibited. If > you have received this e-mail in error, please immediately reply to the > sender by email notifying them of the error and delete the original and > reply copies. Thank you.* > > > -- Matt Harris - Chief Security Officer Security, Compliance, and Engineering Main: +1-816-256-5446 Mobile: +1-908-590-9472 Email: matt at netfire.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Wed Jul 31 14:46:13 2019 From: matt at netfire.net (Matt Harris) Date: Wed, 31 Jul 2019 09:46:13 -0500 Subject: Estimated LTE Data Utilization in Failover Scenario In-Reply-To: <7E737E5CAF874540B47AAA561F038696A25CC1EA@EXCH2010.blackfoot.com> References: <7E737E5CAF874540B47AAA561F038696A25CC1EA@EXCH2010.blackfoot.com> Message-ID: On Wed, Jul 31, 2019 at 9:21 AM Shaun Dombrosky wrote: > Good Morning, > > > > First time NANOG poster, apologies if I breach etiquette. > > > > Does anyone have any first-hand data on how much data a small-medium > business (SMB) can expect to consume in a failover scenario over a 4G/LTE > connection? Retail, under 50 head count, using PoS, maybe cloud accounting > software, general internet activity, 8 hour time period. Wonder if anyone > is using a Cradlepoint or SD-WAN solution that could pull a few quick > numbers from a dashboard for me. I haven’t had much luck in my searches. > > > > Appreciate any info anyone can provide. > > > > Thanks, > Hey Shaun, I'd recommend pulling that data from the device normally facing their internet connection. Does it support netflow or even just basic snmp statistics that you could graph? Ostensibly the traffic level would be the same regardless of whether using an LTE backup connection or the primary internet connection unless you somehow prohibited certain traffic when on LTE. Ultimately though, your best bet is going to be to get real stats over the course of a couple of weeks and then you'll understand better the traffic patterns based on time of day, day of the week, etc, as well, as this is likely relevant. Good luck! -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake at ispn.net Wed Jul 31 16:03:11 2019 From: blake at ispn.net (Blake Hudson) Date: Wed, 31 Jul 2019 11:03:11 -0500 Subject: Estimated LTE Data Utilization in Failover Scenario In-Reply-To: References: <7E737E5CAF874540B47AAA561F038696A25CC1EA@EXCH2010.blackfoot.com> Message-ID: <09486b3f-4283-a1bc-bb49-539fd14c5e8a@ispn.net> Matt Harris wrote on 7/31/2019 9:46 AM: > On Wed, Jul 31, 2019 at 9:21 AM Shaun Dombrosky > > wrote: > > Good Morning, > > First time NANOG poster, apologies if I breach etiquette. > > Does anyone have any first-hand data on how much data a > small-medium business (SMB) can expect to consume in a failover > scenario over a 4G/LTE connection?  Retail, under 50 head count, > using PoS, maybe cloud accounting software, general internet > activity, 8 hour time period.  Wonder if anyone is using a > Cradlepoint or SD-WAN solution that could pull a few quick numbers > from a dashboard for me.  I haven’t had much luck in my searches. > > Appreciate any info anyone can provide. > > Thanks, > > > Hey Shaun, > I'd recommend pulling that data from the device normally facing their > internet connection. Does it support netflow or even just basic snmp > statistics that you could graph? Ostensibly the traffic level would be > the same regardless of whether using an LTE backup connection or the > primary internet connection unless you somehow prohibited certain > traffic when on LTE. Ultimately though, your best bet is going to be > to get real stats over the course of a couple of weeks and then you'll > understand better the traffic patterns based on time of day, day of > the week, etc, as well, as this is likely relevant. > > Good luck! > 100% agree with Matt. Something also to keep in mind is the SMB's peak data rates. The primary (I assume ethernet) uplink may have a sub 10ms latency and 100Mbps or greater data rate while the LTE connection is probably several times slower in terms of bandwidth and latency. If designing a failover connection, customer expectations may need to be managed: internet access may be up, but will be noticeably degraded when on LTE. A backup cable connection may be better for VoIP or other latency/jitter sensitive applications and of course anything that relies on a static IP (server, vpn, etc) will probably break if the primary connection is down. Would be a good idea to test the failover connection during a few different time periods to gauge employee experience. --Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at shawnritchie.com Wed Jul 31 16:37:22 2019 From: me at shawnritchie.com (Shawn Ritchie) Date: Wed, 31 Jul 2019 11:37:22 -0500 Subject: Estimated LTE Data Utilization in Failover Scenario In-Reply-To: <09486b3f-4283-a1bc-bb49-539fd14c5e8a@ispn.net> References: <7E737E5CAF874540B47AAA561F038696A25CC1EA@EXCH2010.blackfoot.com> <09486b3f-4283-a1bc-bb49-539fd14c5e8a@ispn.net> Message-ID: <5BDA8CE9-45DF-4A3D-8D29-BF25F34C3FEF@shawnritchie.com> > On Jul 31, 2019, at 11:03 AM, Blake Hudson wrote: > > Matt Harris wrote on 7/31/2019 9:46 AM: >> On Wed, Jul 31, 2019 at 9:21 AM Shaun Dombrosky > wrote: >> Good Morning, >> >> First time NANOG poster, apologies if I breach etiquette. >> >> Does anyone have any first-hand data on how much data a small-medium business (SMB) can expect to consume in a failover scenario over a 4G/LTE connection? Retail, under 50 head count, using PoS, maybe cloud accounting software, general internet activity, 8 hour time period. Wonder if anyone is using a Cradlepoint or SD-WAN solution that could pull a few quick numbers from a dashboard for me. I haven’t had much luck in my searches. >> >> Appreciate any info anyone can provide. >> >> Thanks, >> >> >> Hey Shaun, >> I'd recommend pulling that data from the device normally facing their internet connection. Does it support netflow or even just basic snmp statistics that you could graph? Ostensibly the traffic level would be the same regardless of whether using an LTE backup connection or the primary internet connection unless you somehow prohibited certain traffic when on LTE. Ultimately though, your best bet is going to be to get real stats over the course of a couple of weeks and then you'll understand better the traffic patterns based on time of day, day of the week, etc, as well, as this is likely relevant. >> >> Good luck! >> > 100% agree with Matt. Something also to keep in mind is the SMB's peak data rates. The primary (I assume ethernet) uplink may have a sub 10ms latency and 100Mbps or greater data rate while the LTE connection is probably several times slower in terms of bandwidth and latency. If designing a failover connection, customer expectations may need to be managed: internet access may be up, but will be noticeably degraded when on LTE. A backup cable connection may be better for VoIP or other latency/jitter sensitive applications and of course anything that relies on a static IP (server, vpn, etc) will probably break if the primary connection is down. Would be a good idea to test the failover connection during a few different time periods to gauge employee experience. > > —Blake Yep. We sell solutions, both Cradlepoint and SD-WAN-based, and a big part of it is going over with the customer “you can’t just fail over all your regular traffic; pick biz-critical functions and deny everything else or you’re going to a) be very unhappy with speeds/performance and b) be EVEN MORE unhappy with the overage bill”. Get some data over a regular work week or so of their traffic, preferably with some flow data so you know what kinds of traffic/apps are consuming the bandwidth. Have the customer ID which of those flows would be critical if the primary connectivity died; size the cell plan appropriately or, if that can’t be done due to data caps, make sure needed tunnels for backoffice-type stuff will even work over your particular solution, etc... help them figure out what else can be dropped in an emergency. Other thing to consider is that almost all US cell plans have a pretty small data cap, even “unlimited”, and our testing shows that just backend Cradlepoint or SD-WAN chatter can add up to a GB or 2 a billing cycle; need to make sure your configs explicitly block any cellular usage unless the primary connection has gone completely down. — Shawn -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrowc.lists at gmail.com Wed Jul 31 17:38:47 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 31 Jul 2019 13:38:47 -0400 Subject: email delays from Google In-Reply-To: References: Message-ID: Trey, the bees behind the hive say: "Please open an issue in this system: https://issuetracker.google.com/issues/new?component=191885" >From what I can tell there are other folk with similar problems so some triangulation on 'what is actually wrong here?' is in order. On Wed, Jul 31, 2019 at 10:28 AM Trey Nolen wrote: > > We have been experiencing delays / failures receiving email from domains > hosted by Google and *only* domains hosted by Google. > > This is happening to customers for whom we host the authoritative DNS > servers. For some reason, Google is not able to look up the MX and/or > A record *sometimes* from our servers. > > Customers are getting an error like this: > --BEGIN > DNS Error: 49391460 DNS type ‘mx’ lookup of > responded with code NOERROR 49391460 DNS type ‘aaaa’ lookup of > mail.internetpro.net . responded with code > SERVFAIL 49391460 DNS type ‘a’ lookup of mail.internetpro.net > . responded with code SERVFAIL > > --END > > In the above case, Google is saying they can't find our mail server. > There is no AAAA record, so that part is normal. > > However, we have other customers who are hosting their own mail servers > or are using relay services such as Trend Micro who are also having a > similar issue. The only thing these customers have in common is our DNS > and the fact that Google is trying to send email to them. > > I can query Google's public servers at 8.8.8.8 and 8.8.4.4 and they > always give the correct answers, but it seems that internally, Google is > unable to make these lookups. Reaching out to their support agents > online, the agents confirm that the correct entries are in place and > that *some* of Google's servers can't do the resolution resulting in > sporadic email delivery. They suggest that we reach out to the DNS > provider to find out why (Grrr) > > We've also had reports from customers that the failures seem to be > location oriented with western US emails being held up and eastern US > emails coming through. I can't independently confirm that, though. > > A full 100% of the email delivery issues have been Google hosted > domains. It seems that every other ISP can do the lookups just fine, > but getting in touch with someone at Google who can troubleshoot this is > impossible for a small ISP like us. > > If anyone can point me to somone at Google who could help me out, I'd be > very thankful. > > > Trey Nolen > > From edepa at ieee.org Wed Jul 31 14:48:01 2019 From: edepa at ieee.org (Etienne-Victor Depasquale) Date: Wed, 31 Jul 2019 16:48:01 +0200 Subject: The future of transport in the metro area Message-ID: Hello, I'm new to this mailing list. I hope I've understood the scope correctly! I've posted this question to ResearchGate but I haven't had any response. I'm hoping for some guidance from here. The question is: "I'm trying to identify trends in adoption of transport technology in the metro-area. If legacy is SDH/SONET and its successor in circuit transport is OTN, what are network providers implementing and planning to implement as transport technology in the metro area? For example, are packet transport technologies being considered as a replacement? As a complementary technology? By packet transport technologies, I am thinking of PBB-TE and MPLS-TP but ultimately, the problem regards how network providers are balancing circuit-transport and packet-transport technologies in current and planned deployments." -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale -------------- next part -------------- An HTML attachment was scrubbed... URL: From razor at meganet.net Wed Jul 31 16:54:26 2019 From: razor at meganet.net (Paul Amaral) Date: Wed, 31 Jul 2019 12:54:26 -0400 Subject: Estimated LTE Data Utilization in Failover Scenario In-Reply-To: <7E737E5CAF874540B47AAA561F038696A25CC1EA@EXCH2010.blackfoot.com> References: <7E737E5CAF874540B47AAA561F038696A25CC1EA@EXCH2010.blackfoot.com> Message-ID: <000701d547c0$9cc46ff0$d64d4fd0$@meganet.net> In my experience with LTE is that it’s never enough. We have bank branches with 20Mbs metro lines and on rare occasion when that circuit drops 4G LTE will provide you with 10mbs at best also note that latency is much higher which can mess with ipsec/VOIP etc. I don’t think you can pick how much bandwidth you will get with 4G LTE. From the testing I have done with VZ 4G I get 10mbs down and 2/3 up with a -65 RSSI. It’s still better to have LTE for a backup then not to have it. I have used cradlepoint and now switched to cisco ISR 1111. I find the crandlepoint to be not as reliable as the cisco ISR. The cradlepoint will get extremely hot, go down for no reason and has poor signal compared to the ISR 1111 with LTE. I would stay away from the cradlepoint and find a Cisco LTE solution. Again like I said a backup of any kind even if not sufficient in bandwidth is better than nothing. Paul From: NANOG On Behalf Of Shaun Dombrosky Sent: Tuesday, July 30, 2019 12:06 PM To: 'nanog at nanog.org' Subject: Estimated LTE Data Utilization in Failover Scenario Good Morning, First time NANOG poster, apologies if I breach etiquette. Does anyone have any first-hand data on how much data a small-medium business (SMB) can expect to consume in a failover scenario over a 4G/LTE connection?  Retail, under 50 head count, using PoS, maybe cloud accounting software, general internet activity, 8 hour time period.  Wonder if anyone is using a Cradlepoint or SD-WAN solution that could pull a few quick numbers from a dashboard for me.  I haven’t had much luck in my searches. Appreciate any info anyone can provide. Thanks, Shaun Dombrosky Data Network Engineer E: mailto:sdombrosky at blackfoot.com http://www.blackfoot.com/ Stay connected with Blackfoot: https://www.facebook.com/GoBlackfoot/?utm_source=Outlook&utm_medium=Sig&utm_ name=2017EmpSig&utm_content=Social  https://www.linkedin.com/company/blackfoot-telecommunications-group/?utm_sou rce=Outlook&utm_medium=Sig&utm_name=2017EmpSig&utm_content=Social  http://ww w.twitter.com/GoBlackfoot/?utm_source=Outlook&utm_medium=Sig&utm_name=2017Em pSig&utm_content=Social  https://www.youtube.com/BlackfootTelecom?utm_source =Outlook&utm_medium=Sig&utm_name=2017EmpSig&utm_content=Social This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed.  If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately reply to the sender by email notifying them of the error and delete the original and reply copies. Thank you. From swimwithphish at yahoo.com Wed Jul 31 16:36:08 2019 From: swimwithphish at yahoo.com (Richard Williams) Date: Wed, 31 Jul 2019 16:36:08 +0000 (UTC) Subject: really amazon? In-Reply-To: <20190731135304.GA24763@gsp.org> References: <20190731135304.GA24763@gsp.org> Message-ID: <1311295557.241488.1564590968224@mail.yahoo.com> To contact AWS SES about spam or abuse the correct email address is abuse at amazonaws.com On Wednesday, July 31, 2019, 9:53:59 AM EDT, Rich Kulawiec wrote: Yes, this is egregious, but on the other hand even when the abuse reporting mechanisms are working my experience has been that they emit no response (other than -- maybe -- boilerplate) and take no action, so it's not terribly surprising. ---rsk -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Wed Jul 31 19:04:53 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 31 Jul 2019 15:04:53 -0400 Subject: really amazon? In-Reply-To: <1311295557.241488.1564590968224@mail.yahoo.com> References: <20190731135304.GA24763@gsp.org> <1311295557.241488.1564590968224@mail.yahoo.com> Message-ID: <14112.1564599893@turing-police> On Wed, 31 Jul 2019 16:36:08 -0000, Richard Williams via NANOG said: > To contact AWS SES about spam or abuse the correct email address is abuse at amazonaws.com You know that, and I know that, but why doesn't the person at AWS whose job it is to keep the ARIN info correct and up to date know that? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From bensons at pc.nanog.org Wed Jul 31 19:24:20 2019 From: bensons at pc.nanog.org (Benson Schliesser) Date: Wed, 31 Jul 2019 15:24:20 -0400 Subject: Reminder: NANOG 77 call for presentations is open Message-ID: NANOG Community - As a reminder, the NANOG Program Committee (PC) is still accepting proposals for talks, tutorials, tracks & panels at the upcoming NANOG 77 in Austin, Texas, October 28-30, 2019. Below is a summary of key details and dates from the Call For Presentations on the NANOG website, which can be found at https://nanog.org/meetings/nanog-77/. Presentations may cover current technologies, soon-to-be deployed technologies, and industry innovation. Vendors are welcome to submit talks which cover relevant technologies and capabilities, but presentations should not be promotional, or discuss proprietary solutions. The primary speaker, moderator, or author should submit a presentation proposal and abstract via the PC Tool at: https://pc.nanog.org - Select “Propose Talk” from the “Talks” menu - Select NANOG 77 from the Meeting menu - Select the appropriate *Session* the talk will be presented in - General Session (30-45 minutes) - Tutorial (90-120 minutes) - Track (90-120 minutes) Key dates for NANOG 77: Date Event/Deadline Aug. 19, 2019 CFP Deadline Sep. 23, 2019 CFP Topic List & NANOG Meeting Highlights Page posted Sep. 30, 2019 NANOG 77 Agenda Posted Oct. 21, 2019 Speaker FINAL presentations DUE (NO CHANGES accepted after this date) Oct. 27, 2019 Lightning Talk Submissions Open, Onsite Registration Begins We look forward to seeing you in October in Austin, Texas! Sincerely, Benson Schliesser On behalf of the NANOG PC -------------- next part -------------- An HTML attachment was scrubbed... URL: From sc at ottie.org Wed Jul 31 20:13:48 2019 From: sc at ottie.org (Scott Christopher) Date: Wed, 31 Jul 2019 23:13:48 +0300 Subject: really amazon? In-Reply-To: <14112.1564599893@turing-police> References: <20190731135304.GA24763@gsp.org> <1311295557.241488.1564590968224@mail.yahoo.com> <14112.1564599893@turing-police> Message-ID: <2ee5e876-89cd-4fa3-9352-44bea22c9dc1@www.fastmail.com> Valdis Klētnieks wrote: > On Wed, 31 Jul 2019 16:36:08 -0000, Richard Williams via NANOG said: > > > To contact AWS SES about spam or abuse the correct email address is abuse at amazonaws.com > > You know that, and I know that, but why doesn't the person at AWS whose job it > is to keep the ARIN info correct and up to date know that? Because it will get spammed if publicly listed in WHOIS. -- S.C. From nuclearcat at nuclearcat.com Wed Jul 31 20:22:29 2019 From: nuclearcat at nuclearcat.com (Denys Fedoryshchenko) Date: Wed, 31 Jul 2019 23:22:29 +0300 Subject: really amazon? In-Reply-To: <2ee5e876-89cd-4fa3-9352-44bea22c9dc1@www.fastmail.com> References: <20190731135304.GA24763@gsp.org> <1311295557.241488.1564590968224@mail.yahoo.com> <14112.1564599893@turing-police> <2ee5e876-89cd-4fa3-9352-44bea22c9dc1@www.fastmail.com> Message-ID: <45ab647927aaf84d7d72dd006015b4d8@nuclearcat.com> On 2019-07-31 23:13, Scott Christopher wrote: > Valdis Klētnieks wrote: > >> On Wed, 31 Jul 2019 16:36:08 -0000, Richard Williams via NANOG said: >> >> > To contact AWS SES about spam or abuse the correct email address is abuse at amazonaws.com >> >> You know that, and I know that, but why doesn't the person at AWS >> whose job it >> is to keep the ARIN info correct and up to date know that? > > Because it will get spammed if publicly listed in WHOIS. They can send autoreply with correct address (even as picture, but yes, From: can be spoofed, so might be bad idea), make error message with link to captcha, custom error in reject (e.g. web url to submit report), and etc. So many ways to be more helpful in such critical matters. But at least not "User not found". From brian at interlinx.bc.ca Wed Jul 31 20:28:10 2019 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Wed, 31 Jul 2019 16:28:10 -0400 Subject: really amazon? In-Reply-To: <2ee5e876-89cd-4fa3-9352-44bea22c9dc1@www.fastmail.com> References: <20190731135304.GA24763@gsp.org> <1311295557.241488.1564590968224@mail.yahoo.com> <14112.1564599893@turing-police> <2ee5e876-89cd-4fa3-9352-44bea22c9dc1@www.fastmail.com> Message-ID: <0891105b22735c0247bba05d621303d7c4ef4fd7.camel@interlinx.bc.ca> On Wed, 2019-07-31 at 23:13 +0300, Scott Christopher wrote: > > Because it will get spammed if publicly listed in WHOIS. I will take that at *least* as ironic as you meant it. b. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From list at satchell.net Wed Jul 31 20:29:47 2019 From: list at satchell.net (Stephen Satchell) Date: Wed, 31 Jul 2019 13:29:47 -0700 Subject: really amazon? In-Reply-To: <14112.1564599893@turing-police> References: <20190731135304.GA24763@gsp.org> <1311295557.241488.1564590968224@mail.yahoo.com> <14112.1564599893@turing-police> Message-ID: <7e2c5a0b-3856-db3b-aff8-1ea972fc6a9f@satchell.net> On 7/31/19 12:04 PM, Valdis Klētnieks wrote: > On Wed, 31 Jul 2019 16:36:08 -0000, Richard Williams via NANOG said: > >> To contact AWS SES about spam or abuse the correct email address is abuse at amazonaws.com > > You know that, and I know that, but why doesn't the person at AWS whose job it > is to keep the ARIN info correct and up to date know that? C'mon, you already know the answer to this: there is no such person. Someone gets a mail once a year and MIGHT, JUST MIGHT, pass it on to someone who knows what to do. From list at satchell.net Wed Jul 31 20:33:23 2019 From: list at satchell.net (Stephen Satchell) Date: Wed, 31 Jul 2019 13:33:23 -0700 Subject: really amazon? In-Reply-To: <0891105b22735c0247bba05d621303d7c4ef4fd7.camel@interlinx.bc.ca> References: <20190731135304.GA24763@gsp.org> <1311295557.241488.1564590968224@mail.yahoo.com> <14112.1564599893@turing-police> <2ee5e876-89cd-4fa3-9352-44bea22c9dc1@www.fastmail.com> <0891105b22735c0247bba05d621303d7c4ef4fd7.camel@interlinx.bc.ca> Message-ID: <0de08971-ce97-9ec4-0508-b1d81554b42e@satchell.net> On 7/31/19 1:28 PM, Brian J. Murrell wrote: > On Wed, 2019-07-31 at 23:13 +0300, Scott Christopher wrote: >> >> Because it will get spammed if publicly listed in WHOIS. > > I will take that at *least* as ironic as you meant it. I don't know about your network, but I have five role mail accounts, and all five get spam, even with spam filters enabled. Oh, forgot about abuse@, which has no filter but LOTS of spam. What's fun is to let it sit a couple of days, then sort by subject. Delete the "conversations". That gets down to the zero or one piece of ham. But then again, I've locked down my network so abuse doesn't get out, even when someone manages to get by the MAC filters on the wireless router. From rsk at gsp.org Wed Jul 31 20:46:13 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 31 Jul 2019 16:46:13 -0400 Subject: really amazon? In-Reply-To: <2ee5e876-89cd-4fa3-9352-44bea22c9dc1@www.fastmail.com> References: <20190731135304.GA24763@gsp.org> <1311295557.241488.1564590968224@mail.yahoo.com> <14112.1564599893@turing-police> <2ee5e876-89cd-4fa3-9352-44bea22c9dc1@www.fastmail.com> Message-ID: <20190731204612.GA4883@gsp.org> On Wed, Jul 31, 2019 at 11:13:48PM +0300, Scott Christopher wrote: > Because it will get spammed if publicly listed in WHOIS. Yes. It will. Are you telling us that Amazon, with its enormous financial and personnel resources, doesn't have ANYBODY on staff who knows how to properly manage an abuse@ address -- part of which includes dealing with that exact problem? ---rsk From lstewart at inap.com Wed Jul 31 20:21:06 2019 From: lstewart at inap.com (Landon Stewart) Date: Wed, 31 Jul 2019 13:21:06 -0700 Subject: really amazon? In-Reply-To: <2ee5e876-89cd-4fa3-9352-44bea22c9dc1@www.fastmail.com> References: <20190731135304.GA24763@gsp.org> <1311295557.241488.1564590968224@mail.yahoo.com> <14112.1564599893@turing-police> <2ee5e876-89cd-4fa3-9352-44bea22c9dc1@www.fastmail.com> Message-ID: <9428F06B-3DBB-4203-9D14-7AB28B86531E@inap.com> On Jul 31, 2019, at 1:13 PM, Scott Christopher wrote: > > Valdis Klētnieks wrote: > >> On Wed, 31 Jul 2019 16:36:08 -0000, Richard Williams via NANOG said: >> >>> To contact AWS SES about spam or abuse the correct email address is abuse at amazonaws.com >> >> You know that, and I know that, but why doesn't the person at AWS whose job it >> is to keep the ARIN info correct and up to date know that? > > Because it will get spammed if publicly listed in WHOIS. Not an excuse. I’m saying this on behalf of ALL the other ASNs that keep their POCs up to date. -------------- 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 sandy at tislabs.com Wed Jul 31 20:55:39 2019 From: sandy at tislabs.com (Sandra Murphy) Date: Wed, 31 Jul 2019 16:55:39 -0400 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <051f3329-e3c8-4965-93a0-c89a41731aa6@www.fastmail.com> References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> <8fda3f1b-6e71-4bb7-9701-4b70a4813c55@www.fastmail.com> <9BA89F2A-6371-40E5-B7F7-2C69ABAD34EF@arin.net> <051f3329-e3c8-4965-93a0-c89a41731aa6@www.fastmail.com> Message-ID: <58BBE0F0-DD60-4767-AECE-71A57C0CBA5E@tislabs.com> Scott, you might want to read "Policy Development Process (PDP)” https://www.arin.net/participate/policy/pdp/ in order to discover just exactly what John means by “If the community developed a policy”. You might also want to join the Public Policy Mailing List, arin-ppml at arin.net, to discuss. Scintillating discourse, I assure you. —Sandy > On Jul 31, 2019, at 10:17 AM, Scott Christopher wrote: > > John Curran wrote: > >> Scott - >> >> Alas, you have a fundamental misunderstanding about the nature of ARIN… we don’t do anything other than implement policies that this community wants. If the community developed a policy to require Abuse POC’s validation, and said policy made clear that failure to do so was to result in revocation, then ARIN would indeed implement the policy (and that includes revocation for those who ignored the policy.) > > Hello John - you are absolutely right. Since the community has shown overwhelming disapproval of Amazon's invalid abuse POC, please go ahead and revoke Amazon's resources. > > Maybe do this late Friday afternoon for the courtesy toward Amazon's support staff ? > > And since this will certainly be historic, please post an announcement to nanog-list ? > > Thanks, and Good luck ! > > S.C. From sc at ottie.org Wed Jul 31 21:31:57 2019 From: sc at ottie.org (Scott Christopher) Date: Thu, 01 Aug 2019 00:31:57 +0300 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <58BBE0F0-DD60-4767-AECE-71A57C0CBA5E@tislabs.com> References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> <8fda3f1b-6e71-4bb7-9701-4b70a4813c55@www.fastmail.com> <9BA89F2A-6371-40E5-B7F7-2C69ABAD34EF@arin.net> <051f3329-e3c8-4965-93a0-c89a41731aa6@www.fastmail.com> <58BBE0F0-DD60-4767-AECE-71A57C0CBA5E@tislabs.com> Message-ID: Sandra Murphy wrote: > Scott, you might want to read "Policy Development Process (PDP)” > https://www.arin.net/participate/policy/pdp/ in order to discover just > exactly what John means by “If the community developed a policy”. > > You might also want to join the Public Policy Mailing List, > arin-ppml at arin.net, to discuss. Scintillating discourse, I assure you. Yes - I am aware of how ARIN functions, its mandate, its governance, etc. What I have been saying is that, if ARIN did something so brazen as to revoke Amazon's resources because of some bounced PoC emails, the impact would be *dramatic* and likely lead to the end of ARIN. Just think about this for a minute. :) Obviously this will not happen because ARIN is so righteously competent. :) I wasn't criticizing ARIN (or anybody) I was just answering a hypothetical. -- S.C. From sc at ottie.org Wed Jul 31 21:54:07 2019 From: sc at ottie.org (Scott Christopher) Date: Thu, 01 Aug 2019 00:54:07 +0300 Subject: really amazon? In-Reply-To: <20190731204612.GA4883@gsp.org> References: <20190731135304.GA24763@gsp.org> <1311295557.241488.1564590968224@mail.yahoo.com> <14112.1564599893@turing-police> <2ee5e876-89cd-4fa3-9352-44bea22c9dc1@www.fastmail.com> <20190731204612.GA4883@gsp.org> Message-ID: <939f5aa2-02a4-48b4-a9a6-24c04b0d0299@www.fastmail.com> Rich Kulawiec wrote: > On Wed, Jul 31, 2019 at 11:13:48PM +0300, Scott Christopher wrote: > > Because it will get spammed if publicly listed in WHOIS. > > Yes. It will. Are you telling us that Amazon, with its enormous financial > and personnel resources, doesn't have ANYBODY on staff who knows how to > properly manage an abuse@ address -- part of which includes dealing > with that exact problem? They do, but it's just time-consuming and inefficient. You can't spam-filter the content of abuse@ obviously. But in addition to spam, random (read: non-technical) people will send complaints outside of the usual purview of spam, network abuse, DMCA, etc. They find some FAQ on the web telling them to determine the PoC on whois.domaintools.com and then they start firing crap. I prefer openness and transparency and the general spirit of WHOIS but, in practice, you really do need the limit the PoC information to a trusted group of insiders. -- S.C. From nanog-post at rsuc.gweep.net Wed Jul 31 22:25:15 2019 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 31 Jul 2019 18:25:15 -0400 Subject: User Unknown (WAS: really amazon?) In-Reply-To: References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> Message-ID: <20190731222515.GA13716@gweep.net> On Tue, Jul 30, 2019 at 04:02:58PM +0300, T??ma Gavrichenkov wrote: > On Tue, Jul 30, 2019 at 1:20 PM Christoffer Hansen > wrote: > > Imagine ARIN did a take from RIPE NCC [Policy Proposal Idea?] and a > > policy came into effect of validating ALL 'OrgAbuseEmail' objects listed > > in the ARIN database. > > Just to be precise, such a policy (2019-04) is still in a discussion > phase in RIPE and has already seen significant resistance. > > You can, however, point fingers at APNIC instead, where pretty much > the same policy proposal from the same authors (prop-125) was already > implemented in apnic-127-v006 "Internet Number Resource Policies". > > I think they will be planning to reach out to ARIN with the same text > right after the RIPE process ends this way or another. Uh, ARIN-2019-5 has been in the ARIN PDP since March of this year. See https://www.arin.net/participate/policy/drafts/2019_5/ Most recent related PPML thread: https://lists.arin.net/pipermail/arin-ppml/2019-July/067241.html Cheers, Joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From marka at isc.org Wed Jul 31 22:27:07 2019 From: marka at isc.org (Mark Andrews) Date: Thu, 1 Aug 2019 08:27:07 +1000 Subject: User Unknown (WAS: really amazon?) In-Reply-To: References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> <8fda3f1b-6e71-4bb7-9701-4b70a4813c55@www.fastmail.com> <9BA89F2A-6371-40E5-B7F7-2C69ABAD34EF@arin.net> <051f3329-e3c8-4965-93a0-c89a41731aa6@www.fastmail.com> <58BBE0F0-DD60-4767-AECE-71A57C0CBA5E@tislabs.com> Message-ID: <97FAF157-BC0E-41C9-8E16-B852F05967D7@isc.org> Actually if ARIN doesn’t pull the resources, after notification and a grace period to get them fixed, then what is the point in writing policy requiring that they be up to date and working? There needs to be checks and balances for systems to work. The only thing is what should the grace period be? > On 1 Aug 2019, at 7:31 am, Scott Christopher wrote: > > Sandra Murphy wrote: > >> Scott, you might want to read "Policy Development Process (PDP)” >> https://www.arin.net/participate/policy/pdp/ in order to discover just >> exactly what John means by “If the community developed a policy”. >> >> You might also want to join the Public Policy Mailing List, >> arin-ppml at arin.net, to discuss. Scintillating discourse, I assure you. > > Yes - I am aware of how ARIN functions, its mandate, its governance, etc. > > What I have been saying is that, if ARIN did something so brazen as to revoke Amazon's resources because of some bounced PoC emails, the impact would be *dramatic* and likely lead to the end of ARIN. Just think about this for a minute. :) Obviously this will not happen because ARIN is so righteously competent. :) > > I wasn't criticizing ARIN (or anybody) I was just answering a hypothetical. > > -- > S.C. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rsk at gsp.org Wed Jul 31 22:31:37 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 31 Jul 2019 18:31:37 -0400 Subject: really amazon? In-Reply-To: <939f5aa2-02a4-48b4-a9a6-24c04b0d0299@www.fastmail.com> References: <20190731135304.GA24763@gsp.org> <1311295557.241488.1564590968224@mail.yahoo.com> <14112.1564599893@turing-police> <2ee5e876-89cd-4fa3-9352-44bea22c9dc1@www.fastmail.com> <20190731204612.GA4883@gsp.org> <939f5aa2-02a4-48b4-a9a6-24c04b0d0299@www.fastmail.com> Message-ID: <20190731223136.GA7701@gsp.org> On Thu, Aug 01, 2019 at 12:54:07AM +0300, Scott Christopher wrote: > Rich Kulawiec wrote: > > > On Wed, Jul 31, 2019 at 11:13:48PM +0300, Scott Christopher wrote: > > > Because it will get spammed if publicly listed in WHOIS. > > > > Yes. It will. Are you telling us that Amazon, with its enormous financial > > and personnel resources, doesn't have ANYBODY on staff who knows how to > > properly manage an abuse@ address -- part of which includes dealing > > with that exact problem? > > They do, but it's just time-consuming and inefficient. You can't spam-filter > the content of abuse@ obviously. Actually, yes, you can -- but probably not in the way you're thinking, because if you do it *that* way you will break [some of the] required functionality. > But in addition to spam, random (read: non-technical) people will send > complaints outside of the usual purview of spam, network abuse, DMCA, > etc. They find some FAQ on the web telling them to determine the PoC on > whois.domaintools.com and then they start firing crap. This is not my first day on the job. I'm aware of what shows up at role addresses. However, handling the problems you enumerate here is a straightforward (albeit occasionally tedious) matter that any operations engineer above entry-level should be able to handle. Doubly so because people like me have done them the favor of writing about it (here and elsewhere), so they can use our experience without needing to repeat our numerous mistakes. > I prefer openness and transparency and the general spirit of WHOIS but, in practice, > you really do need the limit the PoC information to a trusted group of insiders. First, there's no such thing as a trusted group of insiders. Second, even if such a group existed, limiting PoC information to them is impossible. Think about it. Third, besides WHOIS PoC, RFC 2142 (and decades of best practices) specify abuse@, postmaster@, etc. My expectation is that anyone equipped with baseline competence will be fully prepared to handle traffic to those addresses (as applicable) effectively at whatever scale their operation requires. ---rsk From sabri at cluecentral.net Wed Jul 31 23:01:07 2019 From: sabri at cluecentral.net (Sabri Berisha) Date: Wed, 31 Jul 2019 16:01:07 -0700 (PDT) Subject: Estimated LTE Data Utilization in Failover Scenario In-Reply-To: <000701d547c0$9cc46ff0$d64d4fd0$@meganet.net> References: <7E737E5CAF874540B47AAA561F038696A25CC1EA@EXCH2010.blackfoot.com> <000701d547c0$9cc46ff0$d64d4fd0$@meganet.net> Message-ID: <2127263763.162301.1564614067841.JavaMail.zimbra@cluecentral.net> ----- On Jul 31, 2019, at 9:54 AM, nanog nanog at nanog.org wrote: Hi, > From the testing I have done with VZ 4G > I get 10mbs down and 2/3 up with a -65 RSSI. It’s still better to have LTE > for a backup then not to have it. You will have to keep in mind that if there is a generic service outage in your area, you will not be the only one going LTE/4G for backup purposes. That means you will kind of have to lower your expectations in a real world scenario... > Again like I said a backup of any kind even if not sufficient in bandwidth > is better than nothing. That I totally agree with. Thanks, Sabri From sander at steffann.nl Tue Jul 30 12:32:23 2019 From: sander at steffann.nl (Sander Steffann) Date: Tue, 30 Jul 2019 14:32:23 +0200 Subject: MX10003 rack size Message-ID: <29AA198D-CE4F-4ACD-8649-662ED2C34E29@steffann.nl> Hi, Has anyone ever managed to fit a Juniper MX10003 in a 90cm deep rack? Without applying power tools to either the rack or the router ;) Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: