From ryan.g at atwgpc.net Thu Aug 1 01:34:45 2019 From: ryan.g at atwgpc.net (Ryan Gelobter) Date: Wed, 31 Jul 2019 20:34:45 -0500 Subject: UK, NL, & Asia LTE Providers for Opengear Console Servers Message-ID: Anyone have recommendations for providers who I can use for LTE on Opengear console servers in the UK, Netherlands, and Singapore? 1 provider for all 3 countries would be great but I'll take what I can get. Oddly when talking to Opengear they don't really have any great advice. We use Verizon SIM cards in the US with static IPs. Thanks, Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Aug 1 02:19:17 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 31 Jul 2019 19:19:17 -0700 Subject: UK, NL, & Asia LTE Providers for Opengear Console Servers In-Reply-To: References: Message-ID: Google Fi On Wed, Jul 31, 2019 at 18:35 Ryan Gelobter wrote: > Anyone have recommendations for providers who I can use for LTE on > Opengear console servers in the UK, Netherlands, and Singapore? 1 provider > for all 3 countries would be great but I'll take what I can get. Oddly when > talking to Opengear they don't really have any great advice. We use Verizon > SIM cards in the US with static IPs. > > Thanks, > Ryan > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbothe at me.com Thu Aug 1 02:53:25 2019 From: jbothe at me.com (JASON BOTHE) Date: Wed, 31 Jul 2019 21:53:25 -0500 Subject: UK, NL, & Asia LTE Providers for Opengear Console Servers In-Reply-To: References: Message-ID: <737EF3B8-42FF-4E59-801C-D13E4C9BC6D1@me.com> Are the Opengear boxes good gear? We currently have some boxes with a high failure rate and I’ve been on the hunt for something we can leverage globally that support LTE. J~ > On Jul 31, 2019, at 21:19, Mehmet Akcin wrote: > > Google Fi > >> On Wed, Jul 31, 2019 at 18:35 Ryan Gelobter wrote: >> Anyone have recommendations for providers who I can use for LTE on Opengear console servers in the UK, Netherlands, and Singapore? 1 provider for all 3 countries would be great but I'll take what I can get. Oddly when talking to Opengear they don't really have any great advice. We use Verizon SIM cards in the US with static IPs. >> >> Thanks, >> Ryan > -- > Mehmet > +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From louisk at cryptomonkeys.org Thu Aug 1 03:43:46 2019 From: louisk at cryptomonkeys.org (Louis Kowolowski) Date: Wed, 31 Jul 2019 22:43:46 -0500 Subject: UK, NL, & Asia LTE Providers for Opengear Console Servers In-Reply-To: <737EF3B8-42FF-4E59-801C-D13E4C9BC6D1@me.com> References: <737EF3B8-42FF-4E59-801C-D13E4C9BC6D1@me.com> Message-ID: <874B6E08-6BAD-4B2E-8557-1DB66DB7789A@cryptomonkeys.org> I’ve used them in both cellular and non-cellular capacities and been pleased with them. AFAIK they can be setup as an IPSec terminator for clients and block other traffic, which lowers the attack surface a bit. I’ve also seen people try to use “all the features”, set them up as DNS/DHCP/etc and attach them to multiple networks because they are “a linux box”. Its not great. Treat them as a console server and you’ll be happy. Treat them as a general purpose linux “server” and you’ll be disappointed at the lack of flexibility in doing things. I just used swisscom in Zurich. I would expect Orange would probably cover both UK and NL, but don’t know for sure. Haven’t had to do anything in Asia recently. > On Jul 31, 2019, at 9:53 PM, JASON BOTHE via NANOG wrote: > > Are the Opengear boxes good gear? We currently have some boxes with a high failure rate and I’ve been on the hunt for something we can leverage globally that support LTE. > > J~ > > On Jul 31, 2019, at 21:19, Mehmet Akcin > wrote: > >> Google Fi >> >> On Wed, Jul 31, 2019 at 18:35 Ryan Gelobter > wrote: >> Anyone have recommendations for providers who I can use for LTE on Opengear console servers in the UK, Netherlands, and Singapore? 1 provider for all 3 countries would be great but I'll take what I can get. Oddly when talking to Opengear they don't really have any great advice. We use Verizon SIM cards in the US with static IPs. >> >> Thanks, >> Ryan >> -- >> Mehmet >> +1-424-298-1903 -- Louis Kowolowski louisk at cryptomonkeys.org Cryptomonkeys: http://www.cryptomonkeys.com/ Making life more interesting for people since 1977 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ninjabadger.net Thu Aug 1 07:55:20 2019 From: tom at ninjabadger.net (Tom Hill) Date: Thu, 1 Aug 2019 08:55:20 +0100 Subject: UK, NL, & Asia LTE Providers for Opengear Console Servers In-Reply-To: References: Message-ID: On 01/08/2019 03:19, Mehmet Akcin wrote: > Google Fi Are you suggesting Fi because of: "When outside the United States, cellular phone calls cost $0.20 per minute, data costs the same $10 per gigabyte (i.e. there are no extra data charges outside of the US), and texting is free." Ergo, relative to the countries stated, permanently roaming? I'd love to know if you've found that reliable - it seems too good to be true. -- Tom From nanog at as397444.net Thu Aug 1 14:02:07 2019 From: nanog at as397444.net (Matt Corallo) Date: Thu, 1 Aug 2019 10:02:07 -0400 Subject: UK, NL, & Asia LTE Providers for Opengear Console Servers In-Reply-To: References: Message-ID: When using a data-only Fi SIM (which are free if you have an account, just pay the bandwidth), they always just act as a T-Mobile US MVNO and route back through the US. Still, latency aside, I've found it incredibly reliable (plus in many countries you can pick from multiple networks). If you have an Android phone it may switch to 3UK/Hutch's global network, though I have less experience with that. Matt > On Aug 1, 2019, at 03:55, Tom Hill wrote: > >> On 01/08/2019 03:19, Mehmet Akcin wrote: >> Google Fi > > Are you suggesting Fi because of: > > "When outside the United States, cellular phone calls cost $0.20 per > minute, data costs the same $10 per gigabyte (i.e. there are no extra > data charges outside of the US), and texting is free." > > Ergo, relative to the countries stated, permanently roaming? > > I'd love to know if you've found that reliable - it seems too good to be > true. > > -- > Tom From kenny.taylor at kccd.edu Thu Aug 1 14:22:54 2019 From: kenny.taylor at kccd.edu (Kenny Taylor) Date: Thu, 1 Aug 2019 14:22:54 +0000 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: We did some testing with VZ and Sprint earlier this year. Sprint provided rates around 20-25 mbit down and 2-3 mbit up *if* it was an area with decent coverage and the connection was on band 41. Much lower rates on band 25/26. We noticed that their regular unlimited hotspot plans perform well up until the 50 GB mark. The evening after we'd hit the 50 GB mark, throttling kicked in and pinned the connection down to about 128 kbit, regardless of cellular network congestion. VZ seems to throttle the connections after hitting the 25 GB mark, but it's gradual and appears to be more deprioritization than shaping. We tried VZ in a couple of rural areas and quickly discovered that there wasn't enough bandwidth to those particular towers. We could pull 20 mbit down regularly around 6:00 am, then by lunch time we'd get less than 1 mbt down. We deployed an ISR router with LTE NIM and a linux box running iperf hourly to do that testing. Don't base your rate estimate on afterhours testing, and I'd echo the other comments that the cellular network will get slammed during an outage/disaster scenario and will undershoot your estimates. Worth noting, I can pull 45-60 mbit on my T-Mobile phone all day long. Does anyone have experience using T-Mobile plans for LTE backup? Kenny -----Original Message----- From: NANOG On Behalf Of Paul Amaral via NANOG Sent: Wednesday, July 31, 2019 9:54 AM To: 'Shaun Dombrosky' ; nanog at nanog.org Subject: RE: Estimated LTE Data Utilization in Failover Scenario 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 https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.blackfoot.com%2F&data=02%7C01%7Ckenny.taylor%40kccd.edu%7C050595db295d4f2a5a7b08d715e17881%7C52a30add642a46f8a4e2c61db3eb8742%7C0%7C0%7C637001930443436642&sdata=tgXlzwo19vLsM%2BfARvbKCoWxFK1o7JRjmUzz84pLQYE%3D&reserved=0 Stay connected with Blackfoot: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2FGoBlackfoot%2F%3Futm_source%3DOutlook%26utm_medium%3DSig%26utm_&data=02%7C01%7Ckenny.taylor%40kccd.edu%7C050595db295d4f2a5a7b08d715e17881%7C52a30add642a46f8a4e2c61db3eb8742%7C0%7C0%7C637001930443436642&sdata=NDMAwdmN2tJPpXVEP48AN%2FUIay6%2BLWX%2BylH7%2F6mGfFg%3D&reserved=0 name=2017EmpSig&utm_content=Social https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fblackfoot-telecommunications-group%2F%3Futm_sou&data=02%7C01%7Ckenny.taylor%40kccd.edu%7C050595db295d4f2a5a7b08d715e17881%7C52a30add642a46f8a4e2c61db3eb8742%7C0%7C0%7C637001930443436642&sdata=5FjSw1FNGThb8e03fPirzemq6qcSOm352jR%2BDbdkXWE%3D&reserved=0 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2FBlackfootTelecom%3Futm_source&data=02%7C01%7Ckenny.taylor%40kccd.edu%7C050595db295d4f2a5a7b08d715e17881%7C52a30add642a46f8a4e2c61db3eb8742%7C0%7C0%7C637001930443436642&sdata=n3m14erZyEBF2Sl6%2BHYzPO5sDGjDnXkHsX0h0hiKSUE%3D&reserved=0 =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 agakpe at hotmail.com Thu Aug 1 17:34:44 2019 From: agakpe at hotmail.com (peter agakpe) Date: Thu, 1 Aug 2019 17:34:44 +0000 Subject: Help needed configure a server Message-ID: I am a newbie trying to configure and put a home server online as starter project. with some help. Specifically, dns server specifics, port forwarding, recommended hardware and software, such as router, dns server, security, etc. I would greatly appreciate any help. Thanks Peter Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at floridavirtualsolutions.com Thu Aug 1 14:14:06 2019 From: nick at floridavirtualsolutions.com (Nick Olsen) Date: Thu, 1 Aug 2019 10:14:06 -0400 Subject: UK, NL, & Asia LTE Providers for Opengear Console Servers In-Reply-To: References: Message-ID: I've got a line on my Fi account that almost exclusively roams in the UK. Only been on-net in the US a few times and they've never complained about excessive roaming. It roams on 3UK. And works fine. Albeit the LTE deployment isn't near as wide there as it is in the US. And you end up on HSDPA pretty frequently. On Thu, Aug 1, 2019 at 10:04 AM Matt Corallo wrote: > When using a data-only Fi SIM (which are free if you have an account, just > pay the bandwidth), they always just act as a T-Mobile US MVNO and route > back through the US. Still, latency aside, I've found it incredibly > reliable (plus in many countries you can pick from multiple networks). > > If you have an Android phone it may switch to 3UK/Hutch's global network, > though I have less experience with that. > > Matt > > > On Aug 1, 2019, at 03:55, Tom Hill wrote: > > > >> On 01/08/2019 03:19, Mehmet Akcin wrote: > >> Google Fi > > > > Are you suggesting Fi because of: > > > > "When outside the United States, cellular phone calls cost $0.20 per > > minute, data costs the same $10 per gigabyte (i.e. there are no extra > > data charges outside of the US), and texting is free." > > > > Ergo, relative to the countries stated, permanently roaming? > > > > I'd love to know if you've found that reliable - it seems too good to be > > true. > > > > -- > > Tom > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Thu Aug 1 17:54:57 2019 From: matt at netfire.net (Matt Harris) Date: Thu, 1 Aug 2019 12:54:57 -0500 Subject: Help needed configure a server In-Reply-To: References: Message-ID: Hi Peter, I might suggest that you start at the beginning, perhaps with google or some classes - either something in person, or maybe just some introductory videos online that discuss entry level IT topics. As far as recommended hardware, a raspberry pi may be a quick, inexpensive way to get started. Good luck! On Thu, Aug 1, 2019 at 12:48 PM peter agakpe wrote: > I am a newbie trying to configure and put a home server online as starter > project. with some help. Specifically, dns server specifics, port > forwarding, recommended hardware and software, such as router, dns server, > security, etc. I would greatly appreciate any help. > > > > Thanks > > Peter > > > > Sent from Mail for > Windows 10 > > > -- 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 ross at tajvar.io Thu Aug 1 19:40:35 2019 From: ross at tajvar.io (Ross Tajvar) Date: Thu, 1 Aug 2019 15:40:35 -0400 Subject: Help needed configure a server In-Reply-To: References: Message-ID: Peter, You might want to check out reddit, specifically r/homelab. That subreddit has a lot of good resources for the type of stuff you've described (check the wiki). This mailing list is more aimed at enterprise-level networking, so probably not the best place to ask these kind of questions. Best, Ross On Thu, Aug 1, 2019 at 1:57 PM Matt Harris wrote: > Hi Peter, > I might suggest that you start at the beginning, perhaps with google or > some classes - either something in person, or maybe just some introductory > videos online that discuss entry level IT topics. > > As far as recommended hardware, a raspberry pi may be a quick, inexpensive > way to get started. > > Good luck! > > > On Thu, Aug 1, 2019 at 12:48 PM peter agakpe wrote: > >> I am a newbie trying to configure and put a home server online as starter >> project. with some help. Specifically, dns server specifics, port >> forwarding, recommended hardware and software, such as router, dns server, >> security, etc. I would greatly appreciate any help. >> >> >> >> Thanks >> >> Peter >> >> >> >> Sent from Mail for >> Windows 10 >> >> >> > > > -- > 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 fearghas at gmail.com Thu Aug 1 19:47:35 2019 From: fearghas at gmail.com (Fearghas Mckay) Date: Thu, 1 Aug 2019 15:47:35 -0400 Subject: UK, NL, & Asia LTE Providers for Opengear Console Servers In-Reply-To: References: Message-ID: Tom > On 1 Aug 2019, at 03:55, Tom Hill wrote: > > Are you suggesting Fi because of: > > "When outside the United States, cellular phone calls cost $0.20 per > minute, data costs the same $10 per gigabyte (i.e. there are no extra > data charges outside of the US), and texting is free." > > Ergo, relative to the countries stated, permanently roaming? > > I'd love to know if you've found that reliable - it seems too good to be > true. That is is how I use Fi and it just works - the only place it didn’t was Beirut. You used to be able to have 9 sims on the account but they have just reduced it to 4 for new accounts and those who were not already using more than 4. If you had more than 4 they are grandfathered in. f From razor at meganet.net Thu Aug 1 18:05:57 2019 From: razor at meganet.net (Paul Amaral) Date: Thu, 1 Aug 2019 14:05:57 -0400 Subject: Estimated LTE Data Utilization in Failover Scenario In-Reply-To: References: <7E737E5CAF874540B47AAA561F038696A25CC1EA@EXCH2010.blackfoot.com> <000701d547c0$9cc46ff0$d64d4fd0$@meganet.net> Message-ID: <005f01d54893$c4d58e60$4e80ab20$@meganet.net> To clarify, the test was done around 1PM and was simple speed test, probably could have gotten more throughput at the end of the day but these are used as backups and if the primary connection goes down, I don’t have the luxury to pick when that happens. I mainly used these as backups and I make sure the customer knows that this is a temporary solution, the speed/latency will not be as good as the primary connection. If the customer understands this, then 4G LTE is a great solution especially for a backup. It's also great for getting branches up ASAP while waiting for fiber etc. I haven't tried T-mobile LTE but that seems really high. Paul -----Original Message----- From: NANOG On Behalf Of Kenny Taylor Sent: Thursday, August 01, 2019 10:23 AM To: nanog list Subject: RE: Estimated LTE Data Utilization in Failover Scenario We did some testing with VZ and Sprint earlier this year. Sprint provided rates around 20-25 mbit down and 2-3 mbit up *if* it was an area with decent coverage and the connection was on band 41. Much lower rates on band 25/26. We noticed that their regular unlimited hotspot plans perform well up until the 50 GB mark. The evening after we'd hit the 50 GB mark, throttling kicked in and pinned the connection down to about 128 kbit, regardless of cellular network congestion. VZ seems to throttle the connections after hitting the 25 GB mark, but it's gradual and appears to be more deprioritization than shaping. We tried VZ in a couple of rural areas and quickly discovered that there wasn't enough bandwidth to those particular towers. We could pull 20 mbit down regularly around 6:00 am, then by lunch time we'd get less than 1 mbt down. We deployed an ISR router with LTE NIM and a linux box running iperf hourly to do that testing. Don't base your rate estimate on afterhours testing, and I'd echo the other comments that the cellular network will get slammed during an outage/disaster scenario and will undershoot your estimates. Worth noting, I can pull 45-60 mbit on my T-Mobile phone all day long. Does anyone have experience using T-Mobile plans for LTE backup? Kenny -----Original Message----- From: NANOG On Behalf Of Paul Amaral via NANOG Sent: Wednesday, July 31, 2019 9:54 AM To: 'Shaun Dombrosky' ; nanog at nanog.org Subject: RE: Estimated LTE Data Utilization in Failover Scenario 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 https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.blackfo ot.com%2F&data=02%7C01%7Ckenny.taylor%40kccd.edu%7C050595db295d4f2a5a7b0 8d715e17881%7C52a30add642a46f8a4e2c61db3eb8742%7C0%7C0%7C637001930443436642& amp;sdata=tgXlzwo19vLsM%2BfARvbKCoWxFK1o7JRjmUzz84pLQYE%3D&reserved=0 Stay connected with Blackfoot: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebo ok.com%2FGoBlackfoot%2F%3Futm_source%3DOutlook%26utm_medium%3DSig%26utm_& ;data=02%7C01%7Ckenny.taylor%40kccd.edu%7C050595db295d4f2a5a7b08d715e17881%7 C52a30add642a46f8a4e2c61db3eb8742%7C0%7C0%7C637001930443436642&sdata=NDM AwdmN2tJPpXVEP48AN%2FUIay6%2BLWX%2BylH7%2F6mGfFg%3D&reserved=0 name=2017EmpSig&utm_content=Social https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linked in.com%2Fcompany%2Fblackfoot-telecommunications-group%2F%3Futm_sou&data= 02%7C01%7Ckenny.taylor%40kccd.edu%7C050595db295d4f2a5a7b08d715e17881%7C52a30 add642a46f8a4e2c61db3eb8742%7C0%7C0%7C637001930443436642&sdata=5FjSw1FNG Thb8e03fPirzemq6qcSOm352jR%2BDbdkXWE%3D&reserved=0 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://nam02.safelinks.protection.outlook.com/?url =https%3A%2F%2Fwww.youtube.com%2FBlackfootTelecom%3Futm_source&data=02%7 C01%7Ckenny.taylor%40kccd.edu%7C050595db295d4f2a5a7b08d715e17881%7C52a30add6 42a46f8a4e2c61db3eb8742%7C0%7C0%7C637001930443436642&sdata=n3m14erZyEBF2 Sl6%2BHYzPO5sDGjDnXkHsX0h0hiKSUE%3D&reserved=0 =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 spuggy930 at gmail.com Thu Aug 1 19:53:28 2019 From: spuggy930 at gmail.com (Andy Sparrow) Date: Thu, 1 Aug 2019 12:53:28 -0700 Subject: UK, NL, & Asia LTE Providers for Opengear Console Servers In-Reply-To: References: Message-ID: According to https://www.theverge.com/circuitbreaker/2016/7/12/12159210/google-project-fi-three-network-international-roaming-speed , Project/Google Fi added 3/Hutchinson as a native carrier in the UK in the same way that Sprint/T-Mob/US Cellular networks provide service in the US. One of Hutch's subsidiaries probably provides service almost everywhere in the world (except, oddly, Mexico, last I looked). But whether there's a Google/Hutch tie-in in that market another matter. A Fi data SIM should work in any Google-supported market though. Checking the bands used by the local markets (and/or the prospective device) might be a good idea. Think I've had Fi for 4 years now. Stepping off the plane and your phone Just Works is kind of magical. You can only activate a voice SIM in a Fi-supported phone - but the SIM will work if transferred to another phone once activated, you just may have fewer radios & lose functionality (like transparent in-call handoff between multiple carriers). On Thu, Aug 1, 2019 at 7:03 AM Matt Corallo wrote: > When using a data-only Fi SIM (which are free if you have an account, just > pay the bandwidth), they always just act as a T-Mobile US MVNO and route > back through the US. Still, latency aside, I've found it incredibly > reliable (plus in many countries you can pick from multiple networks). > > If you have an Android phone it may switch to 3UK/Hutch's global network, > though I have less experience with that. > > Matt > > > On Aug 1, 2019, at 03:55, Tom Hill wrote: > > > >> On 01/08/2019 03:19, Mehmet Akcin wrote: > >> Google Fi > > > > Are you suggesting Fi because of: > > > > "When outside the United States, cellular phone calls cost $0.20 per > > minute, data costs the same $10 per gigabyte (i.e. there are no extra > > data charges outside of the US), and texting is free." > > > > Ergo, relative to the countries stated, permanently roaming? > > > > I'd love to know if you've found that reliable - it seems too good to be > > true. > > > > -- > > Tom > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tnelson at sangoma.com Thu Aug 1 18:06:56 2019 From: tnelson at sangoma.com (Tim Nelson) Date: Thu, 1 Aug 2019 13:06:56 -0500 Subject: Help needed configure a server In-Reply-To: References: Message-ID: Everything you want to know and more can be found on https://www.reddit.com/r/homelab --Tim On Thu, Aug 1, 2019 at 12:49 PM peter agakpe wrote: > I am a newbie trying to configure and put a home server online as starter > project. with some help. Specifically, dns server specifics, port > forwarding, recommended hardware and software, such as router, dns server, > security, etc. I would greatly appreciate any help. > > > > Thanks > > Peter > > > > Sent from Mail for > Windows 10 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pkranz at unwiredltd.com Thu Aug 1 21:35:08 2019 From: pkranz at unwiredltd.com (Peter Kranz) Date: Thu, 1 Aug 2019 14:35:08 -0700 Subject: Phoenix IX down/gone? Message-ID: <45f6701d548b0$fda153b0$f8e3fb10$@unwiredltd.com> Anyone know what happened to Phoenix IX? https://peeringdb.com/ix/66 They seem off the air including website and phones.. permanently? -PeterK at 32354 From pkranz at unwiredltd.com Thu Aug 1 21:48:53 2019 From: pkranz at unwiredltd.com (Peter Kranz) Date: Thu, 1 Aug 2019 14:48:53 -0700 Subject: Phoenix IX down/gone? In-Reply-To: <45f6701d548b0$fda153b0$f8e3fb10$@unwiredltd.com> References: <45f6701d548b0$fda153b0$f8e3fb10$@unwiredltd.com> Message-ID: <45f6d01d548b2$e960ee40$bc22cac0$@unwiredltd.com> Corrected URL: https://peeringdb.com/ix/662 -----Original Message----- From: NANOG On Behalf Of Peter Kranz via NANOG Sent: Thursday, August 01, 2019 2:35 PM To: nanog at nanog.org Subject: Phoenix IX down/gone? Anyone know what happened to Phoenix IX? https://peeringdb.com/ix/66 They seem off the air including website and phones.. permanently? -PeterK at 32354 From brandonwade at yahoo.com Fri Aug 2 01:29:52 2019 From: brandonwade at yahoo.com (Brandon Wade) Date: Fri, 2 Aug 2019 01:29:52 +0000 (UTC) Subject: Phoenix IX down/gone? References: <719437210.6730.1564709392169.ref@mail.yahoo.com> Message-ID: <719437210.6730.1564709392169@mail.yahoo.com> >> Corrected URL: >> https://peeringdb.com/ix/662 >> >> Anyone know what happened to Phoenix IX? https://peeringdb.com/ix/66 They >> seem off the air including website and phones.. permanently? >> >> -PeterK at 32354We (AS53767) are passing traffic on Phoenix IX. The person who operates the exchange (Paul Emmons) is frequently traveling for business. I suspect something is simply wrong with the website.  I'll reach out to him through a private channel and make sure he's aware the website is down. Best regards,Brandon WadeiCastCenter.com / AS53767 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Fri Aug 2 02:49:45 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 1 Aug 2019 19:49:45 -0700 Subject: Looking glass software Message-ID: hey there, I am looking for a public looking glass software that is used by many. Github has way too many dead projects (or projects that seem like dead) and appreciates community feedback on what's the best out there. my goals are to be able to provide, ping/ping6, traceroute/traceroute6, and route views. Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnschmidt at i3d.net Fri Aug 2 05:52:37 2019 From: martijnschmidt at i3d.net (Martijn Schmidt) Date: Fri, 2 Aug 2019 05:52:37 +0000 Subject: Looking glass software In-Reply-To: References: Message-ID: We are using https://github.com/respawner/looking-glass which is doing the job nicely and is actively developed. Best regards, Martijn ________________________________ From: NANOG on behalf of Mehmet Akcin Sent: 02 August 2019 04:49:45 To: nanog Subject: Looking glass software hey there, I am looking for a public looking glass software that is used by many. Github has way too many dead projects (or projects that seem like dead) and appreciates community feedback on what's the best out there. my goals are to be able to provide, ping/ping6, traceroute/traceroute6, and route views. Mehmet -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Fri Aug 2 08:01:45 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Aug 2019 10:01:45 +0200 Subject: The future of transport in the metro area In-Reply-To: References: Message-ID: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> On 31/Jul/19 16:48, Etienne-Victor Depasquale wrote: > > "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." Ethernet has been ruling the Metro for some time now. The control and forwarding planes that drive that are a decision left to the operator. There is a healthy sharing of the pie between DWDM and packet to drive these Ethernet Metro's, depending on use-case, the operators' business model, whether it's an ISP or a content network, e.t.c. In all, SDH/SONET Metro networks, while not completely gone, are certainly on the decline. As far as OTN goes, I've always heard more talk than actual biting by customers. In our market, every time a customer has shown interest in OTN, they end up going for EoDWDM, all the time. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Fri Aug 2 08:07:22 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Aug 2019 10:07:22 +0200 Subject: The future of transport in the metro area In-Reply-To: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> References: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> Message-ID: <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> And just to add that I think that as part of the future, 5G is likely to play a big part as well, somewhere between the Metro and the Access. Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Fri Aug 2 08:32:19 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Aug 2019 10:32:19 +0200 Subject: The future of transport in the metro area In-Reply-To: References: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> Message-ID: <6d8f5d52-c0b9-ce5e-48bd-7d1f096d4834@seacom.mu> On 2/Aug/19 10:17, Etienne-Victor Depasquale wrote: > Mark, when you write "There is a healthy sharing of the pie between > DWDM and packet to drive these Ethernet Metro's ", can you elaborate a > little? Are you referring specifically to EoDWDM, or do you have > something else in mind? EoDWDM. Ethernet is very widely used, regardless of the Transport technology. In other markets, you will find SDH Transports delivering Ethernet as well (EoSDH), although that is dying in favour of EoDWDM or just Ethernet over (dark) fibre. Mark. From bryan at shout.net Fri Aug 2 09:22:15 2019 From: bryan at shout.net (Bryan Holloway) Date: Fri, 2 Aug 2019 11:22:15 +0200 Subject: Phoenix IX down/gone? In-Reply-To: <719437210.6730.1564709392169@mail.yahoo.com> References: <719437210.6730.1564709392169.ref@mail.yahoo.com> <719437210.6730.1564709392169@mail.yahoo.com> Message-ID: <422b186d-00d0-0d54-20ca-254645be9a55@shout.net> On 8/2/19 3:29 AM, Brandon Wade via NANOG wrote: >>> Corrected URL: >>> https://peeringdb.com/ix/662 >>> >>> Anyone know what happened to Phoenix IX? https://peeringdb.com/ix/66 They >>> seem off the air including website and phones.. permanently? >>> >>> -PeterK at 32354 > > We (AS53767) are passing traffic on Phoenix IX. The person who operates > the exchange (Paul Emmons) is frequently traveling for business. I > suspect something is simply wrong with the website. > > I'll reach out to him through a private channel and make sure he's aware > the website is down. > > Best regards, > Brandon Wade > iCastCenter.com / AS53767 The web-site appears to be up again. From jwbensley+nanog at gmail.com Fri Aug 2 11:12:38 2019 From: jwbensley+nanog at gmail.com (James Bensley) Date: Fri, 2 Aug 2019 12:12:38 +0100 Subject: UK, NL, & Asia LTE Providers for Opengear Console Servers In-Reply-To: References: Message-ID: On Thu, 1 Aug 2019 at 02:36, Ryan Gelobter wrote: > > Anyone have recommendations for providers who I can use for LTE on Opengear console servers in the UK, Netherlands, and Singapore? 1 provider for all 3 countries would be great but I'll take what I can get. Oddly when talking to Opengear they don't really have any great advice. We use Verizon SIM cards in the US with static IPs. > > Thanks, > Ryan Hi Ryan, Vodafone GDSP (Global Data Service Platform) might be what you're looking for "We offer 4G LTE roaming in over 100 countries." - I've been looking into this recently but can't find a list of those countries publically available. I think you'd need to approach Vodafone directly as an interested customer/party, and I'm working via a VAR so no direct channel. Cheers, James. From tom at ninjabadger.net Fri Aug 2 12:01:34 2019 From: tom at ninjabadger.net (Tom Hill) Date: Fri, 2 Aug 2019 13:01:34 +0100 Subject: UK, NL, & Asia LTE Providers for Opengear Console Servers In-Reply-To: References: Message-ID: On 01/08/2019 15:14, Nick Olsen wrote: > It roams on 3UK. And works fine. Albeit the LTE deployment isn't near as > wide there as it is in the US. And you end up on HSDPA pretty frequently. To the this point, I've a Three contract here (UK). It has slightly been frustrating recently, I'll admit. It does look like they're aiming to address that, however. More re-farming 3G frequencies to 4G, additional bands: https://www.ispreview.co.uk/index.php/2019/08/three-uk-in-l-band-rollout-as-mobile-data-usage-per-user-hits-9-1gb.html -- Tom From baldur.norddahl at gmail.com Fri Aug 2 12:17:43 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 2 Aug 2019 14:17:43 +0200 Subject: MAP-E Message-ID: Hello Are there any known public deployments of MAP-E? What about CPE routers with support? The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to go the CGN route going forward. Of all the options, MAP-E appears to be the most elegant. Just add/remove some more headers on a packet and route it as normal. No need to invest in anything as our core routers can already do that. No worries about scale. BUT - our current CPE has zero support. We are too small that they will make this feature just for us, so I need to convince them there is going to be a demand. Alternatively I need to find a different CPE vendor that has MAP-E support, but are there any? What is holding MAP-E back? In my view MAP-E could be the end game for IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP networks are not forced to do a lot of processing such as CGN otherwise requires. I read some posts from Japan where users are reporting a deployment of MAP-E. Anyone know about that? Regards, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From swmike at swm.pp.se Fri Aug 2 12:58:41 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 2 Aug 2019 14:58:41 +0200 (CEST) Subject: MAP-E In-Reply-To: References: Message-ID: On Fri, 2 Aug 2019, Baldur Norddahl wrote: > be a demand. Alternatively I need to find a different CPE vendor that > has MAP-E support, but are there any? Broadcom supports MAP-E and LW4o6 encap/decap in fastpath on at least BCM63138 with their latest BSP versions. -- Mikael Abrahamsson email: swmike at swm.pp.se From jordi.palet at consulintel.es Fri Aug 2 13:37:36 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 02 Aug 2019 15:37:36 +0200 Subject: MAP-E In-Reply-To: References: Message-ID: Ask the vendor to support RFC8585. Also, you can do it with OpenWRT. I think 464XLAT is a better option and both of them are supported by OpenWRT. You can also use OpenSource (Jool) for the NAT64. Regards, Jordi @jordipalet El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" escribió: Hello Are there any known public deployments of MAP-E? What about CPE routers with support? The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to go the CGN route going forward. Of all the options, MAP-E appears to be the most elegant. Just add/remove some more headers on a packet and route it as normal. No need to invest in anything as our core routers can already do that. No worries about scale. BUT - our current CPE has zero support. We are too small that they will make this feature just for us, so I need to convince them there is going to be a demand. Alternatively I need to find a different CPE vendor that has MAP-E support, but are there any? What is holding MAP-E back? In my view MAP-E could be the end game for IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP networks are not forced to do a lot of processing such as CGN otherwise requires. I read some posts from Japan where users are reporting a deployment of MAP-E. Anyone know about that? Regards, Baldur ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at interlinx.bc.ca Fri Aug 2 13:48:06 2019 From: brian at interlinx.bc.ca (Brian J. Murrell) Date: Fri, 02 Aug 2019 09:48:06 -0400 Subject: MAP-E In-Reply-To: References: Message-ID: On Fri, 2019-08-02 at 15:37 +0200, JORDI PALET MARTINEZ via NANOG wrote: > Ask the vendor to support RFC8585. > > > > Also, you can do it with OpenWRT. > > > > I think 464XLAT is a better option and both of them are supported by > OpenWRT. > > > > You can also use OpenSource (Jool) for the NAT64. Will any of these (including MAP-E) support such nasty (in terms of burying IP addresses in data payloads) protocols as FTP and SIP/SDP? Cheers, 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 swmike at swm.pp.se Fri Aug 2 13:57:02 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 2 Aug 2019 15:57:02 +0200 (CEST) Subject: MAP-E In-Reply-To: References: Message-ID: On Fri, 2 Aug 2019, Brian J. Murrell wrote: > Will any of these (including MAP-E) support such nasty (in terms of > burying IP addresses in data payloads) protocols as FTP and SIP/SDP? LW4o6 is regular NAT44 and then tunnel encap. MAP-E is similar. So if there is NAT44 helper for these protocols then it should work the same as if you just had NAT44. -- Mikael Abrahamsson email: swmike at swm.pp.se From aled.w.morris at googlemail.com Fri Aug 2 13:58:45 2019 From: aled.w.morris at googlemail.com (Aled Morris) Date: Fri, 2 Aug 2019 14:58:45 +0100 Subject: MAP-E In-Reply-To: References: Message-ID: On Fri, 2 Aug 2019 at 14:49, Brian J. Murrell wrote: > Will any of these (including MAP-E) support such nasty (in terms of > burying IP addresses in data payloads) protocols as FTP and SIP/SDP? > I'm a fan of these solutions that (only) use NAT44 in the CPE as this is exactly what they're currently doing, and the CPE vendors have already "solved" the problem of application support (SIP, FTP etc.) at least as far as the end-user is concerned. It seems that introducing an extra layer of NAT at the ISP for NAT444 is creating a range of new problems, not least being scalability. Big CGNAT boxes are expensive. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From choprboy at dakotacom.net Thu Aug 1 22:21:59 2019 From: choprboy at dakotacom.net (Adrian) Date: Thu, 1 Aug 2019 15:21:59 -0700 Subject: Phoenix IX down/gone? In-Reply-To: <45f6d01d548b2$e960ee40$bc22cac0$@unwiredltd.com> References: <45f6701d548b0$fda153b0$f8e3fb10$@unwiredltd.com> <45f6d01d548b2$e960ee40$bc22cac0$@unwiredltd.com> Message-ID: <201908011521.59846.choprboy@dakotacom.net> On Thursday 01 August 2019 14:48:53 Peter Kranz via NANOG wrote: > Anyone know what happened to Phoenix IX? https://peeringdb.com/ix/66 They > seem off the air including website and phones.. permanently? > $DAYJOB is peered and passes traffic thru there. I don't have full access to check but it looks like traffic is flowing thru the peer points currently, for thing like MSN/OWA/etc. I can ping and reach peers, but all traceroute thru the peering point seems to now stop at the border. Maybe they added some sort of filtering and hosed themselves? Not sure. Adrian From paul at ninja-ix.net Fri Aug 2 01:07:00 2019 From: paul at ninja-ix.net (Paul Emmons) Date: Thu, 1 Aug 2019 18:07:00 -0700 Subject: Phoenix IX down/gone? Message-ID: VoIP is up and running but the web site server crashed. Currently restoring server. Voice number 602 688-6414 ~Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From edepa at ieee.org Fri Aug 2 08:17:58 2019 From: edepa at ieee.org (Etienne-Victor Depasquale) Date: Fri, 2 Aug 2019 10:17:58 +0200 Subject: The future of transport in the metro area In-Reply-To: <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> References: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> Message-ID: Mark, when you write "There is a healthy sharing of the pie between DWDM and packet to drive these Ethernet Metro's ", can you elaborate a little? Are you referring specifically to EoDWDM, or do you have something else in mind? Etienne On Fri, Aug 2, 2019 at 10:10 AM Mark Tinka wrote: > And just to add that I think that as part of the future, 5G is likely to > play a big part as well, somewhere between the Metro and the Access. > > Mark. > -- 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 baldur.norddahl at gmail.com Fri Aug 2 15:16:35 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 2 Aug 2019 17:16:35 +0200 Subject: MAP-E In-Reply-To: References: Message-ID: On Fri, Aug 2, 2019 at 3:49 PM Brian J. Murrell wrote: > > Will any of these (including MAP-E) support such nasty (in terms of > burying IP addresses in data payloads) protocols as FTP and SIP/SDP? > > All MAP-E does is reserving a port range for each customer. So customer A might be assigned port range 2000-2999, customer B gets 3000-3999 etc. The traffic is then routed to the correct customer using port range in addition to the destination IP address. This is done by encapsulating the original IPv4 packet in an IPv6 tunnel packet. Multiple customers share an IPv4 address each with an assigned port range. The customer CPE router does what it has always done. It does the NAT function but is restricted to only use the port numbers assigned. Therefore anything that works today will continue to work, providing it does not require access to hard coded port numbers. So customer A can not run a web server on port 80. But he could run a web server on port 2080 if he wanted to. Of course few customers are going to run inbound services with this setup. NAT helpers on the CPE for FTP and SIP should work as expected. I like the approach because no actual NAT is going on in the ISP network. It is almost the same as dual stack except a few bits of the port number is used for routing purposes. You need a device to do the MAP encapsulation but everything else in your network only has to do ordinary IPv6. Many core routers have MAP support now, so you might not even need a dedicated MAP encapsulation device. Regards, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Fri Aug 2 15:23:22 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 2 Aug 2019 17:23:22 +0200 Subject: MAP-E In-Reply-To: References: Message-ID: Hi Jordi My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid the expense and operative nightmare of having to run a redundant NAT server setup with thousands of users. MAP is the only alternative that avoids a provider run NAT server. Regards, Baldur On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG < nanog at nanog.org> wrote: > Ask the vendor to support RFC8585. > > > > Also, you can do it with OpenWRT. > > > > I think 464XLAT is a better option and both of them are supported by > OpenWRT. > > > > You can also use OpenSource (Jool) for the NAT64. > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" < > nanog-bounces at nanog.org en nombre de baldur.norddahl at gmail.com> escribió: > > > > Hello > > > > Are there any known public deployments of MAP-E? What about CPE routers > with support? > > > > The pricing on IPv4 is now at USD 20/address so I am thinking we are > forced to go the CGN route going forward. Of all the options, MAP-E appears > to be the most elegant. Just add/remove some more headers on a packet and > route it as normal. No need to invest in anything as our core routers can > already do that. No worries about scale. > > > > BUT - our current CPE has zero support. We are too small that they will > make this feature just for us, so I need to convince them there is going to > be a demand. Alternatively I need to find a different CPE vendor that has > MAP-E support, but are there any? > > > > What is holding MAP-E back? In my view MAP-E could be the end game for > IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible. > The ISP networks are not forced to do a lot of processing such as CGN > otherwise requires. > > > > I read some posts from Japan where users are reporting a deployment of > MAP-E. Anyone know about that? > > > > Regards, > > > > Baldur > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Fri Aug 2 15:32:27 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 02 Aug 2019 17:32:27 +0200 Subject: MAP-E In-Reply-To: References: Message-ID: I understand that, but the inconvenient is the fix allocation of ports per client, and not all the clients use the same number of ports. Every option has good and bad things. MAP is less efficient in terms of maximizing the “use” of the existing IPv4 addresses. https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ Regards, Jordi @jordipalet El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" escribió: Hi Jordi My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid the expense and operative nightmare of having to run a redundant NAT server setup with thousands of users. MAP is the only alternative that avoids a provider run NAT server. Regards, Baldur On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG wrote: Ask the vendor to support RFC8585. Also, you can do it with OpenWRT. I think 464XLAT is a better option and both of them are supported by OpenWRT. You can also use OpenSource (Jool) for the NAT64. Regards, Jordi @jordipalet El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" escribió: Hello Are there any known public deployments of MAP-E? What about CPE routers with support? The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to go the CGN route going forward. Of all the options, MAP-E appears to be the most elegant. Just add/remove some more headers on a packet and route it as normal. No need to invest in anything as our core routers can already do that. No worries about scale. BUT - our current CPE has zero support. We are too small that they will make this feature just for us, so I need to convince them there is going to be a demand. Alternatively I need to find a different CPE vendor that has MAP-E support, but are there any? What is holding MAP-E back? In my view MAP-E could be the end game for IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP networks are not forced to do a lot of processing such as CGN otherwise requires. I read some posts from Japan where users are reporting a deployment of MAP-E. Anyone know about that? Regards, Baldur ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at shout.net Fri Aug 2 15:33:43 2019 From: bryan at shout.net (Bryan Holloway) Date: Fri, 2 Aug 2019 17:33:43 +0200 Subject: MAP-E In-Reply-To: References: Message-ID: On 8/2/19 5:16 PM, Baldur Norddahl wrote: > > Multiple customers share an IPv4 address each with an assigned port range. > One downside that has been brought up on the list before is that a DDoS attack against a single subscriber will impact many, but that particular drawback may not outweigh the benefits (costs). From jayhanke at gmail.com Fri Aug 2 15:39:06 2019 From: jayhanke at gmail.com (Jay Hanke) Date: Fri, 2 Aug 2019 10:39:06 -0500 Subject: MAP-E In-Reply-To: References: Message-ID: Is there a summary presentation someplace laying out the options that are active in the wild with some deployment stats? On Fri, Aug 2, 2019 at 10:34 AM JORDI PALET MARTINEZ via NANOG wrote: > > I understand that, but the inconvenient is the fix allocation of ports per client, and not all the clients use the same number of ports. Every option has good and bad things. > > > > MAP is less efficient in terms of maximizing the “use” of the existing IPv4 addresses. > > > > https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ > > > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" escribió: > > > > Hi Jordi > > > > My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid the expense and operative nightmare of having to run a redundant NAT server setup with thousands of users. MAP is the only alternative that avoids a provider run NAT server. > > > > Regards, > > > > Baldur > > > > > > On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG wrote: > > Ask the vendor to support RFC8585. > > > > Also, you can do it with OpenWRT. > > > > I think 464XLAT is a better option and both of them are supported by OpenWRT. > > > > You can also use OpenSource (Jool) for the NAT64. > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" escribió: > > > > Hello > > > > Are there any known public deployments of MAP-E? What about CPE routers with support? > > > > The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to go the CGN route going forward. Of all the options, MAP-E appears to be the most elegant. Just add/remove some more headers on a packet and route it as normal. No need to invest in anything as our core routers can already do that. No worries about scale. > > > > BUT - our current CPE has zero support. We are too small that they will make this feature just for us, so I need to convince them there is going to be a demand. Alternatively I need to find a different CPE vendor that has MAP-E support, but are there any? > > > > What is holding MAP-E back? In my view MAP-E could be the end game for IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP networks are not forced to do a lot of processing such as CGN otherwise requires. > > > > I read some posts from Japan where users are reporting a deployment of MAP-E. Anyone know about that? > > > > Regards, > > > > Baldur > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > From baldur.norddahl at gmail.com Fri Aug 2 16:02:34 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 2 Aug 2019 18:02:34 +0200 Subject: MAP-E In-Reply-To: References: Message-ID: On Fri, Aug 2, 2019 at 5:33 PM Bryan Holloway wrote: > > > On 8/2/19 5:16 PM, Baldur Norddahl wrote: > > > > Multiple customers share an IPv4 address each with an assigned port > range. > > > > > One downside that has been brought up on the list before is that a DDoS > attack against a single subscriber will impact many, but that particular > drawback may not outweigh the benefits (costs). > > That is true for every CGN solution. At least with MAP the DDoS will only hit multiple users if the attackers hit random port numbers. Regards, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricpatara at gmail.com Fri Aug 2 16:07:03 2019 From: ricpatara at gmail.com (Ricardo Patara) Date: Fri, 2 Aug 2019 13:07:03 -0300 Subject: contact from AS 45382 Message-ID: <80e54077-606e-9970-1156-df68df549b5d@gmail.com> hi, any contact from ASN 45382 in the list? it seems one of its customers is announcing a ipv4 block allocated to other organization. the 45.164.24.0/24 is part of a /22 allocated to a brazilian organization and it is currently being announced with origin in the 45382 and transit via 4766, both in Korea. thanks From dovid at telecurve.com Fri Aug 2 16:14:33 2019 From: dovid at telecurve.com (Dovid Bender) Date: Fri, 2 Aug 2019 12:14:33 -0400 Subject: OT: Tech bag Message-ID: Hi, Sorry for the OT email. I travel extensively to DC's and my computer bag seems to keep collecting more tools which includes your usual console cables, spare everything, two laptops etc. My Swissgear has been taking a beating and I was wondering what others who have to lug around 30-35 pounds use. TIA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hf0002+nanog at uah.edu Fri Aug 2 16:19:08 2019 From: hf0002+nanog at uah.edu (Hunter Fuller) Date: Fri, 2 Aug 2019 11:19:08 -0500 Subject: OT: Tech bag In-Reply-To: References: Message-ID: I carry this. It's a preference I gained in my past life: https://www.kleintools.com/catalog/tool-storage/tradesman-pro-backpack I put my notebook (Surface Pro) in a sleeve and sandwich it between the halves. It hasn't gotten crushed to death yet. I'll admit this is not optimal. This one has since been released, and it has a laptop compartment. My co-worker loves it: https://www.kleintools.com/catalog/tradesman-pro-organizers/tradesman-pro-tech-backpack On Fri, Aug 2, 2019 at 11:14 AM Dovid Bender wrote: > > Hi, > > Sorry for the OT email. I travel extensively to DC's and my computer bag seems to keep collecting more tools which includes your usual console cables, spare everything, two laptops etc. My Swissgear has been taking a beating and I was wondering what others who have to lug around 30-35 pounds use. > > TIA. > > From baldur.norddahl at gmail.com Fri Aug 2 16:21:26 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Fri, 2 Aug 2019 18:21:26 +0200 Subject: MAP-E In-Reply-To: References: Message-ID: The goal is to minimize cost. Assuming 4 bits for the MAP routing (16 users sharing one IPv4), leaving 12 bits for customer ports (4096 ports) and a current price of USD 20 per IPv4 address, this gives a cost of USD 1.25 per user for a fully redundant solution. For us it is even cheaper as we can recirculate existing address space. Regards, Baldur On Fri, Aug 2, 2019 at 5:32 PM JORDI PALET MARTINEZ < jordi.palet at consulintel.es> wrote: > I understand that, but the inconvenient is the fix allocation of ports per > client, and not all the clients use the same number of ports. Every option > has good and bad things. > > > > MAP is less efficient in terms of maximizing the “use” of the existing > IPv4 addresses. > > > > https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ > > > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" < > nanog-bounces at nanog.org en nombre de baldur.norddahl at gmail.com> escribió: > > > > Hi Jordi > > > > My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to > avoid the expense and operative nightmare of having to run a redundant NAT > server setup with thousands of users. MAP is the only alternative that > avoids a provider run NAT server. > > > > Regards, > > > > Baldur > > > > > > On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG < > nanog at nanog.org> wrote: > > Ask the vendor to support RFC8585. > > > > Also, you can do it with OpenWRT. > > > > I think 464XLAT is a better option and both of them are supported by > OpenWRT. > > > > You can also use OpenSource (Jool) for the NAT64. > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" < > nanog-bounces at nanog.org en nombre de baldur.norddahl at gmail.com> escribió: > > > > Hello > > > > Are there any known public deployments of MAP-E? What about CPE routers > with support? > > > > The pricing on IPv4 is now at USD 20/address so I am thinking we are > forced to go the CGN route going forward. Of all the options, MAP-E appears > to be the most elegant. Just add/remove some more headers on a packet and > route it as normal. No need to invest in anything as our core routers can > already do that. No worries about scale. > > > > BUT - our current CPE has zero support. We are too small that they will > make this feature just for us, so I need to convince them there is going to > be a demand. Alternatively I need to find a different CPE vendor that has > MAP-E support, but are there any? > > > > What is holding MAP-E back? In my view MAP-E could be the end game for > IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible. > The ISP networks are not forced to do a lot of processing such as CGN > otherwise requires. > > > > I read some posts from Japan where users are reporting a deployment of > MAP-E. Anyone know about that? > > > > Regards, > > > > Baldur > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.h at bendtel.com Fri Aug 2 16:24:03 2019 From: tim.h at bendtel.com (Tim Howe) Date: Fri, 2 Aug 2019 09:24:03 -0700 Subject: Removing defunct IRR records from LEVEL3 rr Message-ID: <20190802092403.7285e96f@wind.dirtymonday.net> Has anyone successfully gotten Level3/Centurylink to remove defunct IRR objects? All paths seem to lead to trying to get me to log into a customer portal. If they have incorrect objects for IP resources I control, how am I supposed to get them cleaned up if I am not a customer? --TimH From jordi.palet at consulintel.es Fri Aug 2 17:10:35 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 02 Aug 2019 19:10:35 +0200 Subject: MAP-E In-Reply-To: References: Message-ID: The cost of sharing IPs in a static way, is that services such as Sony Playstation Network will put those addresses in the black list, so you need to buy more addresses. This hasn’t been the case for 464XLAT/NAT64, which shares the addresses dynamically. Furthermore, if some users need less ports than others, you “infra-utilize” those addresses, which again is not the case for 464XLAT/NAT64. Each user gets automatically as many ports as he needs at every moment. So, you save money in terms of addresses, that you can invest in a couple of servers running a redundant NAT64 setup (https://www.jool.mx/en/session-synchronization.html). Those servers can be actually VMs, so you don’t need dedicated hardware, especially because when you deploy IPv6 with 464XLAT, typically 75% (and going up) of you traffic will be IPv6 and only 25% will go thru the NAT64. Regards, Jordi @jordipalet El 2/8/19 18:24, "NANOG en nombre de Baldur Norddahl" escribió: The goal is to minimize cost. Assuming 4 bits for the MAP routing (16 users sharing one IPv4), leaving 12 bits for customer ports (4096 ports) and a current price of USD 20 per IPv4 address, this gives a cost of USD 1.25 per user for a fully redundant solution. For us it is even cheaper as we can recirculate existing address space. Regards, Baldur On Fri, Aug 2, 2019 at 5:32 PM JORDI PALET MARTINEZ wrote: I understand that, but the inconvenient is the fix allocation of ports per client, and not all the clients use the same number of ports. Every option has good and bad things. MAP is less efficient in terms of maximizing the “use” of the existing IPv4 addresses. https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ Regards, Jordi @jordipalet El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" escribió: Hi Jordi My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid the expense and operative nightmare of having to run a redundant NAT server setup with thousands of users. MAP is the only alternative that avoids a provider run NAT server. Regards, Baldur On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG wrote: Ask the vendor to support RFC8585. Also, you can do it with OpenWRT. I think 464XLAT is a better option and both of them are supported by OpenWRT. You can also use OpenSource (Jool) for the NAT64. Regards, Jordi @jordipalet El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" escribió: Hello Are there any known public deployments of MAP-E? What about CPE routers with support? The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to go the CGN route going forward. Of all the options, MAP-E appears to be the most elegant. Just add/remove some more headers on a packet and route it as normal. No need to invest in anything as our core routers can already do that. No worries about scale. BUT - our current CPE has zero support. We are too small that they will make this feature just for us, so I need to convince them there is going to be a demand. Alternatively I need to find a different CPE vendor that has MAP-E support, but are there any? What is holding MAP-E back? In my view MAP-E could be the end game for IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP networks are not forced to do a lot of processing such as CGN otherwise requires. I read some posts from Japan where users are reporting a deployment of MAP-E. Anyone know about that? Regards, Baldur ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From egon at egon.cc Fri Aug 2 16:42:14 2019 From: egon at egon.cc (James Downs) Date: Fri, 2 Aug 2019 09:42:14 -0700 Subject: OT: Tech bag In-Reply-To: References: Message-ID: <20190802164214.GG19852@nemesis.egontech.com> On Fri, Aug 02, 2019 at 11:19:08AM -0500, Hunter Fuller wrote: > This one has since been released, and it has a laptop compartment. My Yeah, I definitely look for some sort of laptop compartment. If not padded on its own, I stick the laptop into a padded sleeve. I run one of these: https://tacticalgear.com/511-all-hazards-prime-backpack-black And subdivide for a particular loadout with various smaller cases like: https://countycomm.com/collections/view-all-storage-products/products/apx-multi-purpose-dual-zip-case-by-maratac or something similar to these: https://www.casesbysource.com/category/soft-padded-cases Unfortunately Deep Outdoors, who made a number of great soft-sided padded cases has gone out of business... From laszlo at heliacal.net Fri Aug 2 18:01:48 2019 From: laszlo at heliacal.net (Laszlo Hanyecz) Date: Fri, 2 Aug 2019 18:01:48 +0000 Subject: OT: Tech bag In-Reply-To: <20190802164214.GG19852@nemesis.egontech.com> References: <20190802164214.GG19852@nemesis.egontech.com> Message-ID: <6aa6221f-6aaa-4758-d5b6-deadc28d6373@heliacal.net> On 2019-08-02 16:42, James Downs wrote: > On Fri, Aug 02, 2019 at 11:19:08AM -0500, Hunter Fuller wrote: > >> This one has since been released, and it has a laptop compartment. My > Yeah, I definitely look for some sort of laptop compartment. If not > padded on its own, I stick the laptop into a padded sleeve. I run one > of these: https://tacticalgear.com/511-all-hazards-prime-backpack-black > > And subdivide for a particular loadout with various smaller cases like: > https://countycomm.com/collections/view-all-storage-products/products/apx-multi-purpose-dual-zip-case-by-maratac > > or something similar to these: https://www.casesbysource.com/category/soft-padded-cases > > Unfortunately Deep Outdoors, who made a number of great soft-sided padded cases > has gone out of business... > I use GORUCK GR1 https://www.goruck.com/gr1 It has a padded laptop compartment. -Laszlo From cscora at apnic.net Fri Aug 2 18:04:20 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Aug 2019 04:04:20 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190802180420.A9175C44A1@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 03 Aug, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 766119 Prefixes after maximum aggregation (per Origin AS): 295002 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 368513 Total ASes present in the Internet Routing Table: 65068 Prefixes per ASN: 11.77 Origin-only ASes present in the Internet Routing Table: 55956 Origin ASes announcing only one prefix: 23986 Transit ASes present in the Internet Routing Table: 9112 Transit-only ASes present in the Internet Routing Table: 287 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: 24 Number of instances of unregistered ASNs: 24 Number of 32-bit ASNs allocated by the RIRs: 28103 Number of 32-bit ASNs visible in the Routing Table: 22950 Prefixes from 32-bit ASNs in the Routing Table: 103973 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: 286 Number of addresses announced to Internet: 2842112000 Equivalent to 169 /8s, 103 /16s and 48 /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: 256375 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 206466 Total APNIC prefixes after maximum aggregation: 61655 APNIC Deaggregation factor: 3.35 Prefixes being announced from the APNIC address blocks: 201513 Unique aggregates announced from the APNIC address blocks: 84021 APNIC Region origin ASes present in the Internet Routing Table: 9933 APNIC Prefixes per ASN: 20.29 APNIC Region origin ASes announcing only one prefix: 2753 APNIC Region transit ASes present in the Internet Routing Table: 1480 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4936 Number of APNIC addresses announced to Internet: 771136640 Equivalent to 45 /8s, 246 /16s and 156 /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: 226639 Total ARIN prefixes after maximum aggregation: 105937 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 225670 Unique aggregates announced from the ARIN address blocks: 107080 ARIN Region origin ASes present in the Internet Routing Table: 18544 ARIN Prefixes per ASN: 12.17 ARIN Region origin ASes announcing only one prefix: 6863 ARIN Region transit ASes present in the Internet Routing Table: 1914 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: 2840 Number of ARIN addresses announced to Internet: 1070847616 Equivalent to 63 /8s, 211 /16s and 214 /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: 213722 Total RIPE prefixes after maximum aggregation: 100218 RIPE Deaggregation factor: 2.13 Prefixes being announced from the RIPE address blocks: 209894 Unique aggregates announced from the RIPE address blocks: 123697 RIPE Region origin ASes present in the Internet Routing Table: 26301 RIPE Prefixes per ASN: 7.98 RIPE Region origin ASes announcing only one prefix: 11623 RIPE Region transit ASes present in the Internet Routing Table: 3745 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 35 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8349 Number of RIPE addresses announced to Internet: 720526848 Equivalent to 42 /8s, 242 /16s and 94 /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: 98458 Total LACNIC prefixes after maximum aggregation: 22827 LACNIC Deaggregation factor: 4.31 Prefixes being announced from the LACNIC address blocks: 99765 Unique aggregates announced from the LACNIC address blocks: 43960 LACNIC Region origin ASes present in the Internet Routing Table: 8686 LACNIC Prefixes per ASN: 11.49 LACNIC Region origin ASes announcing only one prefix: 2285 LACNIC Region transit ASes present in the Internet Routing Table: 1596 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: 6241 Number of LACNIC addresses announced to Internet: 173502976 Equivalent to 10 /8s, 87 /16s and 114 /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: 20809 Total AfriNIC prefixes after maximum aggregation: 4345 AfriNIC Deaggregation factor: 4.79 Prefixes being announced from the AfriNIC address blocks: 28991 Unique aggregates announced from the AfriNIC address blocks: 9493 AfriNIC Region origin ASes present in the Internet Routing Table: 1302 AfriNIC Prefixes per ASN: 22.27 AfriNIC Region origin ASes announcing only one prefix: 462 AfriNIC Region transit ASes present in the Internet Routing Table: 252 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: 584 Number of AfriNIC addresses announced to Internet: 105849344 Equivalent to 6 /8s, 79 /16s and 34 /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 4879 591 567 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3224 1459 31 VIETEL-AS-AP Viettel Group, VN 45899 3056 1766 113 VNPT-AS-VN VNPT Corp, VN 9808 2730 9043 63 CMNET-GD Guangdong Mobile Communication 9829 2689 1488 559 BSNL-NIB National Internet Backbone, IN 4766 2540 11119 761 KIXS-AS-KR Korea Telecom, KR 7713 2225 670 594 TELKOMNET-AS-AP PT Telekomunikasi Indon 4755 2156 442 192 TATACOMM-AS TATA Communications formerl 9498 2150 430 209 BBIL-AP BHARTI Airtel Ltd., IN 9394 2073 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 3685 240 617 CABLEONE - CABLE ONE, INC., US 6327 3541 1324 90 SHAW - Shaw Communications Inc., CA 22773 3446 2974 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 3056 6390 1441 AMAZON-02 - Amazon.com, Inc., US 16625 2656 1394 1925 AKAMAI-AS - Akamai Technologies, Inc., 30036 2160 346 249 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2151 2755 525 CHARTER-20115 - Charter Communications, 18566 2093 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 5476 1629 141 UNI2-AS, ES 39891 3780 219 19 ALJAWWALSTC-AS, SA 8551 3327 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2720 508 1931 AKAMAI-ASN1, US 31334 2602 484 13 KABELDEUTSCHLAND-AS, DE 12389 2362 2230 661 ROSTELECOM-AS, RU 34984 2116 346 545 TELLCOM-AS, TR 9009 1668 179 903 M247, GB 9121 1610 1692 18 TTNET, TR 13188 1604 100 47 TRIOLAN, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6203 3368 598 Uninet S.A. de C.V., MX 10620 3384 533 455 Telmex Colombia S.A., CO 11830 2691 370 54 Instituto Costarricense de Electricidad 6503 1626 391 421 Axtel, S.A.B. de C.V., MX 7303 1475 1022 281 Telecom Argentina S.A., AR 28573 1158 2236 207 CLARO S.A., BR 6147 1096 377 31 Telefonica del Peru S.A.A., PE 3816 1044 526 122 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 986 478 246 Mega Cable, S.A. de C.V., MX 11172 935 111 59 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 1185 393 21 LINKdotNET-AS, EG 24835 886 634 22 RAYA-AS, EG 36992 852 1535 76 ETISALAT-MISR, EG 36903 843 424 112 MT-MPLS, MA 8452 666 1859 20 TE-AS TE-AS, EG 29571 522 68 11 ORANGE-COTE-IVOIRE, CI 37492 482 470 57 ORANGE-, TN 37342 414 32 1 MOVITEL, MZ 15399 388 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 6203 3368 598 Uninet S.A. de C.V., MX 12479 5476 1629 141 UNI2-AS, ES 7545 4879 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 3685 240 617 CABLEONE - CABLE ONE, INC., US 6327 3541 1324 90 SHAW - Shaw Communications Inc., CA 22773 3446 2974 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3384 533 455 Telmex Colombia S.A., CO 8551 3327 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 5476 5335 UNI2-AS, ES 7545 4879 4312 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 4039 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3780 3761 ALJAWWALSTC-AS, SA 6327 3541 3451 SHAW - Shaw Communications Inc., CA 22773 3446 3289 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3327 3281 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3224 3193 VIETEL-AS-AP Viettel Group, VN 11492 3685 3068 CABLEONE - CABLE ONE, INC., US 45899 3056 2943 VNPT-AS-VN VNPT Corp, VN 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.140.0/22 37500 -Reserved AS-, ZZ 41.78.180.0/23 37265 -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:293 /13:571 /14:1131 /15:1900 /16:13265 /17:8030 /18:13920 /19:25830 /20:40402 /21:47195 /22:95536 /23:77443 /24:439553 /25:891 /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 4432 5476 UNI2-AS, ES 6327 3330 3541 SHAW - Shaw Communications Inc., CA 7155 3156 4064 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 3780 ALJAWWALSTC-AS, SA 11492 2888 3685 CABLEONE - CABLE ONE, INC., US 8551 2780 3327 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2677 3446 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 31334 2491 2602 KABELDEUTSCHLAND-AS, DE 11830 2039 2691 Instituto Costarricense de Electricidad y Telec 18566 1988 2093 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1716 2:1063 3:6 4:21 5:3081 6:47 7:1 8:1344 9:1 12:1790 13:389 14:2083 15:41 16:7 17:265 18:80 20:56 23:2853 24:2586 25:4 27:2440 31:2706 32:106 35:38 36:915 37:3130 38:1800 39:270 40:106 41:3228 42:833 43:2079 44:163 45:9283 46:3398 47:263 49:1377 50:1093 51:340 52:1011 54:273 55:675 56:6 57:47 58:1745 59:1098 60:562 61:2178 62:1969 63:1854 64:5001 65:2226 66:4784 67:2726 68:1177 69:3570 70:1383 71:662 72:2684 74:2703 75:1294 76:570 77:2553 78:1859 79:2373 80:1839 81:1490 82:1141 83:950 84:1151 85:2309 86:549 87:1533 88:1053 89:2547 90:223 91:6594 92:1446 93:2477 94:2501 95:3628 96:945 97:340 98:957 99:811 100:88 101:1189 102:597 103:21796 104:3624 105:277 106:809 107:1782 108:697 109:3789 110:1734 111:2003 112:1549 113:1409 114:1274 115:1738 116:1751 117:1950 118:2203 119:1644 120:1061 121:1064 122:2287 123:1799 124:1502 125:2030 128:1377 129:850 130:538 131:1831 132:801 133:220 134:1097 135:257 136:586 137:792 138:2081 139:916 140:616 141:884 142:783 143:1060 144:871 145:277 146:1372 147:839 148:1759 149:1008 150:810 151:1018 152:1111 153:344 154:4545 155:883 156:1941 157:1057 158:683 159:1947 160:1603 161:958 162:2982 163:828 164:1243 165:1179 166:514 167:1406 168:3465 169:478 170:4194 171:614 172:1688 173:2210 174:1042 175:997 176:2459 177:4093 178:2739 179:1399 180:2143 181:2358 182:2752 183:1110 184:2286 185:15447 186:3669 187:2491 188:3468 189:2016 190:8192 191:1465 192:10086 193:6754 194:5509 195:4179 196:3051 197:1778 198:5933 199:5977 200:7190 201:5128 202:10421 203:10235 204:4563 205:3059 206:3224 207:3261 208:3943 209:4288 210:3932 211:2028 212:3238 213:2971 214:1129 215:55 216:5921 217:2229 218:883 219:601 220:1921 221:969 222:975 223:1365 End of report From edepa at ieee.org Fri Aug 2 18:06:41 2019 From: edepa at ieee.org (Etienne-Victor Depasquale) Date: Fri, 2 Aug 2019 20:06:41 +0200 Subject: The future of transport in the metro area In-Reply-To: <6d8f5d52-c0b9-ce5e-48bd-7d1f096d4834@seacom.mu> References: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> <6d8f5d52-c0b9-ce5e-48bd-7d1f096d4834@seacom.mu> Message-ID: Bear with me one more time as I drill down a little and spell things out. I've realized that there may be more than one interpretation of "EoDWDM". Are you referring to: (a) Ethernet packets in OTU frames - thereby implying an underlying OTN? (b) Ethernet optical SFP+ transceivers with a cable connection into a transponder plugging into a DWDM Mux or DWDM OADM? (no circuit transport) On Fri, Aug 2, 2019 at 10:32 AM Mark Tinka wrote: > > > On 2/Aug/19 10:17, Etienne-Victor Depasquale wrote: > > > Mark, when you write "There is a healthy sharing of the pie between > > DWDM and packet to drive these Ethernet Metro's ", can you elaborate a > > little? Are you referring specifically to EoDWDM, or do you have > > something else in mind? > > EoDWDM. > > Ethernet is very widely used, regardless of the Transport technology. > > In other markets, you will find SDH Transports delivering Ethernet as > well (EoSDH), although that is dying in favour of EoDWDM or just > Ethernet over (dark) fibre. > > Mark. > -- 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 davis at udel.edu Fri Aug 2 18:03:41 2019 From: davis at udel.edu (Michael Davis) Date: Fri, 2 Aug 2019 14:03:41 -0400 Subject: Removing defunct IRR records from LEVEL3 rr In-Reply-To: <20190802092403.7285e96f@wind.dirtymonday.net> References: <20190802092403.7285e96f@wind.dirtymonday.net> Message-ID: <7e3c4bee-e121-cd22-cfcd-7203e128ea70@udel.edu> I recently did this with an email to routing at level3.net Took all of a few hours, no issues.. thanks mike On 8/2/19 12:24 PM, Tim Howe wrote: > Has anyone successfully gotten Level3/Centurylink to remove defunct IRR > objects? All paths seem to lead to trying to get me to log into a > customer portal. If they have incorrect objects for IP resources I > control, how am I supposed to get them cleaned up if I am not a > customer? > > --TimH -- Mike Davis Manager, Network Routing and Switching IT - University of Delaware - 302.831.8756 Newark, DE 19716 Email davis at udel.edu From covici at ccs.covici.com Fri Aug 2 18:21:31 2019 From: covici at ccs.covici.com (John Covici) Date: Fri, 02 Aug 2019 14:21:31 -0400 Subject: OT: Tech bag In-Reply-To: References: Message-ID: https://www.tombin.com has some great bags for laptops, etc. Not cheap but very good stuff. On Fri, 02 Aug 2019 12:19:08 -0400, Hunter Fuller wrote: > > I carry this. It's a preference I gained in my past life: > https://www.kleintools.com/catalog/tool-storage/tradesman-pro-backpack > > I put my notebook (Surface Pro) in a sleeve and sandwich it between > the halves. It hasn't gotten crushed to death yet. I'll admit this is > not optimal. > > This one has since been released, and it has a laptop compartment. My > co-worker loves it: > https://www.kleintools.com/catalog/tradesman-pro-organizers/tradesman-pro-tech-backpack > > On Fri, Aug 2, 2019 at 11:14 AM Dovid Bender wrote: > > > > Hi, > > > > Sorry for the OT email. I travel extensively to DC's and my computer bag seems to keep collecting more tools which includes your usual console cables, spare everything, two laptops etc. My Swissgear has been taking a beating and I was wondering what others who have to lug around 30-35 pounds use. > > > > TIA. > > > > > -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una covici at ccs.covici.com From morrowc.lists at gmail.com Fri Aug 2 18:52:26 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Aug 2019 14:52:26 -0400 Subject: Removing defunct IRR records from LEVEL3 rr In-Reply-To: <7e3c4bee-e121-cd22-cfcd-7203e128ea70@udel.edu> References: <20190802092403.7285e96f@wind.dirtymonday.net> <7e3c4bee-e121-cd22-cfcd-7203e128ea70@udel.edu> Message-ID: agree with michael, they were super helpful to me over the last few months. On Fri, Aug 2, 2019 at 2:18 PM Michael Davis wrote: > > I recently did this with an email to routing at level3.net > > Took all of a few hours, no issues.. > > thanks > mike > > On 8/2/19 12:24 PM, Tim Howe wrote: > > Has anyone successfully gotten Level3/Centurylink to remove defunct IRR > > objects? All paths seem to lead to trying to get me to log into a > > customer portal. If they have incorrect objects for IP resources I > > control, how am I supposed to get them cleaned up if I am not a > > customer? > > > > --TimH > > > -- > Mike Davis > Manager, Network Routing and Switching > IT - University of Delaware - 302.831.8756 > Newark, DE 19716 Email davis at udel.edu > From morrowc.lists at gmail.com Fri Aug 2 18:54:49 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Aug 2019 14:54:49 -0400 Subject: OT: Tech bag In-Reply-To: References: Message-ID: On Fri, Aug 2, 2019 at 2:50 PM John Covici wrote: > > https://www.tombin.com has some great bags for laptops, etc. Not 'server has no ip address' ..... $ ping www.tombin.com PING www.tombin.com (127.0.0.1) good try to get us all infected by malware... On a less funny note, try out some of the various osprey bags. > cheap but very good stuff. > > On Fri, 02 Aug 2019 12:19:08 -0400, > Hunter Fuller wrote: > > > > I carry this. It's a preference I gained in my past life: > > https://www.kleintools.com/catalog/tool-storage/tradesman-pro-backpack > > > > I put my notebook (Surface Pro) in a sleeve and sandwich it between > > the halves. It hasn't gotten crushed to death yet. I'll admit this is > > not optimal. > > > > This one has since been released, and it has a laptop compartment. My > > co-worker loves it: > > https://www.kleintools.com/catalog/tradesman-pro-organizers/tradesman-pro-tech-backpack > > > > On Fri, Aug 2, 2019 at 11:14 AM Dovid Bender wrote: > > > > > > Hi, > > > > > > Sorry for the OT email. I travel extensively to DC's and my computer bag seems to keep collecting more tools which includes your usual console cables, spare everything, two laptops etc. My Swissgear has been taking a beating and I was wondering what others who have to lug around 30-35 pounds use. > > > > > > TIA. > > > > > > > > > > -- > Your life is like a penny. You're going to lose it. The question is: > How do > you spend it? > > John Covici wb2una > covici at ccs.covici.com From lathama at gmail.com Fri Aug 2 19:11:36 2019 From: lathama at gmail.com (Andrew Latham) Date: Fri, 2 Aug 2019 14:11:36 -0500 Subject: OT: Tech bag In-Reply-To: References: Message-ID: Correct url may be https://www.tombihn.com/ On Fri, Aug 2, 2019 at 1:50 PM John Covici wrote: > https://www.tombin.com has some great bags for laptops, etc. Not > cheap but very good stuff. > > On Fri, 02 Aug 2019 12:19:08 -0400, > Hunter Fuller wrote: > > > > I carry this. It's a preference I gained in my past life: > > https://www.kleintools.com/catalog/tool-storage/tradesman-pro-backpack > > > > I put my notebook (Surface Pro) in a sleeve and sandwich it between > > the halves. It hasn't gotten crushed to death yet. I'll admit this is > > not optimal. > > > > This one has since been released, and it has a laptop compartment. My > > co-worker loves it: > > > https://www.kleintools.com/catalog/tradesman-pro-organizers/tradesman-pro-tech-backpack > > > > On Fri, Aug 2, 2019 at 11:14 AM Dovid Bender > wrote: > > > > > > Hi, > > > > > > Sorry for the OT email. I travel extensively to DC's and my computer > bag seems to keep collecting more tools which includes your usual console > cables, spare everything, two laptops etc. My Swissgear has been taking a > beating and I was wondering what others who have to lug around 30-35 pounds > use. > > > > > > TIA. > > > > > > > > > > -- > Your life is like a penny. You're going to lose it. The question is: > How do > you spend it? > > John Covici wb2una > covici at ccs.covici.com > -- - Andrew "lathama" Latham - -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Fri Aug 2 20:10:32 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 2 Aug 2019 22:10:32 +0200 Subject: The future of transport in the metro area In-Reply-To: References: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> <6d8f5d52-c0b9-ce5e-48bd-7d1f096d4834@seacom.mu> Message-ID: <7ffb97b2-c9b1-8c5c-4cd7-e85886c22b2e@seacom.mu> On 2/Aug/19 20:06, Etienne-Victor Depasquale wrote: > Bear with me one more time as I drill down a little and spell things > out. I've realized that there may be more than one interpretation of > "EoDWDM". Are you referring to: > > (a) Ethernet packets in OTU frames - thereby implying an underlying OTN? > > (b) Ethernet optical SFP+ transceivers with a cable connection into a > transponder plugging into a DWDM Mux or DWDM OADM? (no circuit transport) Either one would count as EoDWDM, in my book. The general use-case for OTN is to have SDH/SONET-like OAM characteristics, but over the DWDM network. In basic deployments, there was a time when folk argued about whether they take LAN-PHY or WAN-PHY EoDWDM services from providers. The OTN vs. DWDM discussion kind of falls around there, in my opinion. Considering that almost all use-cases for EoDWDM are into router ports, where basic day-to-day Ethernet is the cheapest and simplest option, I haven't heard of any customers asking for WAN-PHY or OTN in the last 3 years. Not on our network at least, anyway... I think the costs of WAN-PHY/OTN re: OAM have been outweighed by making the right choice in choosing an operator that is able to deliver an SLA, back it up, and have a NOC that works well. Now, the next step in all this that is starting to gain a bit of traction is "spectrum", i.e., rather than take a normal grey service from a Transport operator, have them deliver you a portion of the DWDM spectrum so that you can run as much bandwidth as you want over their network. Think of it as dark fibre, but lit... Mark. From pete at tccmail.ca Fri Aug 2 20:52:12 2019 From: pete at tccmail.ca (Pete Baldwin - TCC) Date: Fri, 02 Aug 2019 16:52:12 -0400 Subject: OT: Tech bag In-Reply-To: References: Message-ID: I use a Veto Pro Pac https://www.vetopropac.com/product/tech-pac-lt/ More focused on tools, but it fits my Thinkpad p50 without issue, all of my cables, and most of the tools that I use day to day. I used to use more tactical focused backpacks but I kept ripping compartments or breaking zippers. This thing has held up really well so far. -- Tuckersmith Communications IT Manager O: 519-565-2400 F: 519-565-2477 C: 519-441-7383 On August 2, 2019 12:14:33 p.m. EDT, Dovid Bender wrote: >Hi, > >Sorry for the OT email. I travel extensively to DC's and my computer >bag >seems to keep collecting more tools which includes your usual console >cables, spare everything, two laptops etc. My Swissgear has been taking >a >beating and I was wondering what others who have to lug around 30-35 >pounds >use. > >TIA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Fri Aug 2 21:00:56 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Fri, 02 Aug 2019 17:00:56 -0400 Subject: OT: Tech bag In-Reply-To: References: Message-ID: <21384.1564779656@turing-police> On Fri, 02 Aug 2019 14:54:49 -0400, Christopher Morrow said: > 'server has no ip address' ..... > $ ping www.tombin.com > PING www.tombin.com (127.0.0.1) > > good try to get us all infected by malware... Anybody who gets infected by malware from that IP address has bigger problems.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From morrowc.lists at gmail.com Fri Aug 2 21:05:00 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Aug 2019 17:05:00 -0400 Subject: OT: Tech bag In-Reply-To: <21384.1564779656@turing-police> References: <21384.1564779656@turing-police> Message-ID: On Fri, Aug 2, 2019 at 5:01 PM Valdis Klētnieks wrote: > > On Fri, 02 Aug 2019 14:54:49 -0400, Christopher Morrow said: > > 'server has no ip address' ..... > > $ ping www.tombin.com > > PING www.tombin.com (127.0.0.1) > > > > good try to get us all infected by malware... > > Anybody who gets infected by malware from that IP address has bigger problems.... https://media.giphy.com/media/6iLiUnuthOSu4/giphy.gif > > From tb at tburke.us Fri Aug 2 23:32:59 2019 From: tb at tburke.us (Tim Burke) Date: Fri, 02 Aug 2019 18:32:59 -0500 Subject: Spam due to new ARIN allocation Message-ID: <1e519874-5cac-4c16-925a-96995f1c33e7@www.fastmail.com> We recently received a new ASN from ARIN - you know what that means... the sales vultures come out to play! So far, it has resulted in spam from Cogent (which is, of course, to be expected), and now another company called "CapCon Networks" - http://www.capconnetworks.com. As far as I am aware, this practice is against ARIN's Terms of Use. Is it worth reporting to ARIN, or perhaps it's worth creating a List of People To Never Do Business With™, complete with these jokers, and other vultures that engage in similar tactics? Regards, Tim Burke tim at burke.us From lists.nanog at monmotha.net Fri Aug 2 23:36:19 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 2 Aug 2019 19:36:19 -0400 Subject: Spam due to new ARIN allocation In-Reply-To: <1e519874-5cac-4c16-925a-96995f1c33e7@www.fastmail.com> References: <1e519874-5cac-4c16-925a-96995f1c33e7@www.fastmail.com> Message-ID: <3c24f719-08df-6fce-aec7-ead662b96d04@monmotha.net> On 8/2/19 7:32 PM, Tim Burke wrote: > So far, it has resulted in spam from Cogent (which is, of course, to be expected), and now another company called "CapCon Networks" -http://www.capconnetworks.com. As far as I am aware, this practice is against ARIN's Terms of Use. Is it worth reporting to ARIN, or perhaps it's worth creating a List of People To Never Do Business With™, complete with these jokers, and other vultures that engage in similar tactics? I'm not sure what you can really do to prevent it. It's the pain of having publicly available whois data which I'd argue the usefulness of, especially for ASNs, outweighs the spam potential for. Just bin it and don't do business with them. And yes, "CapCon Networks" also contacted me in a similar situation. You can imagine how much I want to do business with them... Name and shame, I guess. -- Brandon Martin From ryan at rkhtech.org Fri Aug 2 23:47:14 2019 From: ryan at rkhtech.org (Ryan Hamel) Date: Fri, 2 Aug 2019 16:47:14 -0700 Subject: Spam due to new ARIN allocation In-Reply-To: References: <1e519874-5cac-4c16-925a-96995f1c33e7@www.fastmail.com> Message-ID: > > Do it. I'd name and shame all of them. Ryan On Fri, Aug 2, 2019, 4:33 PM Tim Burke wrote: > >> We recently received a new ASN from ARIN - you know what that means... >> the sales vultures come out to play! >> >> So far, it has resulted in spam from Cogent (which is, of course, to be >> expected), and now another company called "CapCon Networks" - >> http://www.capconnetworks.com. As far as I am aware, this practice is >> against ARIN's Terms of Use. Is it worth reporting to ARIN, or perhaps it's >> worth creating a List of People To Never Do Business With™, complete with >> these jokers, and other vultures that engage in similar tactics? >> >> Regards, >> Tim Burke >> tim at burke.us >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml at knight-networks.com Sat Aug 3 00:40:06 2019 From: ml at knight-networks.com (Brian Knight) Date: Fri, 2 Aug 2019 19:40:06 -0500 Subject: OT: Tech bag In-Reply-To: References: Message-ID: <8F48D1DD-ABC5-4C77-9223-80521CED36D6@knight-networks.com> About a year ago, I switched from a Swissgear to a High Sierra Endeavor wheeled backpack and been very happy with it. Most of the time I carry < 15 lbs of gear when I commute to the office on the train, so I’ll have it on my back. But when I head to the colo with a heavy load, it’s handy (and a real relief to my neck and shoulders) to be able to switch to wheeled mode. It’s held an ASR920 + laptop + hardware + usual load with a bit of room to spare. HTH, -Brian > On Aug 2, 2019, at 11:14 AM, Dovid Bender wrote: > > Hi, > > Sorry for the OT email. I travel extensively to DC's and my computer bag seems to keep collecting more tools which includes your usual console cables, spare everything, two laptops etc. My Swissgear has been taking a beating and I was wondering what others who have to lug around 30-35 pounds use. > > TIA. > > From lists.nanog at monmotha.net Sat Aug 3 01:14:02 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 2 Aug 2019 21:14:02 -0400 Subject: The future of transport in the metro area In-Reply-To: <7ffb97b2-c9b1-8c5c-4cd7-e85886c22b2e@seacom.mu> References: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> <6d8f5d52-c0b9-ce5e-48bd-7d1f096d4834@seacom.mu> <7ffb97b2-c9b1-8c5c-4cd7-e85886c22b2e@seacom.mu> Message-ID: On 8/2/19 4:10 PM, Mark Tinka wrote: > Now, the next step in all this that is starting to gain a bit of > traction is "spectrum", i.e., rather than take a normal grey service > from a Transport operator, have them deliver you a portion of the DWDM > spectrum so that you can run as much bandwidth as you want over their > network. Think of it as dark fibre, but lit... How are they handling optical power balancing across amplifiers and such? Do they just trust the customer to provide light at the power levels agreed upon? Bulk attenuate the entire "spectrum" automatically? Monitor and drop the whole lot if something is out of whack and causing saturation or gain balance problems for others? Or is this something you're only seeing at metro distances where separate amplifiers are superfluous? I've inquired with a few metro operators in my area about something like this, albeit a few years ago, and I got a pretty hard "no way we'd ever do that" out of them presumably for the reasons above. -- Brandon Martin From mohta at necom830.hpcl.titech.ac.jp Sat Aug 3 03:15:12 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 3 Aug 2019 12:15:12 +0900 Subject: MAP-E In-Reply-To: References: Message-ID: Brian J. Murrell wrote: >> You can also use OpenSource (Jool) for the NAT64. > > Will any of these (including MAP-E) support such nasty (in terms of > burying IP addresses in data payloads) protocols as FTP and SIP/SDP? Are you saying ICMP and DNS nasty? As DNS protocol is still actively maintained, keeping NAT gateways transparent to DNS is not easy. Aled Morris via NANOG wrote: > I'm a fan of these solutions that (only) use NAT44 in the CPE as this > is exactly what they're currently doing, and the CPE vendors have > already "solved" the problem of application support (SIP, FTP etc.) > at least as far as the end-user is concerned. It's better to modify NAT to preserve the end to end transparency. See draft-ohta-e2e-nat-00 for details. JORDI PALET MARTINEZ via NANOG wrote: > The cost of sharing IPs in a static way, is that services such as > SonyPlaystation Network will put those addresses in the black list, > so you need to buy more addresses. This hasn’t been the case for > 464XLAT/NAT64, which shares the addresses dynamically. A problem of dynamic sharing is that logging information to be used for such purposes as crime investigation becomes huge. > Furthermore, if some users need less ports than others, you > "infra-utilize" those addresses, Users needing more ports should pay more money and share an IP address with smaller number of users. > which again is not the case for 464XLAT/NAT64. Each user gets > automatically as many ports as he needs at every moment. Unless all the ports are used up. Thus, even with dynamic port assignment, users needing more ports should pay more money and share an IP address with smaller number of users. Masataka Ohta From jordi.palet at consulintel.es Sat Aug 3 09:29:30 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 03 Aug 2019 11:29:30 +0200 Subject: MAP-E In-Reply-To: References: Message-ID: <4C436557-6E87-4D5E-A55C-14E0ADA0F83C@consulintel.es> > The cost of sharing IPs in a static way, is that services such as > SonyPlaystation Network will put those addresses in the black list, > so you need to buy more addresses. This hasn’t been the case for > 464XLAT/NAT64, which shares the addresses dynamically. A problem of dynamic sharing is that logging information to be used for such purposes as crime investigation becomes huge. -> Of course, everything has good and bad things, but with NAT444 you need to do the same, and because if you deploy 464XLAT you have less than 25% (and going down) of your traffic with IPv4, your cost for logging decreases. I'm assuming that you follow for IPv6 RIPE690 recommendations and you do persistent prefixes to customers, otherwise you also need IPv6 logging (but this is not different regardless of what transition mechanism you use). > Furthermore, if some users need less ports than others, you > "infra-utilize" those addresses, Users needing more ports should pay more money and share an IP address with smaller number of users. -> I don't agree. Users don't know if they need more or less ports, and this is something that may happen dynamically, depending on what apps are you using in your home, or if it is Xmas and you have extra family at home. This is not good for users, is not good for ISPs. If ISPs want to provide "different" services they should CLEARLY say it: "Dear customer, you have two choices 4.000 ports, 16.000 ports or all the ports for you with a single IP address". Otherwise you're cheating to customers, which in many countries is illegal, because providing a reduced number of ports IS NOT (technically) Internet connectivity, is a reduced functionality of Internet connectivity, and you must (legally) advertise it and of course, most customers don't understand that! > which again is not the case for 464XLAT/NAT64. Each user gets > automatically as many ports as he needs at every moment. Unless all the ports are used up. -> That's right, but you need to calculate a sufficient number of IPv4 addresses for your pool (which for sure will be lower than in MAP or lw4o6 or DS-Lite), and even if your number of customers go up, because more and more services are available with IPv6, your number of IPv4 will not keep growing. If you define 4.000 ports per customer, some customers may be using only 300 ports (average) and that means that you're infra-utilizing 3,700 ports x number of users with that average. Not good! Thus, even with dynamic port assignment, users needing more ports should pay more money and share an IP address with smaller number of users. -> Never we should have charged users for IP addresses. This is a bad business model. Is not technically a good thing to provide non-persistent addresses. If we keep saying that, we will end up providing a single IPv6 address to every customer and doing NAT again. If an ISP want to do that, fine, but the competitors will be smarter (hopefully!). Masataka Ohta ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From mark.tinka at seacom.mu Sat Aug 3 10:58:01 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 3 Aug 2019 12:58:01 +0200 Subject: The future of transport in the metro area In-Reply-To: References: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> <6d8f5d52-c0b9-ce5e-48bd-7d1f096d4834@seacom.mu> <7ffb97b2-c9b1-8c5c-4cd7-e85886c22b2e@seacom.mu> Message-ID: <2c442e50-730d-6535-3fb3-e768b3a2385c@seacom.mu> On 3/Aug/19 03:14, Brandon Martin wrote: >   > > How are they handling optical power balancing across amplifiers and > such?  Do they just trust the customer to provide light at the power > levels agreed upon?  Bulk attenuate the entire "spectrum" > automatically?  Monitor and drop the whole lot if something is out of > whack and causing saturation or gain balance problems for others? > > Or is this something you're only seeing at metro distances where > separate amplifiers are superfluous? The details about this are very vendor-specific, and each vendor has some way in which they implement this. Spectrum would be a very customized product between the vendor and operator, and also between the operator and customer. So no BCP for this, as of yet, that I know of. >   I've inquired with a few metro operators in my area about something > like this, albeit a few years ago, and I got a pretty hard "no way > we'd ever do that" out of them presumably for the reasons above. We are seeing requests from as low as 600km, up to 1,600km, all the way to 7,000km. Mark. From cvuljanic at gmail.com Sat Aug 3 11:22:54 2019 From: cvuljanic at gmail.com (Craig) Date: Sat, 3 Aug 2019 07:22:54 -0400 Subject: OT: Tech bag In-Reply-To: <8F48D1DD-ABC5-4C77-9223-80521CED36D6@knight-networks.com> References: <8F48D1DD-ABC5-4C77-9223-80521CED36D6@knight-networks.com> Message-ID: I switched up to a backpack from this company: https://missionworkshop.com/collections/backpacks they have modular packs, so I keep various things in the modules, and they can go onto their packs. On Fri, Aug 2, 2019 at 8:41 PM Brian Knight wrote: > About a year ago, I switched from a Swissgear to a High Sierra Endeavor > wheeled backpack and been very happy with it. Most of the time I carry < 15 > lbs of gear when I commute to the office on the train, so I’ll have it on > my back. But when I head to the colo with a heavy load, it’s handy (and a > real relief to my neck and shoulders) to be able to switch to wheeled mode. > It’s held an ASR920 + laptop + hardware + usual load with a bit of room to > spare. > > HTH, > > -Brian > > > On Aug 2, 2019, at 11:14 AM, Dovid Bender wrote: > > > > Hi, > > > > Sorry for the OT email. I travel extensively to DC's and my computer bag > seems to keep collecting more tools which includes your usual console > cables, spare everything, two laptops etc. My Swissgear has been taking a > beating and I was wondering what others who have to lug around 30-35 pounds > use. > > > > TIA. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chriztoffer at netravnen.de Sat Aug 3 13:12:49 2019 From: chriztoffer at netravnen.de (Chriztoffer Hansen) Date: Sat, 3 Aug 2019 15:12:49 +0200 Subject: [nanog] Cisco GLBP/HSRP question -- Has it ever been discussed to publish fully/in-part the specifications Message-ID: Cisco has their FHR protocol specifications protected as proprietary IP. * Gateway Load Balancing Protocol (GLBP) * Hot Standby Router Protocol (HSRP) * https://packetlife.net/media/library/3/First_Hop_Redundancy.pdf Apart from the EIGRP specifications. Which has become publicly available in-part. Q: Anyone know about if the same has ever been discussed with regards to their HSRP and GLBP protocol specifications? -- Best regards, Chriztoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From saku at ytti.fi Sat Aug 3 13:49:53 2019 From: saku at ytti.fi (Saku Ytti) Date: Sat, 3 Aug 2019 16:49:53 +0300 Subject: [nanog] Cisco GLBP/HSRP question -- Has it ever been discussed to publish fully/in-part the specifications In-Reply-To: References: Message-ID: https://tools.ietf.org/html/rfc2281 I don't think any work for GLBP exists in IETF. On Sat, 3 Aug 2019 at 16:16, Chriztoffer Hansen wrote: > > Cisco has their FHR protocol specifications protected as proprietary IP. > > * Gateway Load Balancing Protocol (GLBP) > * Hot Standby Router Protocol (HSRP) > * https://packetlife.net/media/library/3/First_Hop_Redundancy.pdf > > Apart from the EIGRP specifications. Which has become publicly available > in-part. > > Q: Anyone know about if the same has ever been discussed with regards to > their HSRP and GLBP protocol specifications? > > -- > Best regards, > Chriztoffer > -- ++ytti From chriztoffer at netravnen.de Sat Aug 3 14:18:29 2019 From: chriztoffer at netravnen.de (Chriztoffer Hansen) Date: Sat, 3 Aug 2019 16:18:29 +0200 Subject: [nanog] Cisco GLBP/HSRP question -- Has it ever been discussed to publish fully/in-part the specifications In-Reply-To: References: Message-ID: <53b7b43a-316d-0a62-e247-b78beca196d1@netravnen.de> Saku Ytti wrote on 03/08/2019 15:49: > I don't think any work for GLBP exists in IETF. A shot in the dark. Correct. https://www.google.com/#q=%28"GLBP"%7C"Gateway+Load+Balancing"+Protocol%7C"Global+Load+Balancing"+Protocol%29+AND+inurl%3Adatatracker+AND+inurl%3Aietf (My IETF history is short. =I won't know any older history.) ... I doubt any current or previous Cisco folks on the list would want to chirm in about history from inside Cisco on the GLBP topic...(?) -- Best regards, Chriztoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From valdis.kletnieks at vt.edu Sat Aug 3 15:04:33 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Sat, 03 Aug 2019 11:04:33 -0400 Subject: The future of transport in the metro area In-Reply-To: <2c442e50-730d-6535-3fb3-e768b3a2385c@seacom.mu> References: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> <6d8f5d52-c0b9-ce5e-48bd-7d1f096d4834@seacom.mu> <7ffb97b2-c9b1-8c5c-4cd7-e85886c22b2e@seacom.mu> <2c442e50-730d-6535-3fb3-e768b3a2385c@seacom.mu> Message-ID: <11016.1564844673@turing-police> On Sat, 03 Aug 2019 12:58:01 +0200, Mark Tinka said: > On 3/Aug/19 03:14, Brandon Martin wrote: > > � I've inquired with a few metro operators in my area about something > > like this, albeit a few years ago, and I got a pretty hard "no way > > we'd ever do that" out of them presumably for the reasons above. > > We are seeing requests from as low as 600km, up to 1,600km, all the way > to 7,000km. I'm having a hard time seeing any of those distances as being "metro" as opposed to long-haul.. or did they change the definitions again while I wasn't paying attention? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From john at essenz.com Sat Aug 3 15:13:27 2019 From: john at essenz.com (John Von Essen) Date: Sat, 3 Aug 2019 11:13:27 -0400 Subject: AWS latency is Asia-Pacific Message-ID: <3DF92084-7594-469A-85AD-84381B1EE3EC@essenz.com> Is anyone else seeing increased latency both within AWS and transit in the Asia-Pacific region? We normally see 90-100ms between Aus and Sing within AWS, for the past 18 hours or so this has jumped up to 190ms - even for internal VPC-VPC traffic. Transit from Aus to Sing (3rd party endpoints) is also 190ms or so. So far, Amazon has told me everything is fine, but that same latency test from a budget VPS provider in Sydney to Singapore is like 92ms, whereas on AWS its 190ms. I have some tickets in queue, but curious if anyone else has observed anything. -John From mark.tinka at seacom.mu Sat Aug 3 17:38:37 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 3 Aug 2019 19:38:37 +0200 Subject: The future of transport in the metro area In-Reply-To: <11016.1564844673@turing-police> References: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> <6d8f5d52-c0b9-ce5e-48bd-7d1f096d4834@seacom.mu> <7ffb97b2-c9b1-8c5c-4cd7-e85886c22b2e@seacom.mu> <2c442e50-730d-6535-3fb3-e768b3a2385c@seacom.mu> <11016.1564844673@turing-police> Message-ID: <76184b28-130e-55cc-9ed5-d2fa0e856cf4@seacom.mu> On 3/Aug/19 17:04, Valdis Kl ē tnieks wrote: > I'm having a hard time seeing any of those distances as being "metro" as > opposed to long-haul.. or did they change the definitions again while I wasn't > paying attention? I was answering Brandon's query re: spectrum over distance. The OP's question on Metro still stands. 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 ross at tajvar.io Sat Aug 3 19:30:43 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sat, 3 Aug 2019 15:30:43 -0400 Subject: Best ways to ensure redundancy with no terrestrial ISPs Message-ID: Hi all, A friend of mine is trying to set up a network in a location where there is no fiber (or copper) for many miles. As bandwidth requirements are low (<1M for the foreseeable future) but uptime is important, he was looking at using multiple cell modems from separate carriers as redundant uplinks. I am concerned that different cell carriers might be using the same transport providers to a given tower, so that wouldn't be truly redundant. Another option would be using a satellite provider as a backup for cellular. (The high latency that comes with satellite is not an issue.) A fixed-radio solution would likely be too expensive upfront as it would require building towers. Am I missing any other options or considerations? Thanks, Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at ics-il.net Sat Aug 3 19:33:07 2019 From: nanog at ics-il.net (Mike Hammett) Date: Sat, 3 Aug 2019 14:33:07 -0500 (CDT) Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: References: Message-ID: <741282057.17942.1564860783684.JavaMail.mhammett@ThunderFuck> Any existing WISPs? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Ross Tajvar" To: "North American Network Operators' Group" Sent: Saturday, August 3, 2019 2:30:43 PM Subject: Best ways to ensure redundancy with no terrestrial ISPs Hi all, A friend of mine is trying to set up a network in a location where there is no fiber (or copper) for many miles. As bandwidth requirements are low (<1M for the foreseeable future) but uptime is important, he was looking at using multiple cell modems from separate carriers as redundant uplinks. I am concerned that different cell carriers might be using the same transport providers to a given tower, so that wouldn't be truly redundant. Another option would be using a satellite provider as a backup for cellular. (The high latency that comes with satellite is not an issue.) A fixed-radio solution would likely be too expensive upfront as it would require building towers. Am I missing any other options or considerations? Thanks, Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Sat Aug 3 19:59:27 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sat, 3 Aug 2019 15:59:27 -0400 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: <741282057.17942.1564860783684.JavaMail.mhammett@ThunderFuck> References: <741282057.17942.1564860783684.JavaMail.mhammett@ThunderFuck> Message-ID: Not that I know of, especially given the location. I'll look into it though. On Sat, Aug 3, 2019, 3:42 PM Mike Hammett wrote: > Any existing WISPs? > > > > ----- > Mike Hammett > Intelligent Computing Solutions > > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > ------------------------------ > *From: *"Ross Tajvar" > *To: *"North American Network Operators' Group" > *Sent: *Saturday, August 3, 2019 2:30:43 PM > *Subject: *Best ways to ensure redundancy with no terrestrial ISPs > > Hi all, > > A friend of mine is trying to set up a network in a location where there > is no fiber (or copper) for many miles. As bandwidth requirements are low > (<1M for the foreseeable future) but uptime is important, he was looking at > using multiple cell modems from separate carriers as redundant uplinks. I > am concerned that different cell carriers might be using the same transport > providers to a given tower, so that wouldn't be truly redundant. Another > option would be using a satellite provider as a backup for cellular. (The > high latency that comes with satellite is not an issue.) > > A fixed-radio solution would likely be too expensive upfront as it would > require building towers. > > Am I missing any other options or considerations? > > Thanks, > Ross > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marine64 at gmail.com Sat Aug 3 20:29:55 2019 From: marine64 at gmail.com (Brian Henson) Date: Sat, 3 Aug 2019 16:29:55 -0400 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: References: Message-ID: If we had a location (or at least a part of the world) we might be able to recommend a little better. On Sat, Aug 3, 2019 at 3:32 PM Ross Tajvar wrote: > Hi all, > > A friend of mine is trying to set up a network in a location where there > is no fiber (or copper) for many miles. As bandwidth requirements are low > (<1M for the foreseeable future) but uptime is important, he was looking at > using multiple cell modems from separate carriers as redundant uplinks. I > am concerned that different cell carriers might be using the same transport > providers to a given tower, so that wouldn't be truly redundant. Another > option would be using a satellite provider as a backup for cellular. (The > high latency that comes with satellite is not an issue.) > > A fixed-radio solution would likely be too expensive upfront as it would > require building towers. > > Am I missing any other options or considerations? > > Thanks, > Ross > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Sat Aug 3 21:09:27 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sat, 3 Aug 2019 17:09:27 -0400 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: References: Message-ID: On Sat, Aug 3, 2019 at 4:30 PM Brian Henson wrote: > If we had a location (or at least a part of the world) we might be able to > recommend a little better. > This is in northern Africa. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.tinka at seacom.mu Sat Aug 3 21:21:42 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sat, 3 Aug 2019 23:21:42 +0200 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: References: Message-ID: <5f77cc1e-ab20-c2b1-f60f-15bacd3b922b@seacom.mu> On 3/Aug/19 23:09, Ross Tajvar wrote: > On Sat, Aug 3, 2019 at 4:30 PM Brian Henson > wrote: > > If we had a location (or at least a part of the world) we might be > able to recommend a little better.  > > > This is in northern Africa. Hmmh - normally, when someone says North America, it's one of 2 countries. Not much fuss there... North Africa (by some kind of definition) is 8 or 10 countries, depending on what you feel North Africa means. In short, you'll have to be more specific than that... Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Sat Aug 3 22:34:25 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sat, 3 Aug 2019 15:34:25 -0700 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: <5f77cc1e-ab20-c2b1-f60f-15bacd3b922b@seacom.mu> References: <5f77cc1e-ab20-c2b1-f60f-15bacd3b922b@seacom.mu> Message-ID: Feel free to open live.infrapedia.com on mobile. Click on share location icon. And it will show 3D view of any fiber near by. We are thinking about adding wireless networks too and maybe overlaying national cell phone coverage maps On Sat, Aug 3, 2019 at 14:21 Mark Tinka wrote: > > > On 3/Aug/19 23:09, Ross Tajvar wrote: > > On Sat, Aug 3, 2019 at 4:30 PM Brian Henson wrote: > >> If we had a location (or at least a part of the world) we might be able >> to recommend a little better. >> > > This is in northern Africa. > > > Hmmh - normally, when someone says North America, it's one of 2 countries. > Not much fuss there... > > North Africa (by some kind of definition) is 8 or 10 countries, depending > on what you feel North Africa means. > > In short, you'll have to be more specific than that... > > > Mark. > > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Sun Aug 4 00:16:30 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sat, 3 Aug 2019 20:16:30 -0400 Subject: The future of transport in the metro area In-Reply-To: <2c442e50-730d-6535-3fb3-e768b3a2385c@seacom.mu> References: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> <6d8f5d52-c0b9-ce5e-48bd-7d1f096d4834@seacom.mu> <7ffb97b2-c9b1-8c5c-4cd7-e85886c22b2e@seacom.mu> <2c442e50-730d-6535-3fb3-e768b3a2385c@seacom.mu> Message-ID: On 8/3/19 6:58 AM, Mark Tinka wrote: > We are seeing requests from as low as 600km, up to 1,600km, all the way > to 7,000km. Those are definitely longer distances than I was inquiring about. I was asking for distances in the range of more like 100km. Those distances are firmly into the amplified territory and getting into territory were you're likely to need full RRR stops in at least a couple places. Maybe not with coherent optics especially on NZDS fiber...maybe. -- Brandon Martin From eric.kuhnke at gmail.com Sun Aug 4 01:36:40 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Sat, 3 Aug 2019 18:36:40 -0700 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: References: Message-ID: In a remote area in northern africa if there are no terrestrial ISPs, and there is no budget to build towers for PTP microwave, I don't know if there are any reasonable options. If sufficient funds did exist, my recommendation, if they really want true diversity between two totally different services, would be a combination of a MEO o3b earth station and a traditional geostationary type earth station (Ku band) with appropriate RF chain and SCPC modem. It is also possible to achieve full diversity through two totally separate geostationary earth stations, using different satellite transponders and different teleports on the other end. But that's not going to be cheap, either in a one time equipment cost or in monthly recurring cost, for o3b services and transponder kHz lease + teleport services on the other end somewhere in continental Europe. On Sat, Aug 3, 2019 at 2:10 PM Ross Tajvar wrote: > On Sat, Aug 3, 2019 at 4:30 PM Brian Henson wrote: > >> If we had a location (or at least a part of the world) we might be able >> to recommend a little better. >> > > This is in northern Africa. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sun Aug 4 03:42:05 2019 From: jcurran at arin.net (John Curran) Date: Sun, 4 Aug 2019 03:42:05 +0000 Subject: Spam due to new ARIN allocation In-Reply-To: <1e519874-5cac-4c16-925a-96995f1c33e7@www.fastmail.com> References: <1e519874-5cac-4c16-925a-96995f1c33e7@www.fastmail.com> Message-ID: Tim - When you have moment, could you forward both of those Whois spam messages to compliance at arin.net ? Thanks! /John John Curran President and CEO American Registry for Internet Numbers] On 2 Aug 2019, at 7:32 PM, Tim Burke > wrote: We recently received a new ASN from ARIN - you know what that means... the sales vultures come out to play! So far, it has resulted in spam from Cogent (which is, of course, to be expected), and now another company called "CapCon Networks" - http://www.capconnetworks.com. As far as I am aware, this practice is against ARIN's Terms of Use. Is it worth reporting to ARIN, or perhaps it's worth creating a List of People To Never Do Business With™, complete with these jokers, and other vultures that engage in similar tactics? Regards, Tim Burke tim at burke.us -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sun Aug 4 04:15:11 2019 From: jcurran at arin.net (John Curran) Date: Sun, 4 Aug 2019 04:15:11 +0000 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: On 31 Jul 2019, at 5:31 PM, Scott Christopher > wrote: ... 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. :) Scott - ARIN revokes resources because of other administrative matters (e.g. not paying one’s ARIN fees), and while there is obviously quite a bit of process and notice to avoid this if all possible, we do indeed revoke and networks go down as a result. From list at satchell.net Sun Aug 4 07:12:48 2019 From: list at satchell.net (Stephen Satchell) Date: Sun, 4 Aug 2019 00:12:48 -0700 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: <89f3dc71-36a0-7e92-5e20-b96ff04bccec@satchell.net> On 8/3/19 9:15 PM, John Curran wrote: > As I have noted previously, I have zero doubt in the enforceability > of the ARIN registration services agreements in this regard – so > please carefully consider proposed policy both from the overall > community benefit being sought, and from the implications faced as a > number resource holder having to comply oneself with the new > obligations. Actually, I would re-write the last part of the last sentence as "...and from the implications faced as a number resource holder having to comply oneself with the long-standing and well-known obligations of all network operators." I'm a small network operator that has been around and following "the rules" for many years. I do understand why you are constrained by the legal authority you have. In some respects, I (and others) pine for the old NSFNET days, when negligence -- particularly willful negligence -- was rewarded with disconnection. "The rules" have been around for years, and are codified in the RFCs that are widely published and available to all at zero cost. (That wasn't always true, as it wasn't until the DDN Protocol Handbook volumes were published in 1985 that the RFCs were available to everyone. I seem to recall there was an FTP site that provided the RFC documents before that, but my memory is hazy on that.) I had access to all the RFCs at the University of Illinois Center for Advanced Computation, as I was working at the place as a worker on ARPAnet. During my career as a web server admin, mail admin, and network admin, I followed "the rules" strictly. As the main abuse contact during my time at a web hosting company, my postmaster@ and abuse@ contact addresses were according to Hoyle, and published with the company ASN, netblock, and domain registration records. It took a little convincing for the owner of the shop to buy in, and to back up my responses to abuse reports. I would have expected any ARIN contracts to include by reference the RFCs that constituted "the rules". I have never seen the contracts, so I don't know how they are formulated. That said, I would have expected legacy space to fall under "the rules", particularly with respect to role electronic mail addresses. I don't have a dog in this fight. Currently, I don't "own" any IPv4 address space, nor am I running BGP. From mark.tinka at seacom.mu Sun Aug 4 07:27:38 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Sun, 4 Aug 2019 09:27:38 +0200 Subject: The future of transport in the metro area In-Reply-To: References: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> <6d8f5d52-c0b9-ce5e-48bd-7d1f096d4834@seacom.mu> <7ffb97b2-c9b1-8c5c-4cd7-e85886c22b2e@seacom.mu> <2c442e50-730d-6535-3fb3-e768b3a2385c@seacom.mu> Message-ID: On 4/Aug/19 02:16, Brandon Martin wrote: >   > > Those are definitely longer distances than I was inquiring about.  I > was asking for distances in the range of more like 100km. For shorter runs, I think it's cheaper to find dark fibre and do something yourself. Mark. From ximaera at gmail.com Sun Aug 4 07:33:08 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Sun, 4 Aug 2019 10:33:08 +0300 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <20190731222515.GA13716@gweep.net> References: <6582438c-3069-48c1-b3f8-30746e758a5d@www.fastmail.com> <40760311-9686-a0e7-5fb4-d69caad8b1ea@netravnen.de> <20190731222515.GA13716@gweep.net> Message-ID: On Thu, Aug 1, 2019, 1:25 AM Joe Provo wrote: > On Tue, Jul 30, 2019 at 04:02:58PM +0300, T??ma Gavrichenkov wrote: > 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 Whoops, you're right. My bad, I haven't been following ARIN processes lately. -- Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From edepa at ieee.org Sun Aug 4 08:07:48 2019 From: edepa at ieee.org (Etienne-Victor Depasquale) Date: Sun, 4 Aug 2019 10:07:48 +0200 Subject: The future of transport in the metro area In-Reply-To: References: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> <6d8f5d52-c0b9-ce5e-48bd-7d1f096d4834@seacom.mu> <7ffb97b2-c9b1-8c5c-4cd7-e85886c22b2e@seacom.mu> <2c442e50-730d-6535-3fb3-e768b3a2385c@seacom.mu> Message-ID: A friend of mine whom I rely upon took it upon himself to put my question to a reliable contact of his. In the hope of adding some value to this thread, I'm reproducing this exchange with their names removed, in descending chronological order (latest first, earliest last). Academic in the US:It’s almost all packet over OTN. SONET has been on its way out (at least in what I’ve seen) since the mid 2000’s. The last SONET I touched was like 2008, and that was to tear it out and replace it with Ethernet over OTN. My contact: What you’re seeing pretty much matches what I’m seeing (from the outside). What I think Etienne is wondering is “how is that magic sauce delivered inside the SP network” - are they still using SONET/SDH, did they move to OTN, or is it pure packet-switched technology. The few networks I saw from the inside recently were all using packet-based technology (mostly MPLS) over lambdas. Would you have more data points? Academic in the US: Almost everything I have seen in the US and parts of western Europe are either spectrum sharing (rare, but definitely a thing), wavelength as a managed service, or - more commonly - "managed ethernet" where the product is basically a L2 managed path with a hard bandwidth cap. This is far more common, especially in metro areas as it's basically part of pretty much all of the MetroE platforms. In the US, MPLS is still pretty heavy but MPLS-SR is likely going to take over that space. Carriers are selling waves at a premium, they'd much rather oversell a frame service. On Sun, Aug 4, 2019 at 9:28 AM Mark Tinka wrote: > > > On 4/Aug/19 02:16, Brandon Martin wrote: > > > > > > > Those are definitely longer distances than I was inquiring about. I > > was asking for distances in the range of more like 100km. > > For shorter runs, I think it's cheaper to find dark fibre and do > something yourself. > > Mark. > -- 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 sc at ottie.org Sun Aug 4 08:16:38 2019 From: sc at ottie.org (Scott Christopher) Date: Sun, 04 Aug 2019 11:16:38 +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> <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: <2d008a95-b5c9-4d9c-aed0-c040f5bca164@www.fastmail.com> John Curran wrote: ... > As I have noted previously, I have zero doubt in the enforceability of the ARIN registration services agreements in this regard – so please carefully consider proposed policy both from the overall community benefit being sought, and from the implications faced as a number resource holder having to comply oneself with the new obligations. I completely agree that ARIN can revoke an organization's resources. Nobody has ever doubted that. What I have been saying is that if ARIN revoked Amazon's resources because of a trivial matter of bounced Abuse PoC, even if the small "community" of network operators and other interested parties passed a rule supporting this, the backlash would be *enormous* and lead to media attention, litigation, police, investigation by U.S. Congress, etc. The interests of the public affected by a global Amazon/AWS outage would greatly outweigh the rights of this small "community" which would ultimately be stripped away, I'd think. This is moot, of course, because ARIN would give ample notices and time to Amazon and they would dutifully comply. But the original poster to which I replied invited us to imagine such a situation. S.C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Sun Aug 4 08:40:05 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sun, 4 Aug 2019 04:40:05 -0400 Subject: The future of transport in the metro area In-Reply-To: References: <195498f6-6eee-c0de-2ab5-1f788c2c41b6@seacom.mu> <642fc1e3-8054-55d1-1103-d9883fa5f35d@seacom.mu> <6d8f5d52-c0b9-ce5e-48bd-7d1f096d4834@seacom.mu> <7ffb97b2-c9b1-8c5c-4cd7-e85886c22b2e@seacom.mu> <2c442e50-730d-6535-3fb3-e768b3a2385c@seacom.mu> Message-ID: On 8/4/19 3:27 AM, Mark Tinka wrote: > For shorter runs, I think it's cheaper to find dark fibre and do > something yourself. This was a bit of an unusual situation. One end it rather rural. The only fiber within miles was one semi-independent operator, the area RBOC, and Comcast. The semi-independent operator is on an old cable with very limited fiber count and apparently has basically every strand lit with DWDM at this point. They had no dark fiber to give. -- Brandon Martin From jcurran at arin.net Sun Aug 4 11:57:23 2019 From: jcurran at arin.net (John Curran) Date: Sun, 4 Aug 2019 11:57:23 +0000 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <2d008a95-b5c9-4d9c-aed0-c040f5bca164@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> <58BBE0F0-DD60-4767-AECE-71A57C0CBA5E@tislabs.com> <2d008a95-b5c9-4d9c-aed0-c040f5bca164@www.fastmail.com> Message-ID: <037053F1-5936-42CB-89A7-5D9AE07D057B@arin.net> On 4 Aug 2019, at 4:16 AM, Scott Christopher > wrote: ... What I have been saying is that if ARIN revoked Amazon's resources because of a trivial matter of bounced Abuse PoC, even if the small "community" of network operators and other interested parties passed a rule supporting this, the backlash would be *enormous* and lead to media attention, litigation, police, investigation by U.S. Congress, etc. Scott, That may be the case – for example anyone can initiate litigation for any perceived slight, whereas successful litigation is generally requires actual contractual breach or other cause of action. The interests of the public affected by a global Amazon/AWS outage would greatly outweigh the rights of this small "community" which would ultimately be stripped away, I'd think. It is possible, but far more likely an outcome in circumstances where ARIN contributed in some manner; e.g. an operational outage which was an element in the overall global event. (hence our particular care in certain areas, e.g. ensuring folks know the conditions for use of our RPKI repository, and their duty to handle NOTFOUND and fall back appropriately per best practices…) Thanks, /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From rubensk at gmail.com Sun Aug 4 12:15:33 2019 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 4 Aug 2019 09:15:33 -0300 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <2d008a95-b5c9-4d9c-aed0-c040f5bca164@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> <58BBE0F0-DD60-4767-AECE-71A57C0CBA5E@tislabs.com> <2d008a95-b5c9-4d9c-aed0-c040f5bca164@www.fastmail.com> Message-ID: On Sun, Aug 4, 2019 at 5:17 AM Scott Christopher wrote: > John Curran wrote: > > ... > > As I have noted previously, I have zero doubt in the enforceability of the > ARIN registration services agreements in this regard – so please carefully > consider proposed policy both from the overall community benefit being > sought, and from the implications faced as a number resource holder having > to comply oneself with the new obligations. > > > I completely agree that ARIN can revoke an organization's resources. > Nobody has ever doubted that. > > What I have been saying is that if ARIN revoked Amazon's resources because > of a trivial matter of bounced Abuse PoC, even if the small "community" of > network operators and other interested parties passed a rule supporting > this, the backlash would be *enormous* and lead to media attention, > litigation, police, investigation by U.S. Congress, etc. > > The interests of the public affected by a global Amazon/AWS outage would > greatly outweigh the rights of this small "community" which would > ultimately be stripped away, I'd think. > > This is moot, of course, because ARIN would give ample notices and time to > Amazon and they would dutifully comply. But the original poster to which I > replied invited us to imagine such a situation. > > I don't think that "companies with tons of lawyers" should be a factor in making resource allocation policies. But considering either small or big networks, an escalation path would reduce friction and increase overall compliance... for instance, failure to have functioning abuse PoC could lead first to being inegible to receive new resources. Rubens -------------- next part -------------- An HTML attachment was scrubbed... URL: From tb at tburke.us Sun Aug 4 14:29:06 2019 From: tb at tburke.us (Tim Burke) Date: Sun, 04 Aug 2019 09:29:06 -0500 Subject: Spam due to new ARIN allocation In-Reply-To: References: <1e519874-5cac-4c16-925a-96995f1c33e7@www.fastmail.com> Message-ID: Done, Sir. Thanks. Tim Burke tim at burke.us On Sat, Aug 3, 2019, at 10:42 PM, John Curran wrote: > Tim - > > When you have moment, could you forward both of those Whois spam messages to compliance at arin.net ? > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers] > > >> On 2 Aug 2019, at 7:32 PM, Tim Burke wrote: >> >> We recently received a new ASN from ARIN - you know what that means... the sales vultures come out to play! >> >> So far, it has resulted in spam from Cogent (which is, of course, to be expected), and now another company called "CapCon Networks" - http://www.capconnetworks.com. As far as I am aware, this practice is against ARIN's Terms of Use. Is it worth reporting to ARIN, or perhaps it's worth creating a List of People To Never Do Business With™, complete with these jokers, and other vultures that engage in similar tactics? >> >> Regards, >> Tim Burke >> tim at burke.us -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredbaker.ietf at gmail.com Sun Aug 4 15:50:23 2019 From: fredbaker.ietf at gmail.com (Fred Baker) Date: Sun, 4 Aug 2019 08:50:23 -0700 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: References: Message-ID: Between overlaid ads and the thing trying to force an account, i’d Describe it as a waste of time. Now, a page that delivered the data advertised... Sent using a machine that autocorrects in interesting ways... > On Aug 3, 2019, at 3:36 PM, Mehmet Akcin wrote: > >  > Feel free to open live.infrapedia.com on mobile. Click on share location icon. And it will show 3D view of any fiber near by. > > We are thinking about adding wireless networks too and maybe overlaying national cell phone coverage maps > >> On Sat, Aug 3, 2019 at 14:21 Mark Tinka wrote: >> >> >>> On 3/Aug/19 23:09, Ross Tajvar wrote: >>> On Sat, Aug 3, 2019 at 4:30 PM Brian Henson wrote: >>>> If we had a location (or at least a part of the world) we might be able to recommend a little better. >>> >>> >>> This is in northern Africa. >> >> Hmmh - normally, when someone says North America, it's one of 2 countries. Not much fuss there... >> >> North Africa (by some kind of definition) is 8 or 10 countries, depending on what you feel North Africa means. >> >> In short, you'll have to be more specific than that... >> >> >> Mark. >> > -- > Mehmet > +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Sun Aug 4 16:56:11 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 4 Aug 2019 09:56:11 -0700 Subject: Puerto Rico Internet Exchange In-Reply-To: References: Message-ID: thank you for reaching out offlist. We've received our core switching hardware (thank you Arista for donating these) and identified 5-7 potential different sites which we can be colocated, however, we will start with two that are diversely connected with each other. somewhere others can go deploy 1-2 rack deployments, easily. what do we need now? we will go to Puerto Rico and go rack hardware/servers/cable etc if you have any way to help (you might be living there, etc.. feel free to reach out) an IX without networks to peer is well not an IX. so if you are able to make deployments using 1-2rack unit servers, or even virtual servers (DNS, etc..) feel free to contact me offlist. We would like to have in general, root-servers, TLDs, CDN caches, etc. these all peer with ix. regarding costs of ix - we will be following a model where "members share all costs", at the beginning our ultimate goal is to keep these costs to an absolute minimum. Any other recommendations, please feel free to reach offlist. next, I hope to share some peering utilization numbers. On Sat, Jul 6, 2019 at 2:18 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 mehmet at akcin.net Sun Aug 4 18:20:11 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 4 Aug 2019 11:20:11 -0700 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: References: Message-ID: thank you for the feedback. It's quite challenging to keep a high scale, open, a free platform without having ads, they are designed to be easily closed and should you have problem with it, I am happy to help understand and hear recommendations. I understand and share your frustration about forcing account registration. We had no other way but to implement this as constantly we had sources trying to download our data by examining our code. By having access controls we were able to stop that. My team had recommended user data controls after reviewing Geoserver, mapbox requirements, if you know any other way please feel free to recommend. every feedback is welcome, we are trying to build a tool which is free, open, and hoping to develop and make it even better with recommendations like this. On Sun, Aug 4, 2019 at 8:50 AM Fred Baker wrote: > Between overlaid ads and the thing trying to force an account, i’d > Describe it as a waste of time. Now, a page that delivered the data > advertised... > > Sent using a machine that autocorrects in interesting ways... > > On Aug 3, 2019, at 3:36 PM, Mehmet Akcin wrote: > >  > Feel free to open live.infrapedia.com on mobile. Click on share location > icon. And it will show 3D view of any fiber near by. > > We are thinking about adding wireless networks too and maybe overlaying > national cell phone coverage maps > > On Sat, Aug 3, 2019 at 14:21 Mark Tinka wrote: > >> >> >> On 3/Aug/19 23:09, Ross Tajvar wrote: >> >> On Sat, Aug 3, 2019 at 4:30 PM Brian Henson wrote: >> >>> If we had a location (or at least a part of the world) we might be able >>> to recommend a little better. >>> >> >> This is in northern Africa. >> >> >> Hmmh - normally, when someone says North America, it's one of 2 >> countries. Not much fuss there... >> >> North Africa (by some kind of definition) is 8 or 10 countries, depending >> on what you feel North Africa means. >> >> In short, you'll have to be more specific than that... >> >> >> Mark. >> >> -- > Mehmet > +1-424-298-1903 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramirezcyrus at yahoo.com Sun Aug 4 19:40:49 2019 From: ramirezcyrus at yahoo.com (cyrus ramirez) Date: Sun, 4 Aug 2019 19:40:49 +0000 (UTC) Subject: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis In-Reply-To: <53b7b43a-316d-0a62-e247-b78beca196d1@netravnen.de> References: <53b7b43a-316d-0a62-e247-b78beca196d1@netravnen.de> Message-ID: <1035588386.903366.1564947649242@mail.yahoo.com> If you're looking for vendor neutral FHRP, VRRP has RFC documentation. GLBP and HSRP are Cisco proprietary protocols and are protected information other than the study material and how too out there. Cyrus Sent from Yahoo Mail on Android On Sat, Aug 3, 2019 at 10:19 AM, Chriztoffer Hansen wrote: Saku Ytti wrote on 03/08/2019 15:49: > I don't think any work for GLBP exists in IETF. A shot in the dark. Correct. https://www.google.com/#q=%28"GLBP"%7C"Gateway+Load+Balancing"+Protocol%7C"Global+Load+Balancing"+Protocol%29+AND+inurl%3Adatatracker+AND+inurl%3Aietf (My IETF history is short. =I won't know any older history.) ... I doubt any current or previous Cisco folks on the list would want to chirm in about history from inside Cisco on the GLBP topic...(?) -- Best regards, Chriztoffer -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Sun Aug 4 20:05:51 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sun, 04 Aug 2019 14:05:51 -0600 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: Message-ID: On Sunday, 4 August, 2019 12:20, Mehmet Akcin wrote: >I understand and share your frustration about forcing account >registration. We had no other way but to implement this as constantly >we had sources trying to download our data by examining our code. By >having access controls we were able to stop that. My team had >recommended user data controls after reviewing Geoserver, mapbox >requirements, if you know any other way please feel free to >recommend. You permit anyone to view the code running on your web server? Do you permit them to modify it too? Nevertheless, just deny code viewing permission on your web server and only serve output of executing that code. Quite simple. And no one can steal your code (unless you let them into the room containing the web server). -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From mehmet at akcin.net Sun Aug 4 20:12:13 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 4 Aug 2019 13:12:13 -0700 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: References: Message-ID: Keith, thank you for your response, I think this is slightly becoming offtopic, I will take this offlist with you but in short, that's not how GeoServer works (or mainly GIS when displaying things publicly) for something to be displayed to you, it needs to make it available, and if it's available it can be downloaded with codes/programs that allow you to, we are preventing this by forcing users to log in that way someone can't simply launch a script and get all of the data available in our platform (or if they do, we would notice, know who and stop it via rate-limits). I am neither a security nor GIS expert, I am relying on what I was told/advised. On Sun, Aug 4, 2019 at 1:06 PM Keith Medcalf wrote: > > On Sunday, 4 August, 2019 12:20, Mehmet Akcin wrote: > > >I understand and share your frustration about forcing account > >registration. We had no other way but to implement this as constantly > >we had sources trying to download our data by examining our code. By > >having access controls we were able to stop that. My team had > >recommended user data controls after reviewing Geoserver, mapbox > >requirements, if you know any other way please feel free to > >recommend. > > You permit anyone to view the code running on your web server? Do you > permit them to modify it too? > Nevertheless, just deny code viewing permission on your web server and > only serve output of executing that code. > Quite simple. And no one can steal your code (unless you let them into > the room containing the web server). > > -- > 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 mohta at necom830.hpcl.titech.ac.jp Sun Aug 4 21:42:30 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 5 Aug 2019 06:42:30 +0900 Subject: MAP-E In-Reply-To: <4C436557-6E87-4D5E-A55C-14E0ADA0F83C@consulintel.es> References: <4C436557-6E87-4D5E-A55C-14E0ADA0F83C@consulintel.es> Message-ID: <3da10d9c-2dbc-92c0-92aa-15082b99cb47@necom830.hpcl.titech.ac.jp> JORDI PALET MARTINEZ via NANOG wrote: > A problem of dynamic sharing is that logging information to be used > for such purposes as crime investigation becomes huge. > -> Of course, everything has good and bad things, but with NAT444 you > need to do the same, With static port range assignment, we don't have to. > I'm assuming that you follow for IPv6 RIPE690 > recommendations and you do persistent prefixes to customers, I'm not interested in poor IPv6. > Users needing more ports should pay more money and share an IP > address with smaller number of users. > > -> I don't agree. Users don't know if they need more or less ports, > and this is something that may happen dynamically, depending on what > apps are you using in your home, or if it is Xmas and you have extra > family at home. Only users know what applications they are using. > If > ISPs want to provide "different" services they should CLEARLY say it: > "Dear customer, you have two choices 4.000 ports, 16.000 ports or all > the ports for you with a single IP address". That's what I have been saying. > Otherwise you're > cheating to customers, which in many countries is illegal, because > providing a reduced number of ports IS NOT (technically) Internet > connectivity, is a reduced functionality of Internet connectivity, As Baldur Norddahl wrote: > All MAP-E does is reserving a port range for each customer. So > customer A might be assigned port range 2000-2999, customer B gets > 3000-3999 etc. we are talking about providing users a reduced number of ports from 64K to, say, 2K. As such, I'm afraid you have a very strange idea on Internet connectivity, which is not shared by rest of us. > and you must (legally) advertise it and of course, most customers > don't understand that! Most customers should choose least expensive option without understanding anything, of course. > If you define 4.000 ports per > customer, some customers may be using only 300 ports (average) and > that means that you're infra-utilizing 3,700 ports x number of users > with that average. Not good! Are you saying allocating a customer /48 IPv6 address is not good because there is only 5 /64 links (average) used, which infra-utilizing 64K /64? > -> Never we should have charged users for IP addresses. This is a bad > business model. Feel free to ignore reality of ISP business. Masataka Ohta From baldur.norddahl at gmail.com Sun Aug 4 22:24:38 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Mon, 5 Aug 2019 00:24:38 +0200 Subject: MAP-E In-Reply-To: <4C436557-6E87-4D5E-A55C-14E0ADA0F83C@consulintel.es> References: <4C436557-6E87-4D5E-A55C-14E0ADA0F83C@consulintel.es> Message-ID: On Sat, Aug 3, 2019 at 11:30 AM JORDI PALET MARTINEZ via NANOG < nanog at nanog.org> wrote: > > > which again is not the case for 464XLAT/NAT64. Each user gets > > automatically as many ports as he needs at every moment. > > Unless all the ports are used up. > > -> That's right, but you need to calculate a sufficient number of IPv4 > addresses for your pool > I view it as an operative benefit of MAP that it is very stable in regards what happens if the ports are used up. This will never affect other users, as it could with old fashioned CGN. And in fact, there is almost nothing that could affect MAP but plenty of things that could go wrong with your CGN. In the case a user has a problem with too few available ports he will contact our support. They will either advise him on what he can do to use less ports (example, tell the user to do less bittorrent). Or they will tell the user about the option of using IPv6 for his purpose or that he could pay for a dedicated non shared IPv4 address. But they would never need to escalate to have anything done to the non-existent CGN. Some might not like it, but this is very sound from a business perspective. Even the case of a DDoS attack. For my scheme with 16 users sharing an IPv4, the attack could affect all 16 users. For CGN it is usually many more. Or the case of Playstation network. Yes they WILL blacklist your CGN just the same as they can blacklist a shared MAP ip address. Except it affects more users. There is some advantage in having less dense usage of the address space. As a site site probably has less than 1 out of 16 chance of blacklisting someone, our support staff can solve a problem for a customer by simply moving him to a different shared IPv4 - they could not do that for a CGN solution, or if they could, the alternative would also be blacklisted. Regards, Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From chriztoffer at netravnen.de Mon Aug 5 00:29:08 2019 From: chriztoffer at netravnen.de (Chriztoffer Hansen) Date: Mon, 5 Aug 2019 02:29:08 +0200 Subject: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis In-Reply-To: <1035588386.903366.1564947649242@mail.yahoo.com> References: <53b7b43a-316d-0a62-e247-b78beca196d1@netravnen.de> <1035588386.903366.1564947649242@mail.yahoo.com> Message-ID: <16ed85bb-b8f9-419c-9a88-2eb20a64e717@netravnen.de> cyrus, cyrus ramirez wrote on 04/08/2019 21:40: > If you're looking for vendor neutral FHRP, VRRP has RFC > documentation. GLBP and HSRP are Cisco proprietary protocols > and are protected information other than the study material > and how too out there. The thing about the study material I know already. (have been through both ccna- and ccnp-level route/switch/design training material in recent 1-4 years) The question was simply about if GLBP/HSRP had ever been up in discussions in the IETF concerning publishing the protocol specifications as a standard. (As pointed out. I totally forgot about the RFC concerning HSRP.) Haven't gotten a response on the GLBP part. Which I am more than doubtful, myself, will ever come to fruition as a standard in an IETF WG. -- [ have you enabled IPv6 on something today...? ] [ Chriztoffer Hansen +1 914 3133553 ] [ 0x18dd23c550293098de07052a9dcf2ca008ebd2e8 ] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From mohta at necom830.hpcl.titech.ac.jp Mon Aug 5 01:07:28 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 5 Aug 2019 10:07:28 +0900 Subject: MAP-E In-Reply-To: References: <4C436557-6E87-4D5E-A55C-14E0ADA0F83C@consulintel.es> Message-ID: Baldur Norddahl wrote: > Or the case of Playstation network. Yes they WILL blacklist your CGN > just the same as they can blacklist a shared MAP ip address. Except it > affects more users. If IP address sharing by blocks of ports becomes common and there is typical block size (say, 1024), blacklisting will be done block-wise. Masataka Ohta From janets at nairial.net Mon Aug 5 01:29:05 2019 From: janets at nairial.net (Janet Sullivan) Date: Mon, 5 Aug 2019 01:29:05 +0000 Subject: Xfinity with IPv6 clue? Message-ID: I hate resorting to NANOG, but I've spent over 5 hours on the phone with Xfinity the past two days, and I can't seem to get someone who understands my problem. I do not have working IPv6 - I do not get an address or PD. I have working IPv4. Xfinity wanted to blame this on my modem, so I went and picked up a Xfinity modem. From the 10.0.0.1 web site on the xfinity modem, I can ping IPv4 addresses fine. I can not ping IPv6 addresses from the modem itself, thus taking my equipment out of the picture. This is a new activation. Xfinity keeps asking questions like "well, can you surf the internet", which shows that they seem to totally lack understanding. I've talked to at least 7 people, and have reached my breaking point. I know, I know, its residential and I should have low expectations. I'm sorry for the noise, but I can't seem to find anyone with clue. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Philip.Loenneker at tasmanet.com.au Mon Aug 5 01:43:00 2019 From: Philip.Loenneker at tasmanet.com.au (Philip Loenneker) Date: Mon, 5 Aug 2019 01:43:00 +0000 Subject: MAP-E In-Reply-To: References: <4C436557-6E87-4D5E-A55C-14E0ADA0F83C@consulintel.es> Message-ID: Moving away from the discussion around what technology people may choose to go with, and instead what CPEs may be suitable... I know this is 464XLAT rather than MAP-E that was originally requested, but recent versions of D-Link firmware, eg for the DVA-2800, include the CLAT functionality. My testing in November last year showed that it only partially worked, with the traceroutes to 64:ff9b::1.1.1.1 working, but it would not automatically translate a traceroute to 1.1.1.1 to the IPv6 version. There have been a few new revisions since then and it is on my to-do list to re-test things, but I haven't had the time. It is also worth noting that, in the original firmware revision I tested, I had to manually enter the URL for the CLAT configuration screen. It simply wasn't on the menu. On another version, it had a link to DS-Lite configuration, and from there you get a link to the CLAT options. It is possible that other devices and/or vendors also have this option, or options for similar technologies such as MAP-E, but they just don't have a link to it in the interface. -----Original Message----- From: NANOG On Behalf Of Masataka Ohta Sent: Monday, 5 August 2019 11:07 AM To: nanog at nanog.org Subject: Re: MAP-E Baldur Norddahl wrote: > Or the case of Playstation network. Yes they WILL blacklist your CGN > just the same as they can blacklist a shared MAP ip address. Except it > affects more users. If IP address sharing by blocks of ports becomes common and there is typical block size (say, 1024), blacklisting will be done block-wise. Masataka Ohta From janets at nairial.net Mon Aug 5 01:47:50 2019 From: janets at nairial.net (Janet Sullivan) Date: Mon, 5 Aug 2019 01:47:50 +0000 Subject: Xfinity with IPv6 clue? In-Reply-To: References: Message-ID: Nanog is magical. I have working IPv6 now. From: Janet Sullivan Sent: Sunday, August 4, 2019 6:29 PM To: 'nanog at nanog.org' Subject: Xfinity with IPv6 clue? I hate resorting to NANOG, but I've spent over 5 hours on the phone with Xfinity the past two days, and I can't seem to get someone who understands my problem. I do not have working IPv6 - I do not get an address or PD. I have working IPv4. Xfinity wanted to blame this on my modem, so I went and picked up a Xfinity modem. From the 10.0.0.1 web site on the xfinity modem, I can ping IPv4 addresses fine. I can not ping IPv6 addresses from the modem itself, thus taking my equipment out of the picture. This is a new activation. Xfinity keeps asking questions like "well, can you surf the internet", which shows that they seem to totally lack understanding. I've talked to at least 7 people, and have reached my breaking point. I know, I know, its residential and I should have low expectations. I'm sorry for the noise, but I can't seem to find anyone with clue. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ross at tajvar.io Mon Aug 5 02:00:30 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sun, 4 Aug 2019 22:00:30 -0400 Subject: Xfinity with IPv6 clue? In-Reply-To: References: Message-ID: Did you get in touch with someone? What was the problem? On Sun, Aug 4, 2019, 9:50 PM Janet Sullivan wrote: > Nanog is magical. I have working IPv6 now. > > > > *From:* Janet Sullivan > *Sent:* Sunday, August 4, 2019 6:29 PM > *To:* 'nanog at nanog.org' > *Subject:* Xfinity with IPv6 clue? > > > > I hate resorting to NANOG, but I’ve spent over 5 hours on the phone with > Xfinity the past two days, and I can’t seem to get someone who understands > my problem. > > > > I do not have working IPv6 – I do not get an address or PD. I have > working IPv4. Xfinity wanted to blame this on my modem, so I went and > picked up a Xfinity modem. From the 10.0.0.1 web site on the xfinity > modem, I can ping IPv4 addresses fine. I can not ping IPv6 addresses from > the modem itself, thus taking my equipment out of the picture. This is a > new activation. Xfinity keeps asking questions like “well, can you surf > the internet”, which shows that they seem to totally lack understanding. > I’ve talked to at least 7 people, and have reached my breaking point. I > know, I know, its residential and I should have low expectations. I’m > sorry for the noise, but I can’t seem to find anyone with clue. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Mon Aug 5 02:50:02 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Sun, 04 Aug 2019 22:50:02 -0400 Subject: MAP-E In-Reply-To: <3da10d9c-2dbc-92c0-92aa-15082b99cb47@necom830.hpcl.titech.ac.jp> References: <4C436557-6E87-4D5E-A55C-14E0ADA0F83C@consulintel.es> <3da10d9c-2dbc-92c0-92aa-15082b99cb47@necom830.hpcl.titech.ac.jp> Message-ID: <58485.1564973402@turing-police> On Mon, 05 Aug 2019 06:42:30 +0900, Masataka Ohta said: > JORDI PALET MARTINEZ via NANOG wrote: > > A problem of dynamic sharing is that logging information to be used > > for such purposes as crime investigation becomes huge. > > > -> Of course, everything has good and bad things, but with NAT444 you > > need to do the same, > > With static port range assignment, we don't have to. So you're going to say what ports the users are forced to use... > Only users know what applications they are using. When you don't know what applications on what ports they are using. Gotcha. > I'm not interested in poor IPv6. Well... if you have poor IPv6 support from your ISP, we can understand that. Have you tried talking to your ISP and getting them to provide good IPv6 support? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mohta at necom830.hpcl.titech.ac.jp Mon Aug 5 03:13:15 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 5 Aug 2019 12:13:15 +0900 Subject: MAP-E In-Reply-To: <58485.1564973402@turing-police> References: <4C436557-6E87-4D5E-A55C-14E0ADA0F83C@consulintel.es> <3da10d9c-2dbc-92c0-92aa-15082b99cb47@necom830.hpcl.titech.ac.jp> <58485.1564973402@turing-police> Message-ID: <07d6d3e6-d271-69fc-45db-980e04a28ec6@necom830.hpcl.titech.ac.jp> Valdis Kletnieks wrote: >>> -> Of course, everything has good and bad things, but with NAT444 you >>> need to do the same, >> >> With static port range assignment, we don't have to. > > So you're going to say what ports the users are forced to use... Like DHCP, yes. So? >> Only users know what applications they are using. > > When you don't know what applications on what ports they are using. You don't have to know, because its user's problem. >> I'm not interested in poor IPv6. > > Well... if you have poor IPv6 support from your ISP, we can understand that. You don't understand I was an active member of IPng WG trying to prevent the WG make poor decisions. I was only partially successful. Masataka Ohta From mehmet at akcin.net Mon Aug 5 03:41:14 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Sun, 4 Aug 2019 20:41:14 -0700 Subject: What can ISPs do better? Removing racism out of internet Message-ID: Ok, two mass shootings, touchy topic, lots of emotions this weekend. Going straight to the point. Most of us who operate internet services believe in not being the moderator of internet. We provide a service and that’s it. Obviously there are some established laws around protecting copyrights, and other things which force us to legally take action and turn things down when reported. What can we do better as network operators about hate sites like 8Chan? I applaud cloudflare’s (perhaps slightly late) decision on kicking 8chan off its platform today after El Paso attack. https://blog.cloudflare.com/terminating-service-for-8chan/ I am sure there are many sites like this out there, but could network operators do anything to make these sites “not so easy” to be found, reached, and used to end innocent lives? Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at rkhtech.org Mon Aug 5 03:59:20 2019 From: ryan at rkhtech.org (Ryan Hamel) Date: Sun, 4 Aug 2019 20:59:20 -0700 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: <1564977198.local-04de4988-9d41-v1.2.1-5f094887@getmailspring.com> > could network operators do anything to make these sites “not so easy” to be found, reached, and used to end innocent lives? Nope. If they follow the word of the providers and services they use, there is no reason to terminate the service. CloudFlare terminating 8chan's service was a one off thing. Search rankings have nothing to do with the hosting or proxy provider. If 8chan is coloed, the only options are feds seizing hardware or tapping their connectivity. Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredbaker.ietf at gmail.com Mon Aug 5 07:12:17 2019 From: fredbaker.ietf at gmail.com (Fred Baker) Date: Mon, 5 Aug 2019 00:12:17 -0700 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: > On Aug 4, 2019, at 8:41 PM, Mehmet Akcin wrote: > > I am sure there are many sites like this out there, but could network operators do anything to make these sites “not so easy” to be found, reached, and used to end innocent lives? I''d suggest reducing their reputation rankings, as reported by SpamHous and their kin. That's not to say that "Spamhaus and their kin must", although that would be one implementation. Another would be to include them also some other ranking mechanism in the analysis, and reduce the reputation of such sites in the implied alternative. Another would be to include such rankings in their calculations of whom to accept as customers - BGP or otherwise - and if some AS seems to accept such as customers, not accept them. I imagine they do, to some extent, but this could be followed up more closely. From fredbaker.ietf at gmail.com Mon Aug 5 07:16:54 2019 From: fredbaker.ietf at gmail.com (Fred Baker) Date: Mon, 5 Aug 2019 00:16:54 -0700 Subject: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis In-Reply-To: <16ed85bb-b8f9-419c-9a88-2eb20a64e717@netravnen.de> References: <53b7b43a-316d-0a62-e247-b78beca196d1@netravnen.de> <1035588386.903366.1564947649242@mail.yahoo.com> <16ed85bb-b8f9-419c-9a88-2eb20a64e717@netravnen.de> Message-ID: <639E62D1-5ED0-40D9-B913-7AA614137686@gmail.com> > On Aug 4, 2019, at 5:29 PM, Chriztoffer Hansen wrote: > > The question was simply about if GLBP/HSRP had ever been up in discussions in the IETF concerning publishing the protocol specifications as a standard. (As pointed out. I totally forgot about the RFC concerning HSRP.) Haven't gotten a response on the GLBP part. Which I am more than doubtful, myself, will ever come to fruition as a standard in an IETF WG. AFAIK (and any specific knowledge I have of Cisco is dated), Cisco has not asked the IETF to standardize its proprietary protocol. An obvious start would be for Cisco customers to ask Cisco to do so. With HSRP/VRRP, someone wrote a specification that they thought Would accomplish the Cisco-proprietary objectives, and championed that through IETF processes. At least part of that had to do with a Cisco competitor and someone who had a bee in their bonnet. I'm not telling you to do that (my observation of HSRP/VRRP is that the result has been two competing protocols, not a winner and a loser), but it's a question you might ask your vendor about. From jordi.palet at consulintel.es Mon Aug 5 08:49:42 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 05 Aug 2019 10:49:42 +0200 Subject: MAP-E In-Reply-To: References: <4C436557-6E87-4D5E-A55C-14E0ADA0F83C@consulintel.es> Message-ID: This is not surprising to me as Dlink was one of my co-authors for RFC8585 ... and they indicated in v6ops that implementing CLAT was really easy. I guess they need to improve the GUI, etc. Note that with 464XLAT, you still need the NAT64 at the ISP side, and also, the traceroutes will shows something weird, so not trustable unless you understand very well how it works. However, testing a web site or other services will work fine. Regards, Jordi @jordipalet El 5/8/19 3:45, "NANOG en nombre de Philip Loenneker" escribió: Moving away from the discussion around what technology people may choose to go with, and instead what CPEs may be suitable... I know this is 464XLAT rather than MAP-E that was originally requested, but recent versions of D-Link firmware, eg for the DVA-2800, include the CLAT functionality. My testing in November last year showed that it only partially worked, with the traceroutes to 64:ff9b::1.1.1.1 working, but it would not automatically translate a traceroute to 1.1.1.1 to the IPv6 version. There have been a few new revisions since then and it is on my to-do list to re-test things, but I haven't had the time. It is also worth noting that, in the original firmware revision I tested, I had to manually enter the URL for the CLAT configuration screen. It simply wasn't on the menu. On another version, it had a link to DS-Lite configuration, and from there you get a link to the CLAT options. It is possible that other devices and/or vendors also have this option, or options for similar technologies such as MAP-E, but they just don't have a link to it in the interface. -----Original Message----- From: NANOG On Behalf Of Masataka Ohta Sent: Monday, 5 August 2019 11:07 AM To: nanog at nanog.org Subject: Re: MAP-E Baldur Norddahl wrote: > Or the case of Playstation network. Yes they WILL blacklist your CGN > just the same as they can blacklist a shared MAP ip address. Except it > affects more users. If IP address sharing by blocks of ports becomes common and there is typical block size (say, 1024), blacklisting will be done block-wise. Masataka Ohta ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From sc at ottie.org Mon Aug 5 09:15:10 2019 From: sc at ottie.org (Scott Christopher) Date: Mon, 05 Aug 2019 12:15:10 +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> <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> <2d008a95-b5c9-4d9c-aed0-c040f5bca164@www.fastmail.com> Message-ID: <517fec42-1f8b-4797-a4d5-551d5437f404@www.fastmail.com> Rubens Kuhl wrote: > I don't think that "companies with tons of lawyers" should be a factor in making resource allocation policies. But considering either small or big networks, an escalation path would reduce friction and increase overall compliance... for instance, failure to have functioning abuse PoC could lead first to being inegible to receive new resources. It's not about $BIGCORP having lots of corporate lawyers imposing its will on the small guys - it's about Amazon's role as a public utility, upon which many many many important things depend. S.C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chriztoffer at netravnen.de Mon Aug 5 12:42:53 2019 From: chriztoffer at netravnen.de (Chriztoffer Hansen) Date: Mon, 5 Aug 2019 14:42:53 +0200 Subject: Xfinity with IPv6 clue? In-Reply-To: References: Message-ID: <809dcb7e-5caa-42c3-8c5b-1c87a2baaff9@netravnen.de> Janet, Did an actual person follow up with you privately after ipv6 got working on your connection? ... Or was it more like magic silence from their end. And suddenly it "just" worked? /Chriztoffer On 05/08/2019 04:00, Ross Tajvar wrote: > Did you get in touch with someone? What was the problem? From dot at dotat.at Mon Aug 5 15:02:08 2019 From: dot at dotat.at (Tony Finch) Date: Mon, 5 Aug 2019 16:02:08 +0100 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: References: Message-ID: Fred Baker wrote: > > On Aug 3, 2019, at 3:36 PM, Mehmet Akcin wrote: > > > > Feel free to open live.infrapedia.com on mobile. > Between overlaid ads and the thing trying to force an account, i’d > Describe it as a waste of time. Now, a page that delivered the data > advertised... https://openinframap.org/ works a lot better. Tony. -- f.anthony.n.finch http://dotat.at/ justice and liberty cannot be confined by national boundaries From kmedcalf at dessus.com Mon Aug 5 15:04:30 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 05 Aug 2019 09:04:30 -0600 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: Message-ID: On Sunday, 4 August, 2019 21:41, Mehmet Akcin wrote: >Most of us who operate internet services believe in not being the >moderator of internet. We provide a service and that’s it. Obviously >there are some established laws around protecting copyrights, and >other things which force us to legally take action and turn things >down when reported. >What can we do better as network operators about hate sites like >8Chan? >I applaud cloudflare’s (perhaps slightly late) decision on kicking >8chan off its platform today after El Paso attack. >https://blog.cloudflare.com/terminating-service-for-8chan/ >I am sure there are many sites like this out there, but could network >operators do anything to make these sites “not so easy” to be found, >reached, and used to end innocent lives? I do not quite understand this. In days of yore, nutters used to send their screeds to Newspapers, TV and Radio stations. Did you shut them down or move them to frequencies that could not be received with COTS TVs and Radios? Did you ban the newspapers, put them out of business, or make it so their broadsheet was only available by travelling by aeroplane for 8 hours before breakfast? Of course not, you silly duck! There is an advantage to having all the nutters congregating on one place -- you know exactly where to find them. Granted, the advantage is not exactly the same as we apply to politicians (or lawyers) who are kepts all in one place so that kinetic weapons can dispatch the whole lot at one go if necessary. However, your solution of sweeping things you do not like under the rug is ill-conceived if not brain-dead in conception and you must not be permitted to carry out your objectives. The fate of the free world depends on it. However, do not worry. US AG William Barr is doing a fine job deploying his "backdoors". Why just the other day one of them was used to shut down the Georgia State Public Safety Services, and prior to that his "backdoors" were used to shut down several city computer systems in Florida and even the City of Baltimore. Good work with those backdoors, Mr. Barr. Job well done! It is nincompoops who do not think about what they are doing that create such a bloody mess of things. They should let the adults take care of it. Now, enough of this off-topic stuff and back to our regularly scheduled programming. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From nikosietf at gmail.com Sun Aug 4 18:14:38 2019 From: nikosietf at gmail.com (Nikos Leontsinis) Date: Sun, 4 Aug 2019 21:14:38 +0300 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: References: Message-ID: <1F1F339F-2492-440A-A54A-41E552ECCAEA@gmail.com> Agree > On 4 Aug 2019, at 18:50, Fred Baker wrote: > > Between overlaid ads and the thing trying to force an account, i’d Describe it as a waste of time. Now, a page that delivered the data advertised... > > Sent using a machine that autocorrects in interesting ways... > >> On Aug 3, 2019, at 3:36 PM, Mehmet Akcin wrote: >> >>  >> Feel free to open live.infrapedia.com on mobile. Click on share location icon. And it will show 3D view of any fiber near by. >> >> We are thinking about adding wireless networks too and maybe overlaying national cell phone coverage maps >> >>> On Sat, Aug 3, 2019 at 14:21 Mark Tinka wrote: >>> >>> >>>> On 3/Aug/19 23:09, Ross Tajvar wrote: >>>>> On Sat, Aug 3, 2019 at 4:30 PM Brian Henson wrote: >>>>> If we had a location (or at least a part of the world) we might be able to recommend a little better. >>>> >>>> >>>> This is in northern Africa. >>> >>> Hmmh - normally, when someone says North America, it's one of 2 countries. Not much fuss there... >>> >>> North Africa (by some kind of definition) is 8 or 10 countries, depending on what you feel North Africa means. >>> >>> In short, you'll have to be more specific than that... >>> >>> >>> Mark. >>> >> -- >> Mehmet >> +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at nethead.com Mon Aug 5 03:45:56 2019 From: joe at nethead.com (Joe Hamelin) Date: Sun, 4 Aug 2019 20:45:56 -0700 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: Well, once they let NetOps fire sales staff we can get some traction going. -- Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 On Sun, Aug 4, 2019 at 8:42 PM Mehmet Akcin wrote: > Ok, two mass shootings, touchy topic, lots of emotions this weekend. Going > straight to the point. > > Most of us who operate internet services believe in not being the > moderator of internet. We provide a service and that’s it. Obviously there > are some established laws around protecting copyrights, and other things > which force us to legally take action and turn things down when reported. > > What can we do better as network operators about hate sites like 8Chan? > > I applaud cloudflare’s (perhaps slightly late) decision on kicking 8chan > off its platform today after El Paso attack. > https://blog.cloudflare.com/terminating-service-for-8chan/ > > I am sure there are many sites like this out there, but could network > operators do anything to make these sites “not so easy” to be found, > reached, and used to end innocent lives? > > Mehmet > > > -- > Mehmet > +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From covici at ccs.covici.com Fri Aug 2 20:53:16 2019 From: covici at ccs.covici.com (John Covici) Date: Fri, 02 Aug 2019 16:53:16 -0400 Subject: OT: Tech bag In-Reply-To: References: Message-ID: Maybe I made a mistake, let me try again. its https://www.tombihnn.com, sorry about that. On Fri, 02 Aug 2019 14:54:49 -0400, Christopher Morrow wrote: > > On Fri, Aug 2, 2019 at 2:50 PM John Covici wrote: > > > > https://www.tombin.com has some great bags for laptops, etc. Not > > 'server has no ip address' ..... > $ ping www.tombin.com > PING www.tombin.com (127.0.0.1) > > good try to get us all infected by malware... > > On a less funny note, try out some of the various osprey bags. > > > > cheap but very good stuff. > > > > On Fri, 02 Aug 2019 12:19:08 -0400, > > Hunter Fuller wrote: > > > > > > I carry this. It's a preference I gained in my past life: > > > https://www.kleintools.com/catalog/tool-storage/tradesman-pro-backpack > > > > > > I put my notebook (Surface Pro) in a sleeve and sandwich it between > > > the halves. It hasn't gotten crushed to death yet. I'll admit this is > > > not optimal. > > > > > > This one has since been released, and it has a laptop compartment. My > > > co-worker loves it: > > > https://www.kleintools.com/catalog/tradesman-pro-organizers/tradesman-pro-tech-backpack > > > > > > On Fri, Aug 2, 2019 at 11:14 AM Dovid Bender wrote: > > > > > > > > Hi, > > > > > > > > Sorry for the OT email. I travel extensively to DC's and my computer bag seems to keep collecting more tools which includes your usual console cables, spare everything, two laptops etc. My Swissgear has been taking a beating and I was wondering what others who have to lug around 30-35 pounds use. > > > > > > > > TIA. > > > > > > > > > > > > > > > -- > > Your life is like a penny. You're going to lose it. The question is: > > How do > > you spend it? > > > > John Covici wb2una > > covici at ccs.covici.com > -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una covici at ccs.covici.com From brandon at brandonsjames.com Sat Aug 3 03:06:35 2019 From: brandon at brandonsjames.com (Brandon James) Date: Sat, 3 Aug 2019 03:06:35 +0000 Subject: RFC 5771 - Global Multicast Addresses Message-ID: Good Evening, I'm looking for some insight into the usage of a few of the blocks defined in RFC 5771 (and IPv6 Multicast Addressing as described in RFC 4291 and 7346) , specifically regarding their use on the public internet. I know multicast isn't routed on the public internet. However, it appears that this may be due to operational issues and concerns or that it was simply never implemented. The specific blocks I'm looking at are (as defined in RFC 5771 Section 3-10: Internetwork Control Block - 224.0.1.0/24 > Addresses in the Internetwork Control Block are used for protocol control traffic that MAY be forwarded through the Internet AD-HOC Blocks (I, II, and III) - 224.0.2.0 - 224.0.255.255, 224.3.0.0 - 224.4.255.255, and 233.252.0.0 - 233.255.255.255 > These addresses MAY be globally routed GLOP Block (233/8) - Global routing is never mentioned in RFC 5771, but given the context and the use of ASNs, I'm not sure if the intention was for these to be publicly routable or to simply to guarantee that the address would be unique within your AS (are large telcos and webscale companies exhausting 239.0.0.0/8?) IPv6 Multicast Addresses with scope 0xE - The RFC doesn't really go into detail on how these would be used. As a young network engineer (no historic perspective) and only SMB and enterprise experience. It seems like the intention was to allow these to be publicly routed, but it would be a nightmare to implement so it never was. You'd probably require PIM Sparse Mode (we can't flood traffic to the entire internet), RPs would need to be advertised somehow (maybe BSR could be implemented with RP advertisements coming from the providers edge?). RPF would be a constant process and shortest path trees would change constantly. That's all without mentioning 224.0.1.0/24 is tiny and the AD-HOC and GLOP blocks aren't exactly huge given the size of the internet. I'd love to hear what others have to say about this, maybe get some historic perspective and thoughts on whether or not any of this will change as IPv6 adoption increases. I'd also love to see any guidance on actually implementing multicast on the internet from IANA or the IETF (or guidance that says that it should not or can not be done) as I wasn't able to find any. Regards, Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Mon Aug 5 15:13:34 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 5 Aug 2019 15:13:34 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: , Message-ID: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> Mehmet, I’m not sure if you understand the terms under which ISPs operate as “common carriers”, and thus enjoy immunity from lawsuits due to the acts of their customers. ISPs such as Cloudfare can no more disconnect customers for legal, if offensive, content than the phone company can, without losing that common carrier status. Cloudfare is being foolish, and hypocritical. They freely, for example, carry the equally offensive content of Antifa. Are they going to cut them off too? In America we have the right to free speech, and the right to use common carriers to carry that speech. If a common carrier chooses to censor legal speech, which is what Cloudfare has done, then it loses its CC status and can now be sued for that speech. -mel beckman > On Aug 5, 2019, at 8:06 AM, Keith Medcalf wrote: > > >> On Sunday, 4 August, 2019 21:41, Mehmet Akcin wrote: >> >> Most of us who operate internet services believe in not being the >> moderator of internet. We provide a service and that’s it. Obviously >> there are some established laws around protecting copyrights, and >> other things which force us to legally take action and turn things >> down when reported. > >> What can we do better as network operators about hate sites like >> 8Chan? > >> I applaud cloudflare’s (perhaps slightly late) decision on kicking >> 8chan off its platform today after El Paso attack. >> https://blog.cloudflare.com/terminating-service-for-8chan/ > >> I am sure there are many sites like this out there, but could network >> operators do anything to make these sites “not so easy” to be found, >> reached, and used to end innocent lives? > > I do not quite understand this. > > In days of yore, nutters used to send their screeds to Newspapers, TV and Radio stations. Did you shut them down or move them to frequencies that could not be received with COTS TVs and Radios? Did you ban the newspapers, put them out of business, or make it so their broadsheet was only available by travelling by aeroplane for 8 hours before breakfast? > > Of course not, you silly duck! > > There is an advantage to having all the nutters congregating on one place -- you know exactly where to find them. Granted, the advantage is not exactly the same as we apply to politicians (or lawyers) who are kepts all in one place so that kinetic weapons can dispatch the whole lot at one go if necessary. > > However, your solution of sweeping things you do not like under the rug is ill-conceived if not brain-dead in conception and you must not be permitted to carry out your objectives. The fate of the free world depends on it. > > However, do not worry. US AG William Barr is doing a fine job deploying his "backdoors". Why just the other day one of them was used to shut down the Georgia State Public Safety Services, and prior to that his "backdoors" were used to shut down several city computer systems in Florida and even the City of Baltimore. Good work with those backdoors, Mr. Barr. Job well done! > > It is nincompoops who do not think about what they are doing that create such a bloody mess of things. They should let the adults take care of it. > > Now, enough of this off-topic stuff and back to our regularly scheduled programming. > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. > > > > > From portia.rabonda at safnog.net Sat Aug 3 23:57:17 2019 From: portia.rabonda at safnog.net (Portia Rabonda) Date: Sat, 3 Aug 2019 23:57:17 +0000 Subject: SAFNOG-5 Call For Papers Deadline Message-ID: <1564876637176.75047@safnog.net> Greetings, It's August and the SAFNOG-5 countdown has officially begun! [cid:924e4f24-b227-4750-bee8-fba8c0dd64d9]There's only 2 DAYS left for paper submissions. If you are keen to present/share your expertise on the relevant topics below, submit your paper online at http://www.safnog.org/call-for-papers.html by Monday, 5th August at latest. Topics proposed must be relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and Operations - IPv6 deployment and transition technologies - Internet backbone operations - ISP and Carrier services - IXPs and Peering - Research on Internet Operations and Deployment - Software Defined Networking / Network Function Virtualisation - Network security issues (NSP-SEC, DDoS, Anti-Spam, Anti-Malware) - DNS / DNSSEC - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including Cable/DSL, LTE/5G, wireless, metro ethernet, fibre, segment routing - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) and Cloud Computing Don't hesitate to contact the Programme Committee at safnog-pc-chairs at safnog.org with any questions. We look forward to receiving your presentation proposals. Regards, SAFNOG-5 Programme Committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Mon Aug 5 15:15:11 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 5 Aug 2019 18:15:11 +0300 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: Peace, On Mon, Aug 5, 2019 at 6:42 AM Mehmet Akcin wrote: > What can we do better as network operators about > hate sites like 8Chan? About nothing, because recent IETF developments like QUIC, ESNI, or MASQUE would completely prohibit you from figuring out what sites you, as an ISP, are giving an access to. This is, uh, the very point of those developments. > I applaud cloudflare’s (perhaps slightly late) decision on > kicking 8chan off its platform today after El Paso attack. The 8chan shutdown is no more than a one off. And I assume 8chan just needs to change the name to get their service back. There's no trend whatsoever. This is also sooo funny, because Cloudflare is happily protecting even DDoS booters for almost a decade. $ host -t A ddos-black.info ddos-black.info has address 104.31.72.53 ddos-black.info has address 104.31.73.53 $ whois 104.31.72.53 | grep OrgName: OrgName: Cloudflare, Inc. $ host -t A ddos-stress.cc ddos-stress.cc has address 104.28.4.14 ddos-stress.cc has address 104.28.5.14 $ whois 104.28.4.14 | grep OrgName: OrgName: Cloudflare, Inc. $ Those booters basically only exist because Cloudflare, OVH, and others allow them to. A booter business isn't very steady and profitable. Without a cheap DDoS protection those services would be dead in weeks, because sometimes their operators don't even know how to mitigate their own attacks themselves. So they get that protection from Cloudflare, because apparently that doesn't violate "the Cloudflare mission to help build a better Internet". This is just one example. Carding fraud, malware, illegal munitions, drugs, whatever. It's all there. But, ya know, all those are much better than some imageboard outta there. The latter is the root of all evil. -- Töma From mel at beckman.org Mon Aug 5 15:15:58 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 5 Aug 2019 15:15:58 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: , Message-ID: “Now, enough of this off-topic stuff and back to our regularly scheduled programming.” Keith, what could be more on-topic than an ISP’s status as a common carrier? Seems pretty operational to me. -mel > On Aug 5, 2019, at 8:06 AM, Keith Medcalf wrote: > > Now, enough of this off-topic stuff and back to our regularly scheduled programming. From lists at benappy.com Mon Aug 5 15:21:10 2019 From: lists at benappy.com (Michel 'ic' Luczak) Date: Mon, 5 Aug 2019 17:21:10 +0200 Subject: OT: Tech bag In-Reply-To: References: Message-ID: <0F5A58BF-710A-429B-846C-73E23838A67B@benappy.com> Hi, > On 2 Aug 2019, at 18:14, Dovid Bender wrote: > > Hi, > > Sorry for the OT email. I travel extensively to DC's and my computer bag seems to keep collecting more tools which includes your usual console cables, spare everything, two laptops etc. My Swissgear has been taking a beating and I was wondering what others who have to lug around 30-35 pounds use. I regularly put two 15” laptops in this https://brenthaven.com/product/metrolite-laptop-backpack/ and front pocket is packet with tools, PSUs, wires, … /ic -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikebolitho at gmail.com Mon Aug 5 15:22:39 2019 From: mikebolitho at gmail.com (Mike Bolitho) Date: Mon, 5 Aug 2019 08:22:39 -0700 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: "I am sure there are many sites like this out there, but could network operators do anything to make these sites “not so easy” to be found, reached, and used to end innocent lives?" As network operators? We shouldn't do anything. The onus falls on the hosting companies. I do not want to go down the slippery slope of deciding what traffic should or should not be allowed on the internet. That process involves traffic sniffing and possibly attempting to break encryption to see what's flowing through the pipes. I'm adamantly against that. If I'm building and maintaining highways, I'm not opening up every single truck to make sure there's nobody being smuggled inside. The trucking company can police what cargo is in their trailers. On Sun, Aug 4, 2019, 8:42 PM Mehmet Akcin wrote: > Ok, two mass shootings, touchy topic, lots of emotions this weekend. Going > straight to the point. > > Most of us who operate internet services believe in not being the > moderator of internet. We provide a service and that’s it. Obviously there > are some established laws around protecting copyrights, and other things > which force us to legally take action and turn things down when reported. > > What can we do better as network operators about hate sites like 8Chan? > > I applaud cloudflare’s (perhaps slightly late) decision on kicking 8chan > off its platform today after El Paso attack. > https://blog.cloudflare.com/terminating-service-for-8chan/ > > I am sure there are many sites like this out there, but could network > operators do anything to make these sites “not so easy” to be found, > reached, and used to end innocent lives? > > Mehmet > > > -- > Mehmet > +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nchabbey at n3network.ch Mon Aug 5 15:19:38 2019 From: nchabbey at n3network.ch (Nicolas Chabbey) Date: Mon, 5 Aug 2019 17:19:38 +0200 Subject: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis In-Reply-To: <1035588386.903366.1564947649242@mail.yahoo.com> References: <53b7b43a-316d-0a62-e247-b78beca196d1@netravnen.de> <1035588386.903366.1564947649242@mail.yahoo.com> Message-ID: <03701d21-f581-fc84-4779-bb16020e2078@n3network.ch> Are there any good reasons of using proprietary FHRPs like HSRP and GLBP over VRRP ? I know that one reason may be interoperability with some vendors equipment and old gears, but VRRPv3 is now widely used, in particular for IPv6. Also VRRP can be easily extended with proprietary extensions and looks very similar to HSRP in its operation. Regards. On 04/08/2019 21:40, cyrus ramirez via NANOG wrote: > If you're looking for vendor neutral FHRP, VRRP has RFC documentation. > GLBP and HSRP are Cisco proprietary protocols and are protected > information other than the study material and how too out there. > > Cyrus > > Sent from Yahoo Mail on Android > > > On Sat, Aug 3, 2019 at 10:19 AM, Chriztoffer Hansen > wrote: > > Saku Ytti wrote on 03/08/2019 15:49: > > I don't think any work for GLBP exists in IETF. > > A shot in the dark. Correct. > > https://www.google.com/#q=%28"GLBP"%7C"Gateway+Load+Balancing"+Protocol%7C"Global+Load+Balancing"+Protocol%29+AND+inurl%3Adatatracker+AND+inurl%3Aietf > > (My IETF history is short. =I won't know any older history.) > > ... I doubt any current or previous Cisco folks on the list would want > to chirm in about history from inside Cisco on the GLBP topic...(?) > > > -- > Best regards, > Chriztoffer > From niels=nanog at bakker.net Mon Aug 5 15:29:08 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 5 Aug 2019 17:29:08 +0200 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> Message-ID: <20190805152908.GB2592@jima.tpb.net> * mel at beckman.org (Mel Beckman) [Mon 05 Aug 2019, 17:21 CEST]: >Cloudfare is being foolish, and hypocritical. They freely, for >example, carry the equally offensive content of Antifa. Are they >going to cut them off too? Finally, a centrist to point out the true culprits of all this violence From patrick at ianai.net Mon Aug 5 15:32:34 2019 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 5 Aug 2019 11:32:34 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> Message-ID: Mel: My understanding is ISPs are not Common Carriers. Didn’t we just have a big debate about this w/r/t Network Neutrality? I Am Not A Lawyer (hell, I am not even an ISP :), but if any legal experts want to chime in, please feel free to educate us. Put another way, ISPs are not phone companies. Moreover, ISPs - and CDNs and hosting providers and etc. - can have terms of service which do not allow certain types of content on their platform. Again, that is is my understanding. Happy to be educated by someone who specializes in this type of law. I know there are a couple such people on NANOG-l. -- TTFN, patrick P.S. Interesting choice equating a group founded on the principals that “Nazis are bad” and a group espousing Nazi ideas. But that’s very off-topic, so if you want to discuss, please do so directly. > On Aug 5, 2019, at 11:13 AM, Mel Beckman wrote: > > Mehmet, > > I’m not sure if you understand the terms under which ISPs operate as “common carriers”, and thus enjoy immunity from lawsuits due to the acts of their customers. ISPs such as Cloudfare can no more disconnect customers for legal, if offensive, content than the phone company can, without losing that common carrier status. > > Cloudfare is being foolish, and hypocritical. They freely, for example, carry the equally offensive content of Antifa. Are they going to cut them off too? > > In America we have the right to free speech, and the right to use common carriers to carry that speech. If a common carrier chooses to censor legal speech, which is what Cloudfare has done, then it loses its CC status and can now be sued for that speech. > > -mel beckman > >> On Aug 5, 2019, at 8:06 AM, Keith Medcalf wrote: >> >> >>> On Sunday, 4 August, 2019 21:41, Mehmet Akcin wrote: >>> >>> Most of us who operate internet services believe in not being the >>> moderator of internet. We provide a service and that’s it. Obviously >>> there are some established laws around protecting copyrights, and >>> other things which force us to legally take action and turn things >>> down when reported. >> >>> What can we do better as network operators about hate sites like >>> 8Chan? >> >>> I applaud cloudflare’s (perhaps slightly late) decision on kicking >>> 8chan off its platform today after El Paso attack. >>> https://blog.cloudflare.com/terminating-service-for-8chan/ >> >>> I am sure there are many sites like this out there, but could network >>> operators do anything to make these sites “not so easy” to be found, >>> reached, and used to end innocent lives? >> >> I do not quite understand this. >> >> In days of yore, nutters used to send their screeds to Newspapers, TV and Radio stations. Did you shut them down or move them to frequencies that could not be received with COTS TVs and Radios? Did you ban the newspapers, put them out of business, or make it so their broadsheet was only available by travelling by aeroplane for 8 hours before breakfast? >> >> Of course not, you silly duck! >> >> There is an advantage to having all the nutters congregating on one place -- you know exactly where to find them. Granted, the advantage is not exactly the same as we apply to politicians (or lawyers) who are kepts all in one place so that kinetic weapons can dispatch the whole lot at one go if necessary. >> >> However, your solution of sweeping things you do not like under the rug is ill-conceived if not brain-dead in conception and you must not be permitted to carry out your objectives. The fate of the free world depends on it. >> >> However, do not worry. US AG William Barr is doing a fine job deploying his "backdoors". Why just the other day one of them was used to shut down the Georgia State Public Safety Services, and prior to that his "backdoors" were used to shut down several city computer systems in Florida and even the City of Baltimore. Good work with those backdoors, Mr. Barr. Job well done! >> >> It is nincompoops who do not think about what they are doing that create such a bloody mess of things. They should let the adults take care of it. >> >> Now, enough of this off-topic stuff and back to our regularly scheduled programming. >> >> -- >> 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 chk at pobox.com Mon Aug 5 15:34:28 2019 From: chk at pobox.com (Harald Koch) Date: Mon, 05 Aug 2019 11:34:28 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: On Mon, Aug 5, 2019, at 11:30, Mel Beckman wrote: > Keith, what could be more on-topic than an ISP’s status as a common > carrier? Seems pretty operational to me. American ISPs are not common carriers. When net neutrality was revoked on December 14, 2017, so was ISP's common carrier status / protection. -- Harald From mehmet at akcin.net Mon Aug 5 15:37:08 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Mon, 5 Aug 2019 08:37:08 -0700 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: References: Message-ID: there is nothing about telecoms in this map, it's all about powerlines. On Mon, Aug 5, 2019 at 8:02 AM Tony Finch wrote: > Fred Baker wrote: > > > On Aug 3, 2019, at 3:36 PM, Mehmet Akcin wrote: > > > > > > Feel free to open live.infrapedia.com on mobile. > > > Between overlaid ads and the thing trying to force an account, i’d > > Describe it as a waste of time. Now, a page that delivered the data > > advertised... > > https://openinframap.org/ works a lot better. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > justice and liberty cannot be confined by national boundaries -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels=nanog at bakker.net Mon Aug 5 15:44:48 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Mon, 5 Aug 2019 17:44:48 +0200 Subject: RFC 5771 - Global Multicast Addresses In-Reply-To: References: Message-ID: <20190805154448.GC2592@jima.tpb.net> * brandon at brandonsjames.com (Brandon James) [Mon 05 Aug 2019, 17:17 CEST]: >As a young network engineer (no historic perspective) and only SMB >and enterprise experience. It seems like the intention was to allow >these to be publicly routed, but it would be a nightmare to >implement so it never was. Multicast was never popular with operators because it had the potential to create a lot of state across every router in a network, as well as lead to uncontrolled explosions of traffic, especially in network designs that relied on virtual circuits for significant portions of last-mile infrastructure. Some of these problems were addressed with SSM, IP DSLAMs, and having consumer connection speeds be significantly faster than what a Full HD video stream requires, but given that major network providers already don't have the in-house clue to implement IPv6, multicast will be very low priority. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From kmedcalf at dessus.com Mon Aug 5 15:54:00 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 05 Aug 2019 09:54:00 -0600 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: Message-ID: On Monday, 5 August, 2019 09:16, Mel Beckman wrote: >“Now, enough of this off-topic stuff and back to our regularly >scheduled programming.” >Keith, what could be more on-topic than an ISP’s status as a common >carrier? Seems pretty operational to me. I think that is closing the barn door after the horse already left. It is my understanding that in your fabulous United States of America that "carriers" (meaning having no content serving nor content consuming customers*) may be "common carriers" or can claim to be common carriers. The rest of you who are not pure carriers are, thanks to Ijit Pai, merely Information Services and do not have common carrier status, nor can you claim to be common carriers. A "common carrier" is one who must provide carriage provided the fee for carriage is paid. This is not the case for "Information Service" providers as they are not required to provide carriage to any who can pay the fee for carriage. *I hate the term "content", it is somowhat lame. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From matt at netfire.net Mon Aug 5 15:54:31 2019 From: matt at netfire.net (Matt Harris) Date: Mon, 5 Aug 2019 10:54:31 -0500 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: On Sun, Aug 4, 2019 at 10:41 PM Mehmet Akcin wrote: > What can we do better as network operators about hate sites like 8Chan? > What is a "hate site" and who gets to decide what constitutes a "hate site"? These are the most dangerous questions of our time, because once we begin sliding down the slippery slope of unbounded, subjectively-determined censorship, we may find that we don't agree with what all is being censored. To make this point perhaps more saliently, the vast majority of regimes worldwide that engage or have engaged in censorship have done so primarily in order to quell dissent against their policies and leaders. We could implement a "great firewall" much like China has, but how long would it be before it was viewed as a useful political tool to silence opposition? Could you imagine one side determining that any content related to, perhaps, safe access to abortion, is counter to their ideal society and hence "too dangerous" to allow the citizenry to view? Could the other side then determine just as easily that content related to, say, gun rights is objectionable and dangerous, also? In my humble opinion, no one can or should be trusted with that sort of power, and that is why we have the first amendment in the US constitution. > I applaud cloudflare’s (perhaps slightly late) decision on kicking 8chan > off its platform today after El Paso attack. > https://blog.cloudflare.com/terminating-service-for-8chan/ > Cloudflare is a private entity and can host or not host whatever it wants, of course. > I am sure there are many sites like this out there, but could network > operators do anything to make these sites “not so easy” to be found, > reached, and used to end innocent lives? > Websites can't end innocent lives; only actions taken offline by their participants can do that. Having all of these sites online and as in-the-open as possible has a benefit of allowing law enforcement to monitor activity therein through legal means which allow for oversight and due process, US constitutional concepts which protect all of us from potential abuses of power. If we as operators wish to help prevent crimes and violence, then we should foster good relationships with law enforcement, and inform them of anything that we notice which may be related to the commission of or threats of violence. They can then follow prescribed paths which protect everyone involved to determine whether enforcement action is necessary/possible without violating anyones' rights. I'm not claiming the system is perfect, of course, but I don't think anyone's going to do a whole lot better. There is no perfect system. Bad people can and will still do bad things. The best that we each can do is to be aware of our surroundings at all times both online and off, and protect ourselves, our families, our homes, and our communities. - Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Mon Aug 5 16:02:06 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 5 Aug 2019 16:02:06 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org>, Message-ID: <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> Patrick, You’re confusing the FCC’s definition of common carrier for telecom regulatory purposes, and the DMCA definition, which specifically grants ISPs protection from litigation through its Safe Harbor provision, as long as they operate as pure common carriers: “Section 512(a) provides a safe harbor from liability for ISPs, provided that they operate their networks within certain statutory bounds, generally requiring the transmission of third-party information without interference, modification, storage, or selection. [emphasis mine] http://jolt.law.harvard.edu/articles/pdf/v27/27HarvJLTech257.pdf -mel On Aug 5, 2019, at 8:43 AM, Patrick W. Gilmore > wrote: Mel: My understanding is ISPs are not Common Carriers. Didn’t we just have a big debate about this w/r/t Network Neutrality? I Am Not A Lawyer (hell, I am not even an ISP :), but if any legal experts want to chime in, please feel free to educate us. Put another way, ISPs are not phone companies. Moreover, ISPs - and CDNs and hosting providers and etc. - can have terms of service which do not allow certain types of content on their platform. Again, that is is my understanding. Happy to be educated by someone who specializes in this type of law. I know there are a couple such people on NANOG-l. -- TTFN, patrick P.S. Interesting choice equating a group founded on the principals that “Nazis are bad” and a group espousing Nazi ideas. But that’s very off-topic, so if you want to discuss, please do so directly. On Aug 5, 2019, at 11:13 AM, Mel Beckman > wrote: Mehmet, I’m not sure if you understand the terms under which ISPs operate as “common carriers”, and thus enjoy immunity from lawsuits due to the acts of their customers. ISPs such as Cloudfare can no more disconnect customers for legal, if offensive, content than the phone company can, without losing that common carrier status. Cloudfare is being foolish, and hypocritical. They freely, for example, carry the equally offensive content of Antifa. Are they going to cut them off too? In America we have the right to free speech, and the right to use common carriers to carry that speech. If a common carrier chooses to censor legal speech, which is what Cloudfare has done, then it loses its CC status and can now be sued for that speech. -mel beckman On Aug 5, 2019, at 8:06 AM, Keith Medcalf > wrote: On Sunday, 4 August, 2019 21:41, Mehmet Akcin > wrote: Most of us who operate internet services believe in not being the moderator of internet. We provide a service and that’s it. Obviously there are some established laws around protecting copyrights, and other things which force us to legally take action and turn things down when reported. What can we do better as network operators about hate sites like 8Chan? I applaud cloudflare’s (perhaps slightly late) decision on kicking 8chan off its platform today after El Paso attack. https://blog.cloudflare.com/terminating-service-for-8chan/ I am sure there are many sites like this out there, but could network operators do anything to make these sites “not so easy” to be found, reached, and used to end innocent lives? I do not quite understand this. In days of yore, nutters used to send their screeds to Newspapers, TV and Radio stations. Did you shut them down or move them to frequencies that could not be received with COTS TVs and Radios? Did you ban the newspapers, put them out of business, or make it so their broadsheet was only available by travelling by aeroplane for 8 hours before breakfast? Of course not, you silly duck! There is an advantage to having all the nutters congregating on one place -- you know exactly where to find them. Granted, the advantage is not exactly the same as we apply to politicians (or lawyers) who are kepts all in one place so that kinetic weapons can dispatch the whole lot at one go if necessary. However, your solution of sweeping things you do not like under the rug is ill-conceived if not brain-dead in conception and you must not be permitted to carry out your objectives. The fate of the free world depends on it. However, do not worry. US AG William Barr is doing a fine job deploying his "backdoors". Why just the other day one of them was used to shut down the Georgia State Public Safety Services, and prior to that his "backdoors" were used to shut down several city computer systems in Florida and even the City of Baltimore. Good work with those backdoors, Mr. Barr. Job well done! It is nincompoops who do not think about what they are doing that create such a bloody mess of things. They should let the adults take care of it. Now, enough of this off-topic stuff and back to our regularly scheduled programming. -- 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 Bryan at bryanfields.net Mon Aug 5 16:24:55 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Mon, 5 Aug 2019 12:24:55 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: <8e6e78a2-a46b-754d-d5c2-52a126d10769@bryanfields.net> On 8/4/19 11:41 PM, Mehmet Akcin wrote: > What can we do better as network operators about hate sites like 8Chan? I actually went and looked at 8chan, it would appear to me they have a bunch of hate filled people there, 10 yr olds who think saying the n-word makes them cool, and then other bland users. > I applaud cloudflare’s (perhaps slightly late) decision on kicking 8chan > off its platform today after El Paso attack. > https://blog.cloudflare.com/terminating-service-for-8chan/ I'd be more concerned with the lack of notice given to their customer. This was 24 hours notice, and I'd expect at least 30 days under any hosting contract. This scares the shit out of me as a customer; could cloudflare decide to give me no notice and shut my services off? Once you make the point that you're willing to play that game, how can you be trusted as a provider? > I am sure there are many sites like this out there, but could network > operators do anything to make these sites “not so easy” to be found, > reached, and used to end innocent lives? These atrocities were committed by people willing to die for their cause, how ever sick and fucked up it is. There's little anyone can do against this sort of actor, and it is why it's so terrifying. I certainly don't have a solution to it, but can say censorship is not the answer. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From amitchell at isipp.com Mon Aug 5 16:28:38 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Mon, 5 Aug 2019 10:28:38 -0600 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> Message-ID: <2AF0A91D-F703-4453-85A4-618BA3E992C1@isipp.com> > I’m not sure if you understand the terms under which ISPs operate as “common carriers”, and thus enjoy immunity from lawsuits due to the acts of their customers. ISPs such as Cloudfare can no more disconnect customers for legal, if offensive, content than the phone company can, without losing that common carrier status. > > Cloudfare is being foolish, and hypocritical. They freely, for example, carry the equally offensive content of Antifa. Are they going to cut them off too? > > In America we have the right to free speech, and the right to use common carriers to carry that speech. If a common carrier chooses to censor legal speech, which is what Cloudfare has done, then it loses its CC status and can now be sued for that speech. > > -mel beckman ISPs are not common carriers, and, in fact, they have the right to carry - or to not carry - whatever traffic they choose. In fact, for some aspects of Internet traffic, ISP immunity is specifically written into the law (cf. CAN-SPAM §8(c) which states that "(c) No EFFECT ON POLICIES OF PROVIDERS OF INTERNET ACCESS SERVICE.--Nothing in this Act shall be construed to have any effecton the lawfulness or unlawfulness, under any other provision of law, of the adoption, implementation, or enforcement by a provider of Internet access service of a policy of declining to transmit, route,relay, handle, or store certain types of electronic mail messages."). Anne P. Mitchell, Attorney at Law CEO/President, Institute for Social Internet Public Policy Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS) Member: California Bar Association From Bryan at bryanfields.net Mon Aug 5 16:30:23 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Mon, 5 Aug 2019 12:30:23 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: <83bf80ab-967b-3a65-a674-47cf94610164@bryanfields.net> On 8/5/19 11:15 AM, Mel Beckman wrote: > Keith, what could be more on-topic than an ISP’s status as a common > carrier? Seems pretty operational to me. Mel gets to decide what's on topic and off topic for the nanog list? :D -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From ross at tajvar.io Mon Aug 5 16:32:46 2019 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 5 Aug 2019 12:32:46 -0400 Subject: Best ways to ensure redundancy with no terrestrial ISPs In-Reply-To: References: Message-ID: Hi Eric, thanks for this info. Very helpful. Mark/everyone, this is in Morocco specifically. I haven't been given the exact location but I'm told it's near Dahkla. On Sat, Aug 3, 2019, 9:36 PM Eric Kuhnke wrote: > In a remote area in northern africa if there are no terrestrial ISPs, and > there is no budget to build towers for PTP microwave, I don't know if there > are any reasonable options. > > If sufficient funds did exist, my recommendation, if they really want true > diversity between two totally different services, would be a combination of > a MEO o3b earth station and a traditional geostationary type earth station > (Ku band) with appropriate RF chain and SCPC modem. > > It is also possible to achieve full diversity through two totally separate > geostationary earth stations, using different satellite transponders and > different teleports on the other end. > > But that's not going to be cheap, either in a one time equipment cost or > in monthly recurring cost, for o3b services and transponder kHz lease + > teleport services on the other end somewhere in continental Europe. > > On Sat, Aug 3, 2019 at 2:10 PM Ross Tajvar wrote: > >> On Sat, Aug 3, 2019 at 4:30 PM Brian Henson wrote: >> >>> If we had a location (or at least a part of the world) we might be able >>> to recommend a little better. >>> >> >> This is in northern Africa. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruns at 2mbit.com Mon Aug 5 16:36:53 2019 From: bruns at 2mbit.com (Brielle) Date: Mon, 5 Aug 2019 10:36:53 -0600 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <8e6e78a2-a46b-754d-d5c2-52a126d10769@bryanfields.net> References: <8e6e78a2-a46b-754d-d5c2-52a126d10769@bryanfields.net> Message-ID: On 8/5/2019 10:24 AM, Bryan Fields wrote: > I'd be more concerned with the lack of notice given to their customer. This > was 24 hours notice, and I'd expect at least 30 days under any hosting > contract. This scares the shit out of me as a customer; could cloudflare > decide to give me no notice and shut my services off? If they were a paying customer... sure, maybe 30 days. However, if they're a paying customer, their agreement likely gives cloudflare an out under some situations. If they aren't a paying customers, then you give them the amount of time in relation to how much they are paying. In this case, if they are paying $0, then I think giving them until Midnight was being overly generous. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From amitchell at isipp.com Mon Aug 5 16:41:00 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Mon, 5 Aug 2019 10:41:00 -0600 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> Message-ID: <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> > On Aug 5, 2019, at 10:02 AM, Mel Beckman wrote: > > Patrick, > > You’re confusing the FCC’s definition of common carrier for telecom regulatory purposes, and the DMCA definition, which specifically grants ISPs protection from litigation through its Safe Harbor provision, as long as they operate as pure common carriers: > > “Section 512(a) provides a safe harbor from liability for ISPs, provided that they operate their networks within certain statutory bounds, generally requiring the transmission of third-party information without interference, modification, storage, or selection. [emphasis mine] > > http://jolt.law.harvard.edu/articles/pdf/v27/27HarvJLTech257.pdf > > -mel Section 512(a) applies very specifically to the copyright infringement issue as addressed in the DMCA. While I don't disagree that this law school paper, written while Lovejoy was a law student, in 2013, could be read as if ISPs were common carriers, they are not, and were not. Even if it were headed that way, actions by the current FTC and administration rolled back net neutrality efforts in 2017, four years after this student paper was published. All that said, this is very arcane stuff, and ever-mutating, so it's not at all difficult to see why reasonable people can differ about the meanings of various things out there. Anne Anne P. Mitchell, Attorney at Law CEO/President, Institute for Social Internet Public Policy Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS) Member: California Bar Association From egon at egon.cc Mon Aug 5 16:51:02 2019 From: egon at egon.cc (James Downs) Date: Mon, 5 Aug 2019 09:51:02 -0700 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <8e6e78a2-a46b-754d-d5c2-52a126d10769@bryanfields.net> References: <8e6e78a2-a46b-754d-d5c2-52a126d10769@bryanfields.net> Message-ID: <20190805165053.GJ19852@nemesis.egontech.com> On Mon, Aug 05, 2019 at 12:24:55PM -0400, Bryan Fields wrote: > contract. This scares the shit out of me as a customer; could cloudflare > decide to give me no notice and shut my services off? So much for the "free-speech absolutist". From mike at mtcc.com Mon Aug 5 16:57:08 2019 From: mike at mtcc.com (Michael Thomas) Date: Mon, 5 Aug 2019 09:57:08 -0700 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <8e6e78a2-a46b-754d-d5c2-52a126d10769@bryanfields.net> References: <8e6e78a2-a46b-754d-d5c2-52a126d10769@bryanfields.net> Message-ID: On 8/5/19 9:24 AM, Bryan Fields wrote: > On 8/4/19 11:41 PM, Mehmet Akcin wrote: >> What can we do better as network operators about hate sites like 8Chan? > I actually went and looked at 8chan, it would appear to me they have a bunch > of hate filled people there, 10 yr olds who think saying the n-word makes them > cool, and then other bland users. > >> I applaud cloudflare’s (perhaps slightly late) decision on kicking 8chan >> off its platform today after El Paso attack. >> https://blog.cloudflare.com/terminating-service-for-8chan/ > I'd be more concerned with the lack of notice given to their customer. This > was 24 hours notice, and I'd expect at least 30 days under any hosting > contract. This scares the shit out of me as a customer; could cloudflare > decide to give me no notice and shut my services off? > Well, we don't know what led up to this. Like do we know they weren't on notice? Mike From bill at herrin.us Mon Aug 5 17:05:43 2019 From: bill at herrin.us (William Herrin) Date: Mon, 5 Aug 2019 10:05:43 -0700 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: On Sun, Aug 4, 2019 at 8:41 PM Mehmet Akcin wrote: > Ok, two mass shootings, touchy topic, lots of emotions this weekend. Going > straight to the point. > > Most of us who operate internet services believe in not being the > moderator of internet. We provide a service and that’s it. Obviously there > are some established laws around protecting copyrights, and other things > which force us to legally take action and turn things down when reported. > > What can we do better as network operators about hate sites like 8Chan? > De-anonymize them. Let them say what they'll say and defend their right to say it but don't let them hide behind your name. Promise that when the police come knocking and it appears to you to be a hate speech site, your privacy policy is: none whatsoever. The best cure for speech is more speech. The President notwithstanding, hateful behavior has a hard time surviving the light of day. You shouldn't be the censor but you can shine the light. (Also, as a practical matter the further you force folks to the fringe, the harder they are to track and thereby stop. Letting folks know you object by terminating their service does them more of a favor than cooperating with law enforcement.) Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Mon Aug 5 17:46:12 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Mon, 5 Aug 2019 13:46:12 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> Message-ID: <23880.27492.578569.996929@gargle.gargle.HOWL> My first suggestion would be to include an indemnification clause in your contracts which includes liability for content, if you don't already have it (probably most do.) And a clause which indicates you (need lawyering for this) will seek expenses including but not limited to legal, judgements, reputational recovery (e.g., cost of producing press releases), etc, incurred by actions taken by customer. I've long had something like the latter regarding anyone using our facilities to spam and I have billed spammers, and have collected some of those bills. I don't do this punitively. I really like to be paid for our time and services! Their behavior doesn't give them free access to our time even in the form of responding to emails ("above and beyond normal") or phone calls etc regarding their behavior. I also included a clause that allows me to require an immediate deposit if the outstanding bill rises above (pick a number) and failure to provide that deposit or work out an arrangement is grounds for suspension of services. That allows for nearly immediate action rather than putting it into a 30 day billing cycle. But the real power of generating that sort of bill is if they won't or don't pay ok then they've been shut off not for their content etc but for non-payment have a nice day. And if they pay, ok. As I said I have been paid generally with a promise to moderate their behavior, usually involving too-aggressive email advertising causing a lot of complaints. Perhaps not spamming in spirit but if we come in to 100+ complaints which need to be responded to I ain't payin' for that! But beyond their right to express themselves, which I'm ok with, they need to be financially responsible for their costs. Free speech is not necessarily "free" as in beer. -- -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 gtaylor at tnetconsulting.net Mon Aug 5 17:55:31 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 5 Aug 2019 11:55:31 -0600 Subject: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis In-Reply-To: <03701d21-f581-fc84-4779-bb16020e2078@n3network.ch> References: <53b7b43a-316d-0a62-e247-b78beca196d1@netravnen.de> <1035588386.903366.1564947649242@mail.yahoo.com> <03701d21-f581-fc84-4779-bb16020e2078@n3network.ch> Message-ID: <323637d7-9fec-5f40-4c60-7204084704f9@spamtrap.tnetconsulting.net> On 8/5/19 9:19 AM, Nicolas Chabbey wrote: > Are there any good reasons of using proprietary FHRPs like HSRP and > GLBP over VRRP ? I thought that GLBP had functionality that allowed both participants to be active/active. I.e. you could cause ⅔ of traffic to go to one GLBP peer and the remaining ⅓ go to the other GLBP peer. It's my understanding that neither HSRP nor VRRP support this active/active operation and that they are purely active/passive. Sure, you can have multiple HSRP / VRRP IPs and spread the load via client configuration. But that's outside of the scope of the protocols themselves. Please correct me if I'm wrong. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From amitchell at isipp.com Mon Aug 5 17:56:13 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Mon, 5 Aug 2019 11:56:13 -0600 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <23880.27492.578569.996929@gargle.gargle.HOWL> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <23880.27492.578569.996929@gargle.gargle.HOWL> Message-ID: <816F5638-304B-46FA-A9D4-E2D374BE87C7@isipp.com> > On Aug 5, 2019, at 11:46 AM, bzs at theworld.com wrote: > > My first suggestion would be to include an indemnification clause in > your contracts which includes liability for content, if you don't > already have it (probably most do.) > > And a clause which indicates you (need lawyering for this) will seek > expenses including but not limited to legal, judgements, reputational > recovery (e.g., cost of producing press releases), etc, incurred by > actions taken by customer. These are all excellent suggestions - and while we're on the subject of that sort of thing, *everyone* should have warrantees of GDPR compliance in any of their third-party contracts in which data can be touched, and *also* indemnification clauses in those same contracts if you are held responsible because those third-parties were breached, etc., and found to *not* be in compliance with GDPR (for which GDPR specifically provides - i.e. GDPR can go through the third-party contract and hold *you* liable). This is one of the ways that GDPR can seep in to get you even if you think you're safe because you're not in the EU. Anne --- Anne P. Mitchell, Attorney at Law CEO/President, Institute for Social Internet Public Policy Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS) Member: California Bar Association From mel at beckman.org Mon Aug 5 18:03:55 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 5 Aug 2019 18:03:55 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <83bf80ab-967b-3a65-a674-47cf94610164@bryanfields.net> References: <83bf80ab-967b-3a65-a674-47cf94610164@bryanfields.net> Message-ID: LOL! You mean instead of “Keith gets to decide what’s on topic”? I didn’t “decide” anything, BTW. I simply pointed out that Common Carrier operations is within the NANOG mandate to discuss operational issues. -mel > On Aug 5, 2019, at 9:30 AM, Bryan Fields wrote: > > On 8/5/19 11:15 AM, Mel Beckman wrote: >> Keith, what could be more on-topic than an ISP’s status as a common >> carrier? Seems pretty operational to me. > > Mel gets to decide what's on topic and off topic for the nanog list? > > :D > -- > Bryan Fields > > 727-409-1194 - Voice > http://bryanfields.net From mel at beckman.org Mon Aug 5 18:19:06 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 5 Aug 2019 18:19:06 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> Message-ID: Anne of Many Titles, I notice you didn’t provide any actual data to support your position. What, for example, outside of copyright violations, could ISPs conceivably be liable for? Present an argument to make your case. “No, because I’m a lawyer and you’re not” is not an argument :) As clearly stated in DMC 512(a), the safe harbor provision for transitory transport, which is what Cloudfare provides, "protects service providers who are passive conduits from liability for copyright infringement, even if infringing traffic passes through their networks. In other words, provided the infringing material is being transmitted at the request of a third party to a designated recipient, is handled by an automated process without human intervention, is not modified in any way, and is only temporarily stored on the system, the service provider is not liable for the transmission.” That’s not a law school student opinion. That’s the law itself. As I previously said, I’m not talking about the FCC definition of CC. Under DMCA, "service providers who are passive conduits” are the essence of the common law definition of Common Carrier (https://en.wikipedia.org/wiki/Common_carrier). Incidentally, Network Neutrality wasn’t enacted until 2015, and classified ISPs as FCC CCs purely to bring them under regulation by the FCC. DMCA was passed in 1998, and Safe Harbor is based on the fact that ISPs are “passive conduits". NN has nothing to do with the common carrier aspect of ISPs as "service providers who are passive conduits”. -mel On Aug 5, 2019, at 9:41 AM, Anne P. Mitchell, Esq. > wrote: On Aug 5, 2019, at 10:02 AM, Mel Beckman > wrote: Patrick, You’re confusing the FCC’s definition of common carrier for telecom regulatory purposes, and the DMCA definition, which specifically grants ISPs protection from litigation through its Safe Harbor provision, as long as they operate as pure common carriers: “Section 512(a) provides a safe harbor from liability for ISPs, provided that they operate their networks within certain statutory bounds, generally requiring the transmission of third-party information without interference, modification, storage, or selection. [emphasis mine] http://jolt.law.harvard.edu/articles/pdf/v27/27HarvJLTech257.pdf -mel Section 512(a) applies very specifically to the copyright infringement issue as addressed in the DMCA. While I don't disagree that this law school paper, written while Lovejoy was a law student, in 2013, could be read as if ISPs were common carriers, they are not, and were not. Even if it were headed that way, actions by the current FTC and administration rolled back net neutrality efforts in 2017, four years after this student paper was published. All that said, this is very arcane stuff, and ever-mutating, so it's not at all difficult to see why reasonable people can differ about the meanings of various things out there. Anne Anne P. Mitchell, Attorney at Law CEO/President, Institute for Social Internet Public Policy Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS) Member: California Bar Association -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Mon Aug 5 18:20:34 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 5 Aug 2019 18:20:34 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: The best cure for speech is more speech. +1E07 On Aug 5, 2019, at 10:05 AM, William Herrin > wrote: On Sun, Aug 4, 2019 at 8:41 PM Mehmet Akcin > wrote: Ok, two mass shootings, touchy topic, lots of emotions this weekend. Going straight to the point. Most of us who operate internet services believe in not being the moderator of internet. We provide a service and that’s it. Obviously there are some established laws around protecting copyrights, and other things which force us to legally take action and turn things down when reported. What can we do better as network operators about hate sites like 8Chan? De-anonymize them. Let them say what they'll say and defend their right to say it but don't let them hide behind your name. Promise that when the police come knocking and it appears to you to be a hate speech site, your privacy policy is: none whatsoever. The best cure for speech is more speech. The President notwithstanding, hateful behavior has a hard time surviving the light of day. You shouldn't be the censor but you can shine the light. (Also, as a practical matter the further you force folks to the fringe, the harder they are to track and thereby stop. Letting folks know you object by terminating their service does them more of a favor than cooperating with law enforcement.) Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Mon Aug 5 18:24:31 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 05 Aug 2019 12:24:31 -0600 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <8e6e78a2-a46b-754d-d5c2-52a126d10769@bryanfields.net> Message-ID: On Monday, 5 August, 2019 10:25, Bryan Fields wrote: >I'd be more concerned with the lack of notice given to their >customer. This was 24 hours notice, and I'd expect at least >30 days under any hosting contract. This scares the shit >out of me as a customer; could cloudflare decide to give me >no notice and shut my services off? Yes. This is in Cloudflare's Terms of Service. You pay them and they provide services. They may decide to terminate those services at any time, without any prior notice whatsoever, and keep your money. You agree to this when you contract with them. So I would suppose that this just means that you would not do business with Cloudflare. That is your right. If you do not like the contract provisions you are free not to contract with them. If you do not mind that they may decide at any point in time for any reason or no reason at all to terminate your services and stop providing the service for which you have paid in advance (and without refund), then you are free to do so. As always, the choice is yours. No one compels you to do business with Cloudflare. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From amitchell at isipp.com Mon Aug 5 18:28:32 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Mon, 5 Aug 2019 12:28:32 -0600 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> Message-ID: Mel, this is to ack your note. "Because I'm a lawyer" isn't an argument at all, *nor have I made it* - however, that I'm extremely busy, and under no obligation to provide any of this information here, is. I'm not here for academic debate. You are also free to bring a lawsuit based on ISP as common carrier, but you will lose. Anne > On Aug 5, 2019, at 12:19 PM, Mel Beckman wrote: > > Anne of Many Titles, > > I notice you didn’t provide any actual data to support your position. What, for example, outside of copyright violations, could ISPs conceivably be liable for? Present an argument to make your case. “No, because I’m a lawyer and you’re not” is not an argument :) > > As clearly stated in DMC 512(a), the safe harbor provision for transitory transport, which is what Cloudfare provides, > > "protects service providers who are passive conduits from liability for copyright infringement, even if infringing traffic passes through their networks. In other words, provided the infringing material is being transmitted at the request of a third party to a designated recipient, is handled by an automated process without human intervention, is not modified in any way, and is only temporarily stored on the system, the service provider is not liable for the transmission.” > > That’s not a law school student opinion. That’s the law itself. As I previously said, I’m not talking about the FCC definition of CC. Under DMCA, "service providers who are passive conduits” are the essence of the common law definition of Common Carrier (https://en.wikipedia.org/wiki/Common_carrier). > > Incidentally, Network Neutrality wasn’t enacted until 2015, and classified ISPs as FCC CCs purely to bring them under regulation by the FCC. DMCA was passed in 1998, and Safe Harbor is based on the fact that ISPs are “passive conduits". NN has nothing to do with the common carrier aspect of ISPs as "service providers who are passive conduits”. > > -mel > >> On Aug 5, 2019, at 9:41 AM, Anne P. Mitchell, Esq. wrote: >> >> >> >>> On Aug 5, 2019, at 10:02 AM, Mel Beckman wrote: >>> >>> Patrick, >>> >>> You’re confusing the FCC’s definition of common carrier for telecom regulatory purposes, and the DMCA definition, which specifically grants ISPs protection from litigation through its Safe Harbor provision, as long as they operate as pure common carriers: >>> >>> “Section 512(a) provides a safe harbor from liability for ISPs, provided that they operate their networks within certain statutory bounds, generally requiring the transmission of third-party information without interference, modification, storage, or selection. [emphasis mine] >>> >>> http://jolt.law.harvard.edu/articles/pdf/v27/27HarvJLTech257.pdf >>> >>> -mel >> >> Section 512(a) applies very specifically to the copyright infringement issue as addressed in the DMCA. While I don't disagree that this law school paper, written while Lovejoy was a law student, in 2013, could be read as if ISPs were common carriers, they are not, and were not. Even if it were headed that way, actions by the current FTC and administration rolled back net neutrality efforts in 2017, four years after this student paper was published. >> >> All that said, this is very arcane stuff, and ever-mutating, so it's not at all difficult to see why reasonable people can differ about the meanings of various things out there. >> >> Anne >> >> Anne P. Mitchell, Attorney at Law >> CEO/President, Institute for Social Internet Public Policy >> Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose >> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) >> Legislative Consultant >> GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant >> Board of Directors, Denver Internet Exchange >> Board of Directors, Asilomar Microcomputer Workshop >> Legal Counsel: The CyberGreen Institute >> Former Counsel: Mail Abuse Prevention System (MAPS) >> Member: California Bar Association >> >> >> > --- Anne P. Mitchell, Attorney at Law CEO/President, Institute for Social Internet Public Policy Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS) Member: California Bar Association From valdis.kletnieks at vt.edu Mon Aug 5 18:33:50 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Mon, 05 Aug 2019 14:33:50 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> Message-ID: <575639.1565030030@turing-police> On Mon, 05 Aug 2019 18:19:06 -0000, Mel Beckman said: > I notice you didn���t provide any actual data to support your position. What, > for example, outside of copyright violations, could ISPs conceivably be liable > for? You get caught with nuclear weapons data, terrorism-related info, or kiddie porn on your servers dropped there by a customer, you're going to be wishing for a safe harbor that extends further than just copyright. Whether you actually get one is going to depend on a *lot* of details of the specific incident. At that point, don't listen to me, and don't listen to Anne, hire a good lawyer who knows exactly what the rules are in your jurisdiction(s) and listen to them :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From nchabbey at n3network.ch Mon Aug 5 18:38:41 2019 From: nchabbey at n3network.ch (Nicolas Chabbey) Date: Mon, 5 Aug 2019 20:38:41 +0200 Subject: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis In-Reply-To: <323637d7-9fec-5f40-4c60-7204084704f9@spamtrap.tnetconsulting.net> References: <53b7b43a-316d-0a62-e247-b78beca196d1@netravnen.de> <1035588386.903366.1564947649242@mail.yahoo.com> <03701d21-f581-fc84-4779-bb16020e2078@n3network.ch> <323637d7-9fec-5f40-4c60-7204084704f9@spamtrap.tnetconsulting.net> Message-ID: <0a030044-4449-847c-c2a0-a12716026511@n3network.ch> Good point. I forgot about this one. Apparently, you can have four active forwarders per group. The load is balanced across them via the virtual MAC addresses. I could implement something similar to my open VRRP implementation (I wrote about it on the ML recently), but only if it's a wanted features. I don't think it's overly complex to do, but of course it won't be covered by any current RFCs. Regards. On 05/08/2019 19:55, Grant Taylor via NANOG wrote: > On 8/5/19 9:19 AM, Nicolas Chabbey wrote: >> Are there any good reasons of using proprietary FHRPs like HSRP and >> GLBP over VRRP ? > > I thought that GLBP had functionality that allowed both participants to > be active/active.  I.e. you could cause ⅔ of traffic to go to one GLBP > peer and the remaining ⅓ go to the other GLBP peer. > > It's my understanding that neither HSRP nor VRRP support this > active/active operation and that they are purely active/passive. > > Sure, you can have multiple HSRP / VRRP IPs and spread the load via > client configuration.  But that's outside of the scope of the protocols > themselves. > > Please correct me if I'm wrong. > > > From samual at yakimanetworking.com Mon Aug 5 16:44:35 2019 From: samual at yakimanetworking.com (Samual Carman) Date: Mon, 5 Aug 2019 09:44:35 -0700 Subject: mitel hx5000 Message-ID: does anyone have any contacts at mitel that they can share or forward me onto of our sister company's took over a small customer who has a mitel hx5000 and we are having a devil of a time trying to get support from mitel as they want us to sign a long term maintenance contract which normally we would have no problem with however come end of september we will be migrating them to are in house platform and unfortunately none of the local vendors offer short term contracts and the sister company in quiston will not budge on the timeline so i am hoping the world of NANOG has the ability to connect me to someone in mitel who would be able to help us out mods if this breaks the rules please let me know i was unsure Thanks Sam Lead System Admin Yakima Networking -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.petzholtz at syseleven.de Mon Aug 5 19:17:10 2019 From: v.petzholtz at syseleven.de (Vincentz Petzholtz) Date: Mon, 5 Aug 2019 21:17:10 +0200 Subject: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis In-Reply-To: <323637d7-9fec-5f40-4c60-7204084704f9@spamtrap.tnetconsulting.net> References: <53b7b43a-316d-0a62-e247-b78beca196d1@netravnen.de> <1035588386.903366.1564947649242@mail.yahoo.com> <03701d21-f581-fc84-4779-bb16020e2078@n3network.ch> <323637d7-9fec-5f40-4c60-7204084704f9@spamtrap.tnetconsulting.net> Message-ID: <012FCD1D-DF73-4313-8EF3-81ADD5D93A5B@syseleven.de> > I thought that GLBP had functionality that allowed both participants to be active/active. I.e. you could cause ⅔ of traffic to go to one GLBP peer and the remaining ⅓ go to the other GLBP peer. Yes it’s true. It achieves forwarding active/active situations. One of the GLBP group members get elected „master“ (just like in HSRP/VRRP). This master also knowns the („virt“) interface MAC addresses of the other members within the same BC segment. If then a client arp’s for the GW/GLBP virtual IP then the master is basically spoofing the arp response with a mac of the other members. You have some sort of control of how the mac addresses of the other members are handed out by the master. This leads to a „static“ client assignment style of load balancing (because you can’t really know how much traffic this one client then generates/gets). And as far as I remember: If a member fails then another one is taking over responsibility over the used mac address. It surprised me a little bit that this never really taken off (not even within Cisco folks in the enterprise field as far as I know). I was also keen if/when this ever get available on other vendors and/or open source software. Just as everybody else we do run two VRRP instances with ECMP style routes on datacenter gear a lot. But in some situations it would be nice to have something to spread the traffic across different routers (even when the client is too „dump“ for ecmp routes). Best regards, Vincentz > Am 05.08.2019 um 19:55 schrieb Grant Taylor via NANOG : > > On 8/5/19 9:19 AM, Nicolas Chabbey wrote: >> Are there any good reasons of using proprietary FHRPs like HSRP and GLBP over VRRP ? > > I thought that GLBP had functionality that allowed both participants to be active/active. I.e. you could cause ⅔ of traffic to go to one GLBP peer and the remaining ⅓ go to the other GLBP peer. > > It's my understanding that neither HSRP nor VRRP support this active/active operation and that they are purely active/passive. > > Sure, you can have multiple HSRP / VRRP IPs and spread the load via client configuration. But that's outside of the scope of the protocols themselves. > > Please correct me if I'm wrong. > > > > -- > Grant. . . . > unix || die > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From sethm at rollernet.us Mon Aug 5 19:17:17 2019 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 5 Aug 2019 12:17:17 -0700 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: On 8/5/19 10:05 AM, William Herrin wrote: > The best cure for speech is more speech. The President notwithstanding, > hateful behavior has a hard time surviving the light of day. You > shouldn't be the censor but you can shine the light. That doesn't seem to work on Facebook, where people spew the most vile things under the banner of their own name. From patrick at ianai.net Mon Aug 5 19:41:16 2019 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 5 Aug 2019 15:41:16 -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> <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> <2d008a95-b5c9-4d9c-aed0-c040f5bca164@www.fastmail.com> Message-ID: <5B645B95-6588-4141-A3C1-CB7BE201B916@ianai.net> [Speaking ONLY FOR MYSELF AS AN INDIVIDUAL.] On Aug 4, 2019, at 8:15 AM, Rubens Kuhl wrote: > On Sun, Aug 4, 2019 at 5:17 AM Scott Christopher wrote: > John Curran wrote: > > ... > >> As I have noted previously, I have zero doubt in the enforceability of the ARIN registration services agreements in this regard – so please carefully consider proposed policy both from the overall community benefit being sought, and from the implications faced as a number resource holder having to comply oneself with the new obligations. > > I completely agree that ARIN can revoke an organization's resources. Nobody has ever doubted that. > > What I have been saying is that if ARIN revoked Amazon's resources because of a trivial matter of bounced Abuse PoC, even if the small "community" of network operators and other interested parties passed a rule supporting this, the backlash would be *enormous* and lead to media attention, litigation, police, investigation by U.S. Congress, etc. > > The interests of the public affected by a global Amazon/AWS outage would greatly outweigh the rights of this small "community" which would ultimately be stripped away, I'd think. > > This is moot, of course, because ARIN would give ample notices and time to Amazon and they would dutifully comply. But the original poster to which I replied invited us to imagine such a situation. > > > > I don't think that "companies with tons of lawyers" should be a factor in making resource allocation policies. But considering either small or big networks, an escalation path would reduce friction and increase overall compliance... for instance, failure to have functioning abuse PoC could lead first to being inegible to receive new resources. I would love for “companies with tons of lawyers” to be irrelevant to policy creation and implementation. However, ARIN has to exist to enforce policy and support the community. If there is an existential threat to the corporation, e.g. legal risks, that must be taken into account. To be clear, this does not mean a company with lots of lawyers should be allowed to direct policy. ARIN’s policies should and do come from the communities and their elected representatives (the AC). But to say that ARIN should not consider the legal implications goes a bit too far, IMHO. [Reminder: Speaking ONLY FOR MYSELF AS AN INDIVIDUAL.] -- TTFN, patrick From mel at beckman.org Mon Aug 5 20:19:49 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 5 Aug 2019 20:19:49 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: , Message-ID: Keith, You’re confusing ISPs that merely provide transport services, such as AT&T and Cloudfare, with information services like FaceBook and Twitter. The Common Carrier status for legal protection of ISPs stems from the 1998 DMCA, which long preceded the 2015 Network Neutrality act. It provides protection only for an ISP that as a “provider merely acts as a data conduit, transmitting digital information from one point on a network to another at someone else’s request.” The ISP loses that Common Carrier (in the Common Law definition) protection if it alters the transmission in any way. Just because an ISP isn’t a Common Carrier under FCC rules doesn’t mean that it isn’t a Common Carrier for other purposes. Trains and planes, for example, are Common Carriers, and the FCC has nothing to do with them. But they can’t exclude passengers based on their speech (yet, anyway). -mel > On Aug 5, 2019, at 8:54 AM, Keith Medcalf wrote: > > >> On Monday, 5 August, 2019 09:16, Mel Beckman wrote: >> >> “Now, enough of this off-topic stuff and back to our regularly >> scheduled programming.” > >> Keith, what could be more on-topic than an ISP’s status as a common >> carrier? Seems pretty operational to me. > > I think that is closing the barn door after the horse already left. > > It is my understanding that in your fabulous United States of America that "carriers" (meaning having no content serving nor content consuming customers*) may be "common carriers" or can claim to be common carriers. The rest of you who are not pure carriers are, thanks to Ijit Pai, merely Information Services and do not have common carrier status, nor can you claim to be common carriers. > > A "common carrier" is one who must provide carriage provided the fee for carriage is paid. This is not the case for "Information Service" providers as they are not required to provide carriage to any who can pay the fee for carriage. > > *I hate the term "content", it is somowhat lame. > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. > > > > From patrick at ianai.net Mon Aug 5 20:34:13 2019 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 5 Aug 2019 16:34:13 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: Cloudflare is not an ISP. They are a CDN. You cannot ask them for a DSL or Cable connection, or even DIA. Not that it matters: ISPs are not “Common Carriers” in statute or Common Law. The DMCA provides some protections which are similar to Common Carrier status, but that does not mean they have all the rights and responsibilities of Common Carriers. And just to be really meta, that doesn’t matter either. Cloudflare did nothing wrong. While in the US, anyone can sue anyone for anything, the idea 8Chan will prevail in suing Cloudflare for violation of Common Carrier responsibilities, or even for 1st amendment free speech rights, it ludicrous on its face. I am not terribly pleased with CF’s continued support of miscreants like “Booter Services” (read “DDoS-for-Hire”), but their lawyers are not idiots. And while you may not believe Anne, I know her and trust her judgement here. Plus I know a small amount about running CDNs. So I’m going to go with the consensus on the side of “not Common Carriers”. Feel free to disagree. But if you plan to convince the people reading this thread, you will have to do better than quoting snippets of the DMCA. -- TTFN, patrick > On Aug 5, 2019, at 4:19 PM, Mel Beckman wrote: > > Keith, > > You’re confusing ISPs that merely provide transport services, such as AT&T and Cloudfare, with information services like FaceBook and Twitter. The Common Carrier status for legal protection of ISPs stems from the 1998 DMCA, which long preceded the 2015 Network Neutrality act. It provides protection only for an ISP that as a “provider merely acts as a data conduit, transmitting digital information from one point on a network to another at someone else’s request.” The ISP loses that Common Carrier (in the Common Law definition) protection if it alters the transmission in any way. > > Just because an ISP isn’t a Common Carrier under FCC rules doesn’t mean that it isn’t a Common Carrier for other purposes. Trains and planes, for example, are Common Carriers, and the FCC has nothing to do with them. But they can’t exclude passengers based on their speech (yet, anyway). > > -mel > >> On Aug 5, 2019, at 8:54 AM, Keith Medcalf wrote: >> >> >>> On Monday, 5 August, 2019 09:16, Mel Beckman wrote: >>> >>> “Now, enough of this off-topic stuff and back to our regularly >>> scheduled programming.” >> >>> Keith, what could be more on-topic than an ISP’s status as a common >>> carrier? Seems pretty operational to me. >> >> I think that is closing the barn door after the horse already left. >> >> It is my understanding that in your fabulous United States of America that "carriers" (meaning having no content serving nor content consuming customers*) may be "common carriers" or can claim to be common carriers. The rest of you who are not pure carriers are, thanks to Ijit Pai, merely Information Services and do not have common carrier status, nor can you claim to be common carriers. >> >> A "common carrier" is one who must provide carriage provided the fee for carriage is paid. This is not the case for "Information Service" providers as they are not required to provide carriage to any who can pay the fee for carriage. >> >> *I hate the term "content", it is somowhat lame. >> >> -- >> 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 mel at beckman.org Mon Aug 5 20:40:43 2019 From: mel at beckman.org (Mel Beckman) Date: Mon, 5 Aug 2019 20:40:43 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <575639.1565030030@turing-police> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> , <575639.1565030030@turing-police> Message-ID: <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> Valdis, The key misunderstanding on your part is the phrase “on your servers”. ISPs acting as conduits do not, by definition (in the DMCA), store anything on servers. Moreover, the DMCA specifically spells out that safe harbor protection “covers acts of transmission, routing, or providing connections for the information, as well as the intermediate and transient copies that are made automatically in the operation of a network.” And if the FBI, or whoever, through various technical means, managed to discover that illegal information passed through an ISPs network, they have no more cause of action than if that traffic passed through AT&T leased lines. Not that they haven’t tried. -mel On Aug 5, 2019, at 11:34 AM, Valdis Klētnieks > wrote: On Mon, 05 Aug 2019 18:19:06 -0000, Mel Beckman said: I notice you didn’t provide any actual data to support your position. What, for example, outside of copyright violations, could ISPs conceivably be liable for? You get caught with nuclear weapons data, terrorism-related info, or kiddie porn on your servers dropped there by a customer, you're going to be wishing for a safe harbor that extends further than just copyright. Whether you actually get one is going to depend on a *lot* of details of the specific incident. At that point, don't listen to me, and don't listen to Anne, hire a good lawyer who knows exactly what the rules are in your jurisdiction(s) and listen to them :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Mon Aug 5 20:57:50 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Mon, 5 Aug 2019 16:57:50 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: Message-ID: <23880.38990.232759.103080@gargle.gargle.HOWL> One tiny bit of sermonizing not aimed at anyone in particular: Interested amateurs tend to study the wording of laws. Lawyers tend to study case law, actual cases and their outcomes. In part that's because, besides the hazards of interpretation, laws often conflict, supercede each other, modify each other, have unexpressed limits particularly regarding jurisdiction and other matters of process and applicability, etc etc etc and that all tends to come out and get defined in the case law. And case law tends to be dispositive, /stare decisis/ and all that, precedents. And if that paragraph bored the crap out of you then good luck guessing at what a few thousand pages of case law on a topic will do to you. TBH some of this is like watching someone try to set up a router using only the marketing brochures. -- -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 Bryan at bryanfields.net Mon Aug 5 21:12:01 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Mon, 5 Aug 2019 17:12:01 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <23880.38990.232759.103080@gargle.gargle.HOWL> References: <23880.38990.232759.103080@gargle.gargle.HOWL> Message-ID: <35691305-0967-3bd4-54a0-c73a89c067a9@bryanfields.net> On 8/5/19 4:57 PM, bzs at theworld.com wrote: > TBH some of this is like watching someone try to set up a router using > only the marketing brochures. Hey, I got my Network+ too. dafuq is a "BGP"?.... -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From kmedcalf at dessus.com Mon Aug 5 22:26:44 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 05 Aug 2019 16:26:44 -0600 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <35691305-0967-3bd4-54a0-c73a89c067a9@bryanfields.net> Message-ID: <4a3c8a427406694283d9c28aea340671@mail.dessus.com> >Hey, I got my Network+ too. dafuq is a "BGP"?.... That's what the British get after too much Beer-o-clock. A Bloody-Good-Puking ... -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From valdis.kletnieks at vt.edu Mon Aug 5 23:02:06 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Mon, 05 Aug 2019 19:02:06 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> , <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> Message-ID: <591177.1565046126@turing-police> On Mon, 05 Aug 2019 20:40:43 -0000, Mel Beckman said: > The key misunderstanding on your part is the phrase ���on your servers���. ISPs > acting as conduits do not, by definition (in the DMCA), store anything on > servers. Note that ISPs whose business is 100% "acting as conduits" are in the minority. Hint: The DMCA has the text about data stored on ISP servers because many ISPs aren't mere conduits. And this thread got started regarding a CDN, which is very much all about storing data on servers..... -------------- 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 Mon Aug 5 23:05:08 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Tue, 6 Aug 2019 01:05:08 +0200 Subject: MAP-E In-Reply-To: References: Message-ID: On 2/Aug/19 14:17, Baldur Norddahl wrote: > > > The pricing on IPv4 is now at USD 20/address so I am thinking we are > forced to go the CGN route going forward. Of all the options, MAP-E > appears to be the most elegant. Just add/remove some more headers on a > packet and route it as normal. No need to invest in anything as our > core routers can already do that. No worries about scale. Actually, I think NAT64/DNS64/464XLAT is the best option, because as more IPv4 falls away, you are automatically translating less and going native IPv6 more. And there is nothing for you to "turn off" or migrate away from after all is said & done. Mark. From marka at isc.org Mon Aug 5 23:22:04 2019 From: marka at isc.org (Mark Andrews) Date: Tue, 6 Aug 2019 09:22:04 +1000 Subject: MAP-E In-Reply-To: References: Message-ID: > On 6 Aug 2019, at 9:05 am, Mark Tinka wrote: > > > > On 2/Aug/19 14:17, Baldur Norddahl wrote: > >> >> >> The pricing on IPv4 is now at USD 20/address so I am thinking we are >> forced to go the CGN route going forward. Of all the options, MAP-E >> appears to be the most elegant. Just add/remove some more headers on a >> packet and route it as normal. No need to invest in anything as our >> core routers can already do that. No worries about scale. > > Actually, I think NAT64/DNS64/464XLAT is the best option, because as > more IPv4 falls away, you are automatically translating less and going > native IPv6 more. And there is nothing for you to "turn off" or migrate > away from after all is said & done. > > Mark. Which only applies to DNS64 and not 464XLAT. That said, every IPv6 node should be attempting to connect over IPv6 first. That alone moves most of the traffic to IPv6 regardless of the IPv4aaS method in use. DNS64 also breaks DNSSEC which is not a good thing. DNS64 alone also depends on *everybody* having good (complete) IPv6 connectivity and not leaving IPv6 breakages uncorrected. There is no fallback to IPv4 with DNS64 alone. If you also have 464XLAT with DNS64 then there is NO DIFFERENCE to MAP-[ET] or DS-Lite in terms of traffic shifting to native IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mel at beckman.org Tue Aug 6 02:27:30 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 6 Aug 2019 02:27:30 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <591177.1565046126@turing-police> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> , <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org>, <591177.1565046126@turing-police> Message-ID: Valdis, A CDN is very much an ISP. It is providing transport for its customers from arbitrary Internet destinations, to the customer’s content. The caching done by a CDN is incidental to this transport, in accordance with the DMCA. The alternative is that you believe CDNs are not protected by safe Harbor. Is that the case? -mel via cell > On Aug 5, 2019, at 4:02 PM, Valdis Klētnieks wrote: > > On Mon, 05 Aug 2019 20:40:43 -0000, Mel Beckman said: >> The key misunderstanding on your part is the phrase “on your servers”. ISPs >> acting as conduits do not, by definition (in the DMCA), store anything on >> servers. > > Note that ISPs whose business is 100% "acting as conduits" are in the minority. > > Hint: The DMCA has the text about data stored on ISP servers because many ISPs > aren't mere conduits. And this thread got started regarding a CDN, which is very much > all about storing data on servers..... > From john at essenz.com Tue Aug 6 02:37:49 2019 From: john at essenz.com (John Von Essen) Date: Mon, 5 Aug 2019 22:37:49 -0400 Subject: Apple AS714 - peering down on the East Coast? Message-ID: <8CA2F804-DCEA-4750-AF1B-C08909D483B1@essenz.com> Starting around July 28th, I noticed a latency spike (70ms) on some of our traffic to Apple (mainly api.apple-mapkit.com) coming out of Virginia. This traffic usually always takes some local peering, and never is higher then 10-15ms. I checked from AWS backbone, Cogent, Zayo, Level3, all show 70+ ms from east coast. I also noticed on bgp.he.net, Apple’s IPv4 peer list dropped from 307 to 275 also on July 28-29th. Anyone else who peers with Apple on the east coast seeing this? Is it an outage or planned maintenance? Thanks John From valdis.kletnieks at vt.edu Tue Aug 6 03:14:47 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Mon, 05 Aug 2019 23:14:47 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> , <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org>, <591177.1565046126@turing-police> Message-ID: <604174.1565061287@turing-police> On Tue, 06 Aug 2019 02:27:30 -0000, Mel Beckman said: > A CDN is very much an ISP. It is providing transport for its customers from > arbitrary Internet destinations, to the customer���s content. The caching done by > a CDN is incidental to this transport, in accordance with the DMCA. Just because the DMCA says it's incidental doesn't mean that covers all bases. Go read up on the mess that covers warrants for e-mail contents - the rules are different for on-the-wire intercepts, mail that's in the queue and not delivered to a mailbox yet, mail that's been delivered to a mailbox and not read, and mail that's been read by the user and left in the mailbox, and mail that the user has read and downloaded to their personal computer. Anybody who thinks "DMCA says we have a safe harbor" is the be-all and end-all of it is in for a rude awakening. And if you have an NSL show up on your desk, you're in for a whole different world of hurt - even finding and hiring a lawyer can be a problem when you can't tell the lawyer you have an NSL problem until after you've hired them to help with your NSL problem. But I guarantee that if you tell the person handing you the NSL "DMCA says I have a safe harbor, get out of my office", your day will get even worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From gtaylor at tnetconsulting.net Tue Aug 6 03:20:51 2019 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Mon, 5 Aug 2019 21:20:51 -0600 Subject: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis In-Reply-To: <012FCD1D-DF73-4313-8EF3-81ADD5D93A5B@syseleven.de> References: <53b7b43a-316d-0a62-e247-b78beca196d1@netravnen.de> <1035588386.903366.1564947649242@mail.yahoo.com> <03701d21-f581-fc84-4779-bb16020e2078@n3network.ch> <323637d7-9fec-5f40-4c60-7204084704f9@spamtrap.tnetconsulting.net> <012FCD1D-DF73-4313-8EF3-81ADD5D93A5B@syseleven.de> Message-ID: On 8/5/19 1:17 PM, Vincentz Petzholtz wrote: > And as far as I remember: If a member fails then another one is taking > over responsibility over the used mac address. That's my understanding as well. > It surprised me a little bit that this never really taken off (not > even within Cisco folks in the enterprise field as far as I know). The few times that it's been discussed with colleagues has usually run into an issue of "how do we do GLBP between two L3 switches?". I get the impression that GLBP would be more likely used with separate routers connected to common switches that didn't do L3 switching. > I was also keen if/when this ever get available on other vendors > and/or open source software. Agreed. I did some sleuthing and just learned that OpenBSD's Common Address Redundancy Protocol (also ported to other *BSDs and Linux) does support an active/active configuration. I found some details in FreeBSD's carp(4) man page. Search said page for "net.inet.carp.arpbalance". So … I'm going to need to do some pontification about CARP. }:-) > Just as everybody else we do run two VRRP instances with ECMP style > routes on datacenter gear a lot. I see VRRP used a lot as a way to move VIPs between servers for similar redundancy reasons. > But in some situations it would be nice to have something to spread > the traffic across different routers (even when the client is too > „dump“ for ecmp routes). Yep. Cisco's GLBP can do that. I now know that OpenBSD's CARP can do that too. (#todayilearned) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From eric.kuhnke at gmail.com Tue Aug 6 06:08:54 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 5 Aug 2019 23:08:54 -0700 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> <591177.1565046126@turing-police> Message-ID: A CDN is a hosting company. It is the logical continuation and evolution of what an httpd hosting/server colo company was twenty years ago, but with more geographical scale and a great deal more automation tools. I have never in my life seen a medium to large-sized hosting company that didn't have a ToS reserving the right to discontinue service at any time for arbitrary reasons. On Mon, Aug 5, 2019 at 7:28 PM Mel Beckman wrote: > Valdis, > > A CDN is very much an ISP. It is providing transport for its customers > from arbitrary Internet destinations, to the customer’s content. The > caching done by a CDN is incidental to this transport, in accordance with > the DMCA. > > The alternative is that you believe CDNs are not protected by safe Harbor. > Is that the case? > > -mel via cell > > > On Aug 5, 2019, at 4:02 PM, Valdis Klētnieks > wrote: > > > > On Mon, 05 Aug 2019 20:40:43 -0000, Mel Beckman said: > >> The key misunderstanding on your part is the phrase “on your servers”. > ISPs > >> acting as conduits do not, by definition (in the DMCA), store anything > on > >> servers. > > > > Note that ISPs whose business is 100% "acting as conduits" are in the > minority. > > > > Hint: The DMCA has the text about data stored on ISP servers because > many ISPs > > aren't mere conduits. And this thread got started regarding a CDN, > which is very much > > all about storing data on servers..... > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Tue Aug 6 06:15:36 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 6 Aug 2019 06:15:36 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> <591177.1565046126@turing-police> , Message-ID: <9E1FF54A-491C-401F-9BA8-1D50ED647B73@beckman.org> Eric, Not really. The customer provides the content on its own servers. The CDN simply redistributes the content via temporary caching. It’s not a web hosting provider. The CDN _customer_ hosts the content. -mel beckman On Aug 5, 2019, at 11:09 PM, Eric Kuhnke > wrote: A CDN is a hosting company. It is the logical continuation and evolution of what an httpd hosting/server colo company was twenty years ago, but with more geographical scale and a great deal more automation tools. I have never in my life seen a medium to large-sized hosting company that didn't have a ToS reserving the right to discontinue service at any time for arbitrary reasons. On Mon, Aug 5, 2019 at 7:28 PM Mel Beckman > wrote: Valdis, A CDN is very much an ISP. It is providing transport for its customers from arbitrary Internet destinations, to the customer’s content. The caching done by a CDN is incidental to this transport, in accordance with the DMCA. The alternative is that you believe CDNs are not protected by safe Harbor. Is that the case? -mel via cell > On Aug 5, 2019, at 4:02 PM, Valdis Klētnieks > wrote: > > On Mon, 05 Aug 2019 20:40:43 -0000, Mel Beckman said: >> The key misunderstanding on your part is the phrase “on your servers”. ISPs >> acting as conduits do not, by definition (in the DMCA), store anything on >> servers. > > Note that ISPs whose business is 100% "acting as conduits" are in the minority. > > Hint: The DMCA has the text about data stored on ISP servers because many ISPs > aren't mere conduits. And this thread got started regarding a CDN, which is very much > all about storing data on servers..... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Tue Aug 6 06:36:12 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Tue, 06 Aug 2019 02:36:12 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <9E1FF54A-491C-401F-9BA8-1D50ED647B73@beckman.org> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> <591177.1565046126@turing-police> , <9E1FF54A-491C-401F-9BA8-1D50ED647B73@beckman.org> Message-ID: <616083.1565073372@turing-police> On Tue, 06 Aug 2019 06:15:36 -0000, Mel Beckman said: > Not really. The customer provides the content on its own servers. The CDN > simply redistributes the content via temporary caching. It���s not a web hosting > provider. The CDN _customer_ hosts the content. That's an... interesting.. interpretation. Most people would see it as the CDN doing the hosting, and the customer *providing* the content to be hosted. Do you also believe that your outbox is hosting the e-mail I'm replying to, and all the MTAs that got involved are just temporary caching? Or did you provide a copy of the mail, and request that the MTAs distribute it? (Also, if the CDN isn't a web hosting provider, why is it able to serve up data on an http connection? Hint - at one time, almost the entire web was static content, and even today a lot of it is file data not javascript and css. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From jordi.palet at consulintel.es Tue Aug 6 06:45:40 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 06 Aug 2019 08:45:40 +0200 Subject: MAP-E In-Reply-To: References: Message-ID: The difference is that 464XLAT/NAT64 is the only one that runs in cellular networks. Also with 464XLAT, you don't need DNS64. This document is already in the RFC Editor Queue: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ El 6/8/19 1:24, "NANOG en nombre de Mark Andrews" escribió: > On 6 Aug 2019, at 9:05 am, Mark Tinka wrote: > > > > On 2/Aug/19 14:17, Baldur Norddahl wrote: > >> >> >> The pricing on IPv4 is now at USD 20/address so I am thinking we are >> forced to go the CGN route going forward. Of all the options, MAP-E >> appears to be the most elegant. Just add/remove some more headers on a >> packet and route it as normal. No need to invest in anything as our >> core routers can already do that. No worries about scale. > > Actually, I think NAT64/DNS64/464XLAT is the best option, because as > more IPv4 falls away, you are automatically translating less and going > native IPv6 more. And there is nothing for you to "turn off" or migrate > away from after all is said & done. > > Mark. Which only applies to DNS64 and not 464XLAT. That said, every IPv6 node should be attempting to connect over IPv6 first. That alone moves most of the traffic to IPv6 regardless of the IPv4aaS method in use. DNS64 also breaks DNSSEC which is not a good thing. DNS64 alone also depends on *everybody* having good (complete) IPv6 connectivity and not leaving IPv6 breakages uncorrected. There is no fallback to IPv4 with DNS64 alone. If you also have 464XLAT with DNS64 then there is NO DIFFERENCE to MAP-[ET] or DS-Lite in terms of traffic shifting to native IPv6. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From mel at beckman.org Tue Aug 6 06:46:15 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 6 Aug 2019 06:46:15 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <616083.1565073372@turing-police> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> <591177.1565046126@turing-police> , <9E1FF54A-491C-401F-9BA8-1D50ED647B73@beckman.org>, <616083.1565073372@turing-police> Message-ID: Valdis, You agree that the CDN content is temporary, no? That is the definition of processes used by an ISP providing pure transport services. -mel via cell > On Aug 5, 2019, at 11:36 PM, Valdis Klētnieks wrote: > > On Tue, 06 Aug 2019 06:15:36 -0000, Mel Beckman said: > >> Not really. The customer provides the content on its own servers. The CDN >> simply redistributes the content via temporary caching. It’s not a web hosting >> provider. The CDN _customer_ hosts the content. > > That's an... interesting.. interpretation. Most people would see it as the CDN > doing the hosting, and the customer *providing* the content to be hosted. > > Do you also believe that your outbox is hosting the e-mail I'm replying to, and > all the MTAs that got involved are just temporary caching? Or did you provide > a copy of the mail, and request that the MTAs distribute it? > > (Also, if the CDN isn't a web hosting provider, why is it able to serve up data > on an http connection? Hint - at one time, almost the entire web was static > content, and even today a lot of it is file data not javascript and css. ;) From chriztoffer at netravnen.de Tue Aug 6 10:28:36 2019 From: chriztoffer at netravnen.de (Chriztoffer Hansen) Date: Tue, 6 Aug 2019 12:28:36 +0200 Subject: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis In-Reply-To: References: <53b7b43a-316d-0a62-e247-b78beca196d1@netravnen.de> <1035588386.903366.1564947649242@mail.yahoo.com> <03701d21-f581-fc84-4779-bb16020e2078@n3network.ch> <323637d7-9fec-5f40-4c60-7204084704f9@spamtrap.tnetconsulting.net> <012FCD1D-DF73-4313-8EF3-81ADD5D93A5B@syseleven.de> Message-ID: <10b28ce3-d918-4077-f530-f33606c08ff4@netravnen.de> On 06/08/2019 05:20, Grant Taylor via NANOG wrote: > I did some sleuthing and just learned that OpenBSD's Common Address > Redundancy Protocol (also ported to other *BSDs and Linux) does support > an active/active configuration. > > I found some details in FreeBSD's carp(4) man page.  Search said page > for "net.inet.carp.arpbalance". > > So … I'm going to need to do some pontification about CARP.  }:-) Colour me surprised! Option is documented as early as the FreeBSD-5.4 carp(4) man pages. https://www.freebsd.org/cgi/man.cgi?query=carp&apropos=0&sektion=4&manpath=FreeBSD+5.4-RELEASE&arch=default&format=html -- [ have you enabled IPv6 on something today...? ] [ Chriztoffer Hansen +1 914 3133553 ] [ 0x18dd23c550293098de07052a9dcf2ca008ebd2e8 ] From chris at marget.com Tue Aug 6 12:59:13 2019 From: chris at marget.com (Chris Marget) Date: Tue, 6 Aug 2019 08:59:13 -0400 Subject: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis In-Reply-To: <03701d21-f581-fc84-4779-bb16020e2078@n3network.ch> References: <53b7b43a-316d-0a62-e247-b78beca196d1@netravnen.de> <1035588386.903366.1564947649242@mail.yahoo.com> <03701d21-f581-fc84-4779-bb16020e2078@n3network.ch> Message-ID: On Mon, Aug 5, 2019 at 11:38 AM Nicolas Chabbey wrote: > > Are there any good reasons of using proprietary FHRPs like HSRP and GLBP > over VRRP ? HSRP has an potential advantage over VRRP in that HSRP speakers keep track of groups (virtual gateway clusters) in which they do not participate. The distinction could matter in a configuration where the routers all participate in dynamic routing and might be generating ICMP redirects to steer host traffic toward routers in different groups. A VRRP router will redirect the client traffic toward the physical interface of a (failure-prone) physical router (the redirect matches the sending router's routing table). An HSRP router recognizes that the preferred next-hop is participating in an HSRP group, so it redirects the client traffic toward the VIP associated with that group, rather than the physical router's interface. Since these redirects result in something akin to a static route in the host device, it's safer to have that route pointing at a virtual gateway than a physical interface. You could easily convince me that any access LAN including multiple routers participating in different FHRP groups is due for a redesign, so this distinction might be moot. But I think it's a neat subtlety. /chris From andrew.koch at gawul.net Mon Aug 5 19:40:08 2019 From: andrew.koch at gawul.net (Andrew Koch) Date: Mon, 05 Aug 2019 19:40:08 +0000 Subject: mitel hx5000 In-Reply-To: References: Message-ID: <2Ev7tKUePT6LihUpKJe5WeBkyNB0Q50YWrQkSqO_pEwTrenlJknihpDIwElvuncEgHjklB1A0AoGDLrMPfB30Jv_lleK_g8F70YLXYgyA6U=@gawul.net> Hi Sam, You might have better luck connecting through the Mitel User Group - https://mitelusergroup.org. Last I knew they were active and quite helpful. Andy On Mon, Aug 5, 2019 at 11:44, Samual Carman wrote: > does anyone have any contacts at mitel that they can share or forward me onto > > of our sister company's took over a small customer who has a mitel hx5000 and we are having a devil of a time trying to get support from mitel > > as they want us to sign a long term maintenance contract which normally we would have no problem with however come end of september we will be migrating them to are in house platform and unfortunately none of the local vendors offer short term contracts and the sister company in quiston will not budge on the timeline > > so i am hoping the world of NANOG has the ability to connect me to someone in mitel who would be able to help us out > mods if this breaks the rules please let me know i was unsure > > Thanks > Sam > Lead System Admin > Yakima Networking -------------- next part -------------- An HTML attachment was scrubbed... URL: From arusso at pixar.com Mon Aug 5 20:07:23 2019 From: arusso at pixar.com (Aaron Russo) Date: Mon, 5 Aug 2019 13:07:23 -0700 Subject: OT: Tech bag In-Reply-To: References: Message-ID: I have been really happy with my Tom Bihn Brain Bag (https://tombihn.com). I carry a 15in and 13in laptop along with a snake charmer accessory for all my cables. If you loosen the straps there’s plenty of room to also stuff a jacket AND a small to medium sized UPS parcel if need be. Aaron On Mon, Aug 5, 2019 at 08:16 John Covici wrote: > Maybe I made a mistake, let me try again. its > https://www.tombihnn.com, sorry about that. > On Fri, 02 Aug 2019 14:54:49 -0400, > Christopher Morrow wrote: > > > > On Fri, Aug 2, 2019 at 2:50 PM John Covici > wrote: > > > > > > https://www.tombin.com has some great bags for laptops, etc. Not > > > > 'server has no ip address' ..... > > $ ping www.tombin.com > > PING www.tombin.com (127.0.0.1) > > > > good try to get us all infected by malware... > > > > On a less funny note, try out some of the various osprey bags. > > > > > > > cheap but very good stuff. > > > > > > On Fri, 02 Aug 2019 12:19:08 -0400, > > > Hunter Fuller wrote: > > > > > > > > I carry this. It's a preference I gained in my past life: > > > > > https://www.kleintools.com/catalog/tool-storage/tradesman-pro-backpack > > > > > > > > I put my notebook (Surface Pro) in a sleeve and sandwich it between > > > > the halves. It hasn't gotten crushed to death yet. I'll admit this is > > > > not optimal. > > > > > > > > This one has since been released, and it has a laptop compartment. My > > > > co-worker loves it: > > > > > https://www.kleintools.com/catalog/tradesman-pro-organizers/tradesman-pro-tech-backpack > > > > > > > > On Fri, Aug 2, 2019 at 11:14 AM Dovid Bender > wrote: > > > > > > > > > > Hi, > > > > > > > > > > Sorry for the OT email. I travel extensively to DC's and my > computer bag seems to keep collecting more tools which includes your usual > console cables, spare everything, two laptops etc. My Swissgear has been > taking a beating and I was wondering what others who have to lug around > 30-35 pounds use. > > > > > > > > > > TIA. > > > > > > > > > > > > > > > > > > > > -- > > > Your life is like a penny. You're going to lose it. The question is: > > > How do > > > you spend it? > > > > > > John Covici wb2una > > > covici at ccs.covici.com > > > > -- > Your life is like a penny. You're going to lose it. The question is: > How do > you spend it? > > John Covici wb2una > covici at ccs.covici.com > -- Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at netfront.jp Tue Aug 6 12:50:06 2019 From: nanog at netfront.jp (im) Date: Tue, 6 Aug 2019 21:50:06 +0900 Subject: MX10003 rack size In-Reply-To: <29AA198D-CE4F-4ACD-8649-662ED2C34E29@steffann.nl> References: <29AA198D-CE4F-4ACD-8649-662ED2C34E29@steffann.nl> Message-ID: <20190806215006.a5e01f6f6a5e954496130bbb@netfront.jp> 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 ;) No. In my case, MX10003 needs 13cm gap between front-door and fron-panel, and needs 10cm gap between back-door and back-panel. You need at least 120cm depth. you can install 90cm depth rack if without cabling, never power-on ;) thanks, -- im On Tue, 30 Jul 2019 14:32:23 +0200 Sander Steffann wrote: > 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 > From amitchell at isipp.com Tue Aug 6 15:47:07 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Tue, 6 Aug 2019 09:47:07 -0600 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> <591177.1565046126@turing-police> <9E1FF54A-491C-401F-9BA8-1D50ED647B73@beckman.org> <616083.1565073372@turing-police> Message-ID: <232B2BEB-84BE-4A68-A16E-538C4E7D333B@isipp.com> Hey guys, how about we talk about the CLOUD act now? Anne --- Anne P. Mitchell, Attorney at Law Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose CEO/President, Institute for Social Internet Public Policy Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS) Member: California Bar Association From warren at kumari.net Tue Aug 6 15:52:02 2019 From: warren at kumari.net (Warren Kumari) Date: Tue, 6 Aug 2019 11:52:02 -0400 Subject: MX10003 rack size In-Reply-To: <20190806215006.a5e01f6f6a5e954496130bbb@netfront.jp> References: <29AA198D-CE4F-4ACD-8649-662ED2C34E29@steffann.nl> <20190806215006.a5e01f6f6a5e954496130bbb@netfront.jp> Message-ID: On Tue, Aug 6, 2019 at 10:23 AM im wrote: > > 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 ;) > > No. > > In my case, MX10003 needs 13cm gap between front-door and fron-panel, > and needs 10cm gap between back-door and back-panel. > > You need at least 120cm depth. > ... but... but the sales blurb says: "Space and Power Optimized Provides advanced power-saving features in a small form factor to help contain OpEx and ensure exceptional efficiency." > > you can install 90cm depth rack if without cabling, never power-on ;) Ah. Yes, if you never power it on, it has awesome OpEx, and exceptional efficiency... solved! W > > > thanks, > > -- > im > > > On Tue, 30 Jul 2019 14:32:23 +0200 > Sander Steffann wrote: > > > 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 > > > > -- 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 lobna_gouda at hotmail.com Tue Aug 6 17:10:49 2019 From: lobna_gouda at hotmail.com (lobna gouda) Date: Tue, 6 Aug 2019 17:10:49 +0000 Subject: Network controller Message-ID: Hello Networker, Wanted to get a general feedback, if you are considering having a controller on your network. Let's say it will be on your core network to handle your mpls network or core network or to provide Traffic Engineering (TE) feedback/decisions What would you need from a controller and its software What we would like to have in a controller and its software what we can live without it ( The answer isnot the controller here) Cdt LG -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Tue Aug 6 17:59:03 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 6 Aug 2019 17:59:03 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <232B2BEB-84BE-4A68-A16E-538C4E7D333B@isipp.com> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> <591177.1565046126@turing-police> <9E1FF54A-491C-401F-9BA8-1D50ED647B73@beckman.org> <616083.1565073372@turing-police> <232B2BEB-84BE-4A68-A16E-538C4E7D333B@isipp.com> Message-ID: <9592F64F-3666-441E-A8B5-2FB19728A77F@beckman.org> Anne, Is the CLOUD Act germane to North American network operations (the mission of NANOG)? My understanding is that this ACT was to help solve problems the FBI had with obtaining remote data through overseas service providers, through SCA warrants. SCA already compels U.S.- and Canada-based service providers, via warrant or subpoena, to provide requested data stored on servers. It doesn’t matter if the data are stored in the U.S. or in another country. I’m not seeing how CLOUD impacts any NANOG member, which just encompasses Canada and the US (Mexico has its own network operator’s group, LACNOG.) I’m open to being educated, however. -mel On Aug 6, 2019, at 8:47 AM, Anne P. Mitchell, Esq. > wrote: Hey guys, how about we talk about the CLOUD act now? Anne --- Anne P. Mitchell, Attorney at Law Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose CEO/President, Institute for Social Internet Public Policy Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS) Member: California Bar Association -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitchell at isipp.com Tue Aug 6 18:16:48 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Tue, 6 Aug 2019 12:16:48 -0600 Subject: the CLOUD Act (was What can ISPs do better? Removing racism out of internet) In-Reply-To: <9592F64F-3666-441E-A8B5-2FB19728A77F@beckman.org> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> <591177.1565046126@turing-police> <9E1FF54A-491C-401F-9BA8-1D50ED647B73@beckman.org> <616083.1565073372@turing-police> <232B2BEB-84BE-4A68-A16E-538C4E7D333B@isipp.com> <9592F64F-3666-441E-A8B5-2FB19728A77F@beckman.org> Message-ID: <4774D19D-DE01-4484-9D15-F7E4511AD68D@isipp.com> > Is the CLOUD Act germane to North American network operations (the mission of NANOG)? My understanding is that this ACT was to help solve problems the FBI had with obtaining remote data through overseas service providers, through SCA warrants. > > SCA already compels U.S.- and Canada-based service providers, via warrant or subpoena, to provide requested data stored on servers. It doesn’t matter if the data are stored in the U.S. or in another country. I’m not seeing how CLOUD impacts any NANOG member, which just encompasses Canada and the US (Mexico has its own network operator’s group, LACNOG.) > > I’m open to being educated, however. The CLOUD act is reciprocal. It allows an agency of another country to demand from U.S.-based holders of data that data which is relevant to a citizen of that country, where that individual is working abroad in the U.S.. - with *no* due process - in fact with no requirement of notice to that individual. It's the equivalent of a demand for production of documents (i.e. a subpoena) - no warrant, no anything else. Example (using the UK because that is the reciprocal agreement closest to being formalized): John Deaux is from London, and a citizen of the UK. John is working in the U.S., at a tech company in Palo Alto, California. John has a Gmail account, and uses Dropbox to store his photos. A law enforcement agency in the UK decides that it wants access to the data in John’s Gmail account and Dropbox account, and so they serve a demand for the production of John’s data on Google and Dropbox, under the CLOUD Act. If the U.S. and the UK have an executive agreement in place as contemplated by the CLOUD Act, Google and Dropbox must comply. And, it gets worse: Let’s say that while combing through John Deaux’s Gmail data the UK authorities find evidence that he has been laundering money, and they believe that it may be in concert with Joe Smith, who lives in Mountain View, a short distance from John. Joe is a U.S. citizen. The U.S. authorities do not know about Joe’s possible illegal activity, and they have no reason to suspect it. If they did suspect it, they would have to convince a judge to issue a warrant to search Joe’s data (because in the U.S. you can only use the subpoena route if there is already an open case against the person). *However*, there is nothing in the CLOUD Act that stops the UK agency from simply passing this data on to U.S. law enforcement voluntarily. In fact, the CLOUD Act encourages it. Anne --- Anne P. Mitchell, Attorney at Law Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose CEO/President, Institute for Social Internet Public Policy Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS) Member: California Bar Association From bzs at theworld.com Tue Aug 6 18:17:50 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 6 Aug 2019 14:17:50 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <591177.1565046126@turing-police> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> <591177.1565046126@turing-police> Message-ID: <23881.50254.708533.931864@gargle.gargle.HOWL> On August 5, 2019 at 19:02 valdis.kletnieks at vt.edu (Valdis Klētnieks) wrote: > > Hint: The DMCA has the text about data stored on ISP servers because many ISPs > aren't mere conduits. And this thread got started regarding a CDN, which is very much > all about storing data on servers..... I acted as an expert witness for the FBI regarding a case which revolved around whether email spending time on intermediate servers is "storing" the data or is it just another form of wire transmission? I don't think they came to a definitive conclusion, the case was basically settled out of court, plea-bargained I think, it was a criminal matter. But needless to say, once again, a non-legal-expert's reading of "storing data on servers" doesn't amount to a hill of beans in the legal world. It turned out to be very important at least in theory since illegally intercepting a wire transmission falls under a completely different law than illegally accessing stored data, the defendant was arguing that he'd been charged under the wrong law, and the court agreed it was a valid point to investigate. So my phone rang and I tried to help with the part of that (technical) I knew something about, how internet email is transmitted etc. But I was briefed on the legal aspects to help me focus on what they needed and I agreed it isn't /prima facie/ obvious. For example you may see storing of email (which may not even mean to a physical disk) during transmission through intermediate servers as "storing of data" but then again many network devices have various buffering mechanisms in which data might reside for some amount of time. Are they legally distinguishable? Should they be? etc. -- -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 rob at invaluement.com Tue Aug 6 18:30:03 2019 From: rob at invaluement.com (Rob McEwen) Date: Tue, 6 Aug 2019 14:30:03 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <9592F64F-3666-441E-A8B5-2FB19728A77F@beckman.org> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> <591177.1565046126@turing-police> <9E1FF54A-491C-401F-9BA8-1D50ED647B73@beckman.org> <616083.1565073372@turing-police> <232B2BEB-84BE-4A68-A16E-538C4E7D333B@isipp.com> <9592F64F-3666-441E-A8B5-2FB19728A77F@beckman.org> Message-ID: <7ef2ad42-8e52-0d7c-608b-b5812451a59a@invaluement.com> I'm so tired of this thread - but the bottom line is that censorship and even the definition of "hate" and "racism" (especially when used in the vernacular!) are extremely subjective and can lead to situations where reasonable people disagree. And if/when such policies are implemented to try to limit or shut down such speech, horrific unintended collateral damage will LIKELY occur. Also, totalitarian regimes OFTEN use the same arguments to get their foot in the door of controlling and suppressing speech. Even now, the mainstream news media is ALREADY highlighting a very selective part of these murderer's ideologies, and suppressing other parts, in order to convey an overall impression of their ideologies that doesn't actually match them, but furthers certain biased agendas. So actions to suppress "hate speech" and "racism" based on the 1/2 truths that most have been brainwashed to believe about these evil murderers' beliefs (1/2 contradicted by their own actual writings, which are already evil!), is ALREADY well on its way towards potentially causing collateral damage by unplugging or suppressing forums/platforms that really don't closely match the actual ideology of the shooters. Again, I'm not defending the murderers in the slightest - I'm just saying that many of those in favor of limiting speech are the SAME crowd that is either publishing or consuming content that describes the shooters' ideologies in a certain particular way that purposely tries to make them look like a DIFFERENT group of deranged people, in order to advance a biased agenda. So we're already well on the way towards the collateral damage I mentioned above. Also, I'm not saying that nothing should ever be done, or that we can't make any changes or improvements, but the cure might end up being potentially much worse than the disease if we're not careful. -- Rob McEwen -------------- next part -------------- An HTML attachment was scrubbed... URL: From sabri at cluecentral.net Tue Aug 6 18:31:59 2019 From: sabri at cluecentral.net (Sabri Berisha) Date: Tue, 6 Aug 2019 11:31:59 -0700 (PDT) Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <816F5638-304B-46FA-A9D4-E2D374BE87C7@isipp.com> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <23880.27492.578569.996929@gargle.gargle.HOWL> <816F5638-304B-46FA-A9D4-E2D374BE87C7@isipp.com> Message-ID: <330425820.174606.1565116319541.JavaMail.zimbra@cluecentral.net> Hi Anne, I would argue that if you're not in the EU and have no presence there, you are safe from GDPR. No matter how much they EUSSR wants it, they cannot enforce their laws in other jurisdictions. What would happen if Russia would try to enforce their laws in the U.S.? Same thing. GDPR is the most ridiculous piece of legislation I've ever read, and a clear indication of where the EUSSR is headed to. A bloated business unfriendly socialist continent. Thanks, Sabri Berisha, Network Engineer CEO/President, Cluecentral Ventures Inc Volunteer, Barrett Elementary School Author: www.null.nl Network Consultant M.Sc, MBA, JNCIE-M/SP #261, JNCIP-M/SP #381, JNCIS-ER, JNCIS-ENT, JNCSP-SP, ECE-IPN #2 Board of Directors, Villanova HOA Licensed Pilot Former JTAC Engineer Member: AAA ----- On Aug 5, 2019, at 10:56 AM, Anne P. Mitchell, Esq. amitchell at isipp.com wrote: >> On Aug 5, 2019, at 11:46 AM, bzs at theworld.com wrote: >> >> My first suggestion would be to include an indemnification clause in >> your contracts which includes liability for content, if you don't >> already have it (probably most do.) >> >> And a clause which indicates you (need lawyering for this) will seek >> expenses including but not limited to legal, judgements, reputational >> recovery (e.g., cost of producing press releases), etc, incurred by >> actions taken by customer. > > These are all excellent suggestions - and while we're on the subject of that > sort of thing, *everyone* should have warrantees of GDPR compliance in any of > their third-party contracts in which data can be touched, and *also* > indemnification clauses in those same contracts if you are held responsible > because those third-parties were breached, etc., and found to *not* be in > compliance with GDPR (for which GDPR specifically provides - i.e. GDPR can go > through the third-party contract and hold *you* liable). This is one of the > ways that GDPR can seep in to get you even if you think you're safe because > you're not in the EU. > > Anne > > --- > > Anne P. Mitchell, Attorney at Law > CEO/President, Institute for Social Internet Public Policy > Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose > Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) > Legislative Consultant > GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant > Board of Directors, Denver Internet Exchange > Board of Directors, Asilomar Microcomputer Workshop > Legal Counsel: The CyberGreen Institute > Former Counsel: Mail Abuse Prevention System (MAPS) > Member: California Bar Association From mel at beckman.org Tue Aug 6 18:43:18 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 6 Aug 2019 18:43:18 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <23881.50254.708533.931864@gargle.gargle.HOWL> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> <591177.1565046126@turing-police> <23881.50254.708533.931864@gargle.gargle.HOWL> Message-ID: <39C2F459-F8B1-4949-80CE-26A5BB80A959@beckman.org> Anne, I can see the 4th amendment violation here, but are there operational issues with ISPs? For example, CALEA requires telecommunications carriers (or VoIP providers) to provide voice data streams to law enforcement agencies in real time. NSLs require production of customer information in secret, which means the ISP needs internal security procedures to avoid criminal violations of the terms of the NSL. So impacted ISP’s have a clear operational concerns in both cases. What is the CLOUD Act’s operational impact? Is it the same as responding to an ordinary subpoena or search warrant? FISA, for example, has similar 4A issues, but no operational component for ISPs (the government intercepts data using its own means in the Internet backbone). One operational issue with CLOUD might be how much data an ISP turns over in a CLOUD Act request (which I gather still requires due process for the ISP). For example, when your example law enforcement agency in the UK uses their power under a CLOUD executive agreement to collect a foreign target’s data from a US ISP, can the ISP legally sanitize that data to mask US citizens information? This is, after all, the standard with FISA 702 (requiring the gov to get a warrant before looking at information collected on US intelligence agencies surveilling foreign targets). If that’s the case, then there is an operational interest in ISP-operated software to do the sanitizing. If it’s not the case, and the ISP has to turn over anything requested, I’m not seeing the operational impact. The technical effort is no different than with today’s domestic subpoenas, which ISPs deal with all the time. -mel > On Aug 6, 2019, at 11:17 AM, bzs at theworld.com wrote: > > > On August 5, 2019 at 19:02 valdis.kletnieks at vt.edu (Valdis Klētnieks) wrote: >> >> Hint: The DMCA has the text about data stored on ISP servers because many ISPs >> aren't mere conduits. And this thread got started regarding a CDN, which is very much >> all about storing data on servers..... > > I acted as an expert witness for the FBI regarding a case which > revolved around whether email spending time on intermediate servers is > "storing" the data or is it just another form of wire transmission? > > I don't think they came to a definitive conclusion, the case was > basically settled out of court, plea-bargained I think, it was a > criminal matter. > > But needless to say, once again, a non-legal-expert's reading of > "storing data on servers" doesn't amount to a hill of beans in the > legal world. > > It turned out to be very important at least in theory since illegally > intercepting a wire transmission falls under a completely different > law than illegally accessing stored data, the defendant was arguing > that he'd been charged under the wrong law, and the court agreed it > was a valid point to investigate. > > So my phone rang and I tried to help with the part of that (technical) > I knew something about, how internet email is transmitted etc. But I > was briefed on the legal aspects to help me focus on what they needed > and I agreed it isn't /prima facie/ obvious. > > For example you may see storing of email (which may not even mean to a > physical disk) during transmission through intermediate servers as > "storing of data" but then again many network devices have various > buffering mechanisms in which data might reside for some amount of > time. Are they legally distinguishable? Should they be? etc. > > -- > -Barry Shein > > Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com > Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD > The World: Since 1989 | A Public Information Utility | *oo* From kmedcalf at dessus.com Tue Aug 6 18:54:55 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 06 Aug 2019 12:54:55 -0600 Subject: the CLOUD Act (was What can ISPs do better? Removing racism out of internet) In-Reply-To: <4774D19D-DE01-4484-9D15-F7E4511AD68D@isipp.com> Message-ID: <9ff35c5f01620b4cb3d51d61a351f276@mail.dessus.com> On Tuesday, 6 August, 2019 12:17, Anne P. Mitchell, Esq. wrote: ... >John Deaux is from London, and a citizen of the UK. John is working >in the U.S., at a tech company in Palo Alto, California. John has a >Gmail account, and uses Dropbox to store his photos. A law >enforcement agency in the UK decides that it wants access to the data >in John’s Gmail account and Dropbox account, and so they serve a >demand for the production of John’s data on Google and Dropbox, under >the CLOUD Act. If the U.S. and the UK have an executive agreement in >place as contemplated by the CLOUD Act, Google and Dropbox must >comply. I assume that by "serve a demand" you mean "send a letter requesting"? I realize that the purpose of the terms "serve a demand" if legal globedey-glook phrased to pompously instill in the reader some feeling of the majesty and due regard for the process (etc), but in reality it is just pompous for "send a letter requesting" is it not? >Google and Dropbox must comply. Well, no. They do not "have to" do anything. You do not *have to comply* with anything. Such is the nature of existance and it has always been thus. Of course, those seeking compliance are also free to torture you until you do as they want, but you do not "have to comply". What happens when an irresistable force (the torturer) meets and immovable object (the one refusing to comply) depends on which has the greatest resolve. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From valdis.kletnieks at vt.edu Tue Aug 6 19:20:49 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Tue, 06 Aug 2019 15:20:49 -0400 Subject: the CLOUD Act (was What can ISPs do better? Removing racism out of internet) In-Reply-To: <9ff35c5f01620b4cb3d51d61a351f276@mail.dessus.com> References: <9ff35c5f01620b4cb3d51d61a351f276@mail.dessus.com> Message-ID: <36857.1565119249@turing-police> On Tue, 06 Aug 2019 12:54:55 -0600, "Keith Medcalf" said: > I realize that the purpose of the terms "serve a demand" if legal > globedey-glook phrased to pompously instill in the reader some feeling of the > majesty and due regard for the process (etc), but in reality it is just pompous > for "send a letter requesting" is it not? I don't know about that. Most definitions of "pompous" don't include the implied phrase "or end up in a cell on a contempt citation". Feel free to be the test case to find out if a demand under the CLOUD act can result in a US contempt citation. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From bzs at theworld.com Tue Aug 6 19:40:27 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Tue, 6 Aug 2019 15:40:27 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <7ef2ad42-8e52-0d7c-608b-b5812451a59a@invaluement.com> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> <591177.1565046126@turing-police> <9E1FF54A-491C-401F-9BA8-1D50ED647B73@beckman.org> <616083.1565073372@turing-police> <232B2BEB-84BE-4A68-A16E-538C4E7D333B@isipp.com> <9592F64F-3666-441E-A8B5-2FB19728A77F@beckman.org> <7ef2ad42-8e52-0d7c-608b-b5812451a59a@invaluement.com> Message-ID: <23881.55211.138415.916694@gargle.gargle.HOWL> And now this has happened, in a nutshell France's lower house says remove content which is "obviously hateful" (words used in the article) in 24 hours or face up to a 1.25M euro fine. Granted perhaps it won't become law. But legislators are clearly becoming consumed with this whole internet fad and when all you have is a hammer the whole world looks like a nail. I'd argue all they're trying to legislate is free curation from providers which is a really lousy thing to do. https://www.msn.com/en-us/news/world/frances-lower-house-passes-online-hate-speech-law/ar-AAE5prg -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From kmedcalf at dessus.com Tue Aug 6 19:43:23 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 06 Aug 2019 13:43:23 -0600 Subject: the CLOUD Act (was What can ISPs do better? Removing racism out of internet) In-Reply-To: <36857.1565119249@turing-police> Message-ID: <17dc61699847d643b61cf840957b8986@mail.dessus.com> On Tuesday, 6 August, 2019 13:21, Valdis Kletnieks wrote: >On Tue, 06 Aug 2019 12:54:55 -0600, "Keith Medcalf" said: >> I realize that the purpose of the terms "serve a demand" if legal >> globedey-glook phrased to pompously instill in the reader some >> feeling of the majesty and due regard for the process (etc), but >> in reality it is just pompous for "send a letter requesting" is it not? > I don't know about that. Most definitions of "pompous" don't include > the implied phrase "or end up in a cell on a contempt citation". In Canada that is called "Extortion" and is a crime punishable by a number of years in prison. If the "implication" of the phraseology is to convey a threat in order to obtain compliance with the object of the statement, then the entire process is extortion from the get go. Since this cannot possibly be the case, your assertion must be incorrect, and there can be no such implication. Moveover I would wonder what exactly one would be in contempt of? The politicians who voted in favour of the passage of the Act? Contempt for the sender of the letter? None of these are capable of being "contempt" in any actionable sense. In fact, failure to comply with an order of a judge who makes an "administrative" order (that is, who is not acting as a judge, but is merely an administrative functionary or rubber-stamper) does not constitute contempt of court in Canada (since there was no actual due process or court function of judicial judgement involved to be in contempt of). >Feel free to be the test case to find out if a demand under the CLOUD >act can result in a US contempt citation. :) Anyone can bring whatever proceedings they like before any court at any time for any reason or no reason at all without regard to the probability of success of those proceedings. So whether or not "a demand under the CLOUD act can result in a US contempt citation" is quite meaningless. Of course, I only have first-hand knowledge of legal procedures in free countries, so how the United States does things is not entirely within my experience. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From clegendre at coextro.com Tue Aug 6 15:10:07 2019 From: clegendre at coextro.com (Colin Legendre) Date: Tue, 6 Aug 2019 11:10:07 -0400 Subject: GEO IP Updates Message-ID: Hi, We've leased some new IP blocks, but are having issues with customers complaining they can't access some Geo Restricted content. We updated all the GEO IP databases we can think of.. but are still having issues... 2 services people have complained about are... Crave TV Amazon Prime We are located in Canada as are all our clients, and they are getting notices that they are located in the US. We updated... Maxmind, DB-IP, IP Info, IP Geolocation, IPHub. IP2location Any others we should update? --- Colin -------------- next part -------------- An HTML attachment was scrubbed... URL: From dylan.kraklan at dedipath.com Tue Aug 6 18:31:15 2019 From: dylan.kraklan at dedipath.com (Dylan Kraklan) Date: Tue, 6 Aug 2019 14:31:15 -0400 Subject: Network controller In-Reply-To: References: Message-ID: We are looking for something that could manage our commts with our providers from keeping us from having to pay overages. and possibly something similar to noction which would optimize BGP to improve traffic to our clients. On Tue, Aug 6, 2019 at 1:12 PM lobna gouda wrote: > Hello Networker, > > Wanted to get a general feedback, if you are considering having a > controller on your network. Let's say it will be on your core network to > handle your mpls network or core network or to provide Traffic Engineering > (TE) feedback/decisions > > What would you need from a controller and its software > What we would like to have in a controller and its software > what we can live without it ( The answer isnot the controller here) > > Cdt > > LG > > > -- *Dylan Kraklan* *Executive Vice President* *DediPath *| Dedicated Serves | Colocation | Virtual Private Servers Office: 1 (877) 234-DEDI Ext 806 http://www.dedipath.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lobna_gouda at hotmail.com Tue Aug 6 19:53:20 2019 From: lobna_gouda at hotmail.com (lobna gouda) Date: Tue, 6 Aug 2019 19:53:20 +0000 Subject: Network controller In-Reply-To: References: , Message-ID: Thanks Dylan, so bgp route-policy controller and optimizer. Any thoughts to go more granular than ips and look into the ports as well. ________________________________ From: Dylan Kraklan Sent: Tuesday, August 6, 2019 2:31 PM To: lobna gouda Cc: nanog at nanog.org Subject: Re: Network controller We are looking for something that could manage our commts with our providers from keeping us from having to pay overages. and possibly something similar to noction which would optimize BGP to improve traffic to our clients. On Tue, Aug 6, 2019 at 1:12 PM lobna gouda > wrote: Hello Networker, Wanted to get a general feedback, if you are considering having a controller on your network. Let's say it will be on your core network to handle your mpls network or core network or to provide Traffic Engineering (TE) feedback/decisions What would you need from a controller and its software What we would like to have in a controller and its software what we can live without it ( The answer isnot the controller here) Cdt LG -- Dylan Kraklan Executive Vice President DediPath | Dedicated Serves | Colocation | Virtual Private Servers Office: 1 (877) 234-DEDI Ext 806 http://www.dedipath.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dylan.kraklan at dedipath.com Tue Aug 6 19:53:21 2019 From: dylan.kraklan at dedipath.com (Dylan Kraklan) Date: Tue, 6 Aug 2019 15:53:21 -0400 Subject: GEO IP Updates In-Reply-To: References: Message-ID: <254b1ddd-3314-4865-830b-b2f098af152b@Spark> Did you update the info in the Whois at the RIR ? Sometimes they pull from this in my experience. On Aug 6, 2019, 3:48 PM -0400, Colin Legendre , wrote: > Hi, > > We've leased some new IP blocks, but are having issues with customers complaining they can't access some Geo Restricted content. > > We updated all the GEO IP databases we can think of.. but are still having issues... > > 2 services people have complained about are... > > Crave TV > Amazon Prime > > We are located in Canada as are all our clients, and they are getting notices that they are located in the US. > > We updated... Maxmind, DB-IP, IP Info, IP Geolocation, IPHub. IP2location > > Any others we should update? > > --- > Colin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mel at beckman.org Tue Aug 6 20:00:42 2019 From: mel at beckman.org (Mel Beckman) Date: Tue, 6 Aug 2019 20:00:42 +0000 Subject: the CLOUD Act (was What can ISPs do better? Removing racism out of internet) In-Reply-To: <17dc61699847d643b61cf840957b8986@mail.dessus.com> References: <17dc61699847d643b61cf840957b8986@mail.dessus.com> Message-ID: My final comment on the original proposition of this thread, "What can ISPs do better? Removing racism out of internet.” is that no, we can’t remove racism from the Internet and still have free speech on, at least, democratically-administered Internet realms. -mel On Aug 6, 2019, at 12:43 PM, Keith Medcalf > wrote: On Tuesday, 6 August, 2019 13:21, Valdis Kletnieks > wrote: On Tue, 06 Aug 2019 12:54:55 -0600, "Keith Medcalf" said: I realize that the purpose of the terms "serve a demand" if legal globedey-glook phrased to pompously instill in the reader some feeling of the majesty and due regard for the process (etc), but in reality it is just pompous for "send a letter requesting" is it not? I don't know about that. Most definitions of "pompous" don't include the implied phrase "or end up in a cell on a contempt citation". In Canada that is called "Extortion" and is a crime punishable by a number of years in prison. If the "implication" of the phraseology is to convey a threat in order to obtain compliance with the object of the statement, then the entire process is extortion from the get go. Since this cannot possibly be the case, your assertion must be incorrect, and there can be no such implication. Moveover I would wonder what exactly one would be in contempt of? The politicians who voted in favour of the passage of the Act? Contempt for the sender of the letter? None of these are capable of being "contempt" in any actionable sense. In fact, failure to comply with an order of a judge who makes an "administrative" order (that is, who is not acting as a judge, but is merely an administrative functionary or rubber-stamper) does not constitute contempt of court in Canada (since there was no actual due process or court function of judicial judgement involved to be in contempt of). Feel free to be the test case to find out if a demand under the CLOUD act can result in a US contempt citation. :) Anyone can bring whatever proceedings they like before any court at any time for any reason or no reason at all without regard to the probability of success of those proceedings. So whether or not "a demand under the CLOUD act can result in a US contempt citation" is quite meaningless. Of course, I only have first-hand knowledge of legal procedures in free countries, so how the United States does things is not entirely within my experience. -- 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 goemon at sasami.anime.net Tue Aug 6 20:17:15 2019 From: goemon at sasami.anime.net (Dan Hollis) Date: Tue, 6 Aug 2019 13:17:15 -0700 (PDT) Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <7ef2ad42-8e52-0d7c-608b-b5812451a59a@invaluement.com> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <112A3B10-EB40-413C-83A5-C722B327A63C@beckman.org> <3DB65583-1EB0-4F25-8FDA-11E542440258@isipp.com> <575639.1565030030@turing-police> <43310F5E-3A45-4063-8E2E-C0AD3CA08C5D@beckman.org> <591177.1565046126@turing-police> <9E1FF54A-491C-401F-9BA8-1D50ED647B73@beckman.org> <616083.1565073372@turing-police> <232B2BEB-84BE-4A68-A16E-538C4E7D333B@isipp.com> <9592F64F-3666-441E-A8B5-2FB19728A77F@beckman.org> <7ef2ad42-8e52-0d7c-608b-b5812451a59a@invaluement.com> Message-ID: On Tue, 6 Aug 2019, Rob McEwen wrote: > I'm so tired of this thread - but the bottom line is that censorship and even > the definition of "hate" and "racism" (especially when used in the > vernacular!) are extremely subjective and can lead to situations where > reasonable people disagree. And if/when such policies are implemented to try > to limit or shut down such speech, horrific unintended collateral damage will > LIKELY occur. Also, totalitarian regimes OFTEN use the same arguments to get > their foot in the door of controlling and suppressing speech. Even now, the > mainstream news media is ALREADY highlighting a very selective part of these > murderer's ideologies, and suppressing other parts, in order to convey an > overall impression of their ideologies that doesn't actually match them, but > furthers certain biased agendas. So actions to suppress "hate speech" and > "racism" based on the 1/2 truths that most have been brainwashed to believe > about these evil murderers' beliefs (1/2 contradicted by their own actual > writings, which are already evil!), is ALREADY well on its way towards > potentially causing collateral damage by unplugging or suppressing > forums/platforms that really don't closely match the actual ideology of the > shooters. those who perform political curation of content are at risk of losing their section 230 protections. archive.fo/zOUBG if you really want this to happen, go ahead and "remove racism out of internet". you won't like the result. -Dan From clegendre at coextro.com Tue Aug 6 21:31:28 2019 From: clegendre at coextro.com (Colin Legendre) Date: Tue, 6 Aug 2019 17:31:28 -0400 Subject: GEO IP Updates In-Reply-To: <254b1ddd-3314-4865-830b-b2f098af152b@Spark> References: <254b1ddd-3314-4865-830b-b2f098af152b@Spark> Message-ID: No, we don't own the IPs, we lease them. We have no access to the whois data, and have other blocks that we've had no issues with, so certainly not that. Also using whois would be odd, as people often have large blocks, and don't subdivide them in whois to say where each block is located. --- Colin Legendre President and CTO Coextro - Unlimited. Fast. Reliable. w: www.coextro.com e: clegendre at coextro.com p: 647-693-7686 ext.101 m: 416-560-8502 f: 647-693-7601 On Tue, Aug 6, 2019 at 3:53 PM Dylan Kraklan wrote: > Did you update the info in the Whois at the RIR ? Sometimes they pull from > this in my experience. > On Aug 6, 2019, 3:48 PM -0400, Colin Legendre , > wrote: > > Hi, > > We've leased some new IP blocks, but are having issues with customers > complaining they can't access some Geo Restricted content. > > We updated all the GEO IP databases we can think of.. but are still having > issues... > > 2 services people have complained about are... > > Crave TV > Amazon Prime > > We are located in Canada as are all our clients, and they are getting > notices that they are located in the US. > > We updated... Maxmind, DB-IP, IP Info, IP Geolocation, IPHub. IP2location > > Any others we should update? > > --- > Colin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjo at dojo.mi.org Wed Aug 7 00:37:20 2019 From: mjo at dojo.mi.org (Mike O'Connor) Date: Tue, 6 Aug 2019 20:37:20 -0400 Subject: netstat -s In-Reply-To: <1CD09B99-B6A9-4C76-B2FA-4FB06164953C@tzi.org> References: <1CD09B99-B6A9-4C76-B2FA-4FB06164953C@tzi.org> Message-ID: <20190807003720.vwy3x6aa6guyf3zu@dojo.mi.org> :On Jul 17, 2019, at 20:54, Randy Bush wrote: :> :> do folk use `netstat -s` to help diagnose on routers/switches? Yes, for sufficienly Unix-y 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. "sudo netstat -s" is your friend. -Mike -- Michael J. O'Connor mjo at dojo.mi.org =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "Puny god." -Hulk -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From johnl at iecc.com Wed Aug 7 02:36:45 2019 From: johnl at iecc.com (John Levine) Date: 6 Aug 2019 22:36:45 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> Message-ID: <20190807023646.51AB87B7BE3@ary.qy> In article <6956E76B-E6B7-409F-A636-C7607BFD881C at beckman.org> you write: >Mehmet, > >I’m not sure if you understand the terms under which ISPs operate as “common carriers”, and thus enjoy immunity from lawsuits due to the acts of their customers. ISPs in the U.S. are not carriers and never have been. Even the ISPs that are subsidaries of telcos, which are common carriers for their telco operations, are not common carriers for their ISPs. This should not come as surprise to anyone who's spent 15 minutes looking at the relevant law. ISPs are probably protected by 47 USC 230(c)(1) but all of the case law I know is related to web sites or hosting providers. From mel at beckman.org Wed Aug 7 03:36:03 2019 From: mel at beckman.org (Mel Beckman) Date: Wed, 7 Aug 2019 03:36:03 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <20190807023646.51AB87B7BE3@ary.qy> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org>, <20190807023646.51AB87B7BE3@ary.qy> Message-ID: John, Please reread my comments. I did not say “carriers” and specifically excluded the FCC’s definition. I said “Common Carriers”, as defined by Common Law. The DMCA asserts that they must operate as CCs under this definition: in order to get protection under Safe Harbor they must function as a “passive conduit” of information. -mel via cell > On Aug 6, 2019, at 7:36 PM, John Levine wrote: > > In article <6956E76B-E6B7-409F-A636-C7607BFD881C at beckman.org> you write: >> Mehmet, >> >> I’m not sure if you understand the terms under which ISPs operate as “common carriers”, and thus enjoy immunity from lawsuits due to the acts of their customers. > > ISPs in the U.S. are not carriers and never have been. Even the ISPs > that are subsidaries of telcos, which are common carriers for their > telco operations, are not common carriers for their ISPs. > > This should not come as surprise to anyone who's spent 15 minutes > looking at the relevant law. > > ISPs are probably protected by 47 USC 230(c)(1) but all of the case > law I know is related to web sites or hosting providers. > > From eric-list at truenet.com Wed Aug 7 03:43:40 2019 From: eric-list at truenet.com (Eric Tykwinski) Date: Tue, 6 Aug 2019 23:43:40 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <20190807023646.51AB87B7BE3@ary.qy> References: <20190807023646.51AB87B7BE3@ary.qy> Message-ID: <56CBB25E-9A53-4E5E-B2CB-3E769112F516@truenet.com> John, Seriously, just quote so people don’t have to look it up. Honestly, though others are probably right in that case law usually will over-ride written law due to our legal structure. > On Aug 6, 2019, at 10:36 PM, John Levine wrote: > > In article <6956E76B-E6B7-409F-A636-C7607BFD881C at beckman.org> you write: >> Mehmet, >> >> I’m not sure if you understand the terms under which ISPs operate as “common carriers”, and thus enjoy immunity from lawsuits due to the acts of their customers. > > ISPs in the U.S. are not carriers and never have been. Even the ISPs > that are subsidaries of telcos, which are common carriers for their > telco operations, are not common carriers for their ISPs. > > This should not come as surprise to anyone who's spent 15 minutes > looking at the relevant law. > > ISPs are probably protected by 47 USC 230(c)(1) but all of the case > law I know is related to web sites or hosting providers. [ (1)Treatment of publisher or speaker No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider. ] Sounds great on paper, but sort of caught backpage in a quondam, perhaps because they installed filters to begin with. Technically, will anyone else booting customer’s for any offense of TOS be similar is still up for grabs, since it’s basically a political nightmare for lawyers right now. Right or wrong in your philosophy you are basically screwed imho. I guess that’s why Anne’s got a job... * Seriously though I think we should probably put a discussion thread in here, it’s reminding me of outages saying me too. From johnl at iecc.com Wed Aug 7 04:40:10 2019 From: johnl at iecc.com (John Levine) Date: 7 Aug 2019 00:40:10 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <56CBB25E-9A53-4E5E-B2CB-3E769112F516@truenet.com> Message-ID: <20190807044011.4826B7B8804@ary.qy> In article <56CBB25E-9A53-4E5E-B2CB-3E769112F516 at truenet.com> you write: >John, > >Seriously, just quote so people don’t have to look it up. Honestly, though others are probably right in that case law usually will over-ride written law due >to our legal structure. Well, kind of, but in this particular case they're well aligned. >> ISPs are probably protected by 47 USC 230(c)(1) but all of the case >> law I know is related to web sites or hosting providers. > >[ (1)Treatment of publisher or speaker > No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content >provider. ] > >Sounds great on paper, but sort of caught backpage in a quondam, perhaps because they installed filters to begin with. Keep reading and look at 47 USC 230(c)(2). No provider or user of an interactive computer service shall be held liable on account of— (A) any action voluntarily taken in good faith to restrict access to or availability of material that the provider or user considers to be obscene, lewd, lascivious, filthy, excessively violent, harassing, or otherwise objectionable, whether or not such material is constitutionally protected; ... Courts have construed "otherwise objectionable" very broadly. It includes spam filtering. The section Mel has been trying to interpret is different, 17 USC 512(a) which says that if you're carrying traffic in a mechanical way (defined in more detail, see the statute) you're not responsible for copyright violations. This is not even sort of like being a common carrier, of course. >Technically, will anyone else booting customer’s for any offense of TOS be similar is still up for grabs, since it’s basically a political nightmare for >lawyers right now. No, really, it's not. ISPs and CDNs don't have to provide service to anyone. I suppose a lawyer could make a case if a provider refused to provide service to members of a protected class ("we don't serve black people") but the kind of people you find on 8chan aren't a protected class. R's, John From mel at beckman.org Wed Aug 7 04:56:59 2019 From: mel at beckman.org (Mel Beckman) Date: Wed, 7 Aug 2019 04:56:59 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <20190807044011.4826B7B8804@ary.qy> References: <56CBB25E-9A53-4E5E-B2CB-3E769112F516@truenet.com>, <20190807044011.4826B7B8804@ary.qy> Message-ID: > ISPs and CDNs don't have to provide service to anyone. You mean like bakers don’t have to sell cakes to anyone? :) -mel > On Aug 6, 2019, at 9:40 PM, John Levine wrote: > > ISPs and CDNs don't have to provide service to > anyone. From chriztoffer at netravnen.de Wed Aug 7 06:27:23 2019 From: chriztoffer at netravnen.de (Chriztoffer Hansen) Date: Wed, 7 Aug 2019 08:27:23 +0200 Subject: GEO IP Updates In-Reply-To: References: Message-ID: <03d0c29a-b746-1e00-c349-b378fdf7e0da@netravnen.de> Colin Legendre wrote on 06/08/2019 17:10: > We updated... Maxmind, DB-IP, IP Info, IP Geolocation, IPHub. IP2location > > Any others we should update? $DAY_JOB previously had a case. Were it was necessary to contact Akamai. Because they have their own database. -- [ have you enabled IPv6 on something today...? ] [ Chriztoffer Hansen +1 914 3133553 ] [ 0x18dd23c550293098de07052a9dcf2ca008ebd2e8 ] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From martijnschmidt at i3d.net Wed Aug 7 07:48:06 2019 From: martijnschmidt at i3d.net (Martijn Schmidt) Date: Wed, 7 Aug 2019 07:48:06 +0000 Subject: GEO IP Updates In-Reply-To: <03d0c29a-b746-1e00-c349-b378fdf7e0da@netravnen.de> References: , <03d0c29a-b746-1e00-c349-b378fdf7e0da@netravnen.de> Message-ID: Google also has a portal where you can provide a link to a self-published csv geofeed, which is used for some but not all products served from their CDN infrastructure. https://isp.google.com/geo_feed/ They're also working on getting the format standardised in the IETF. I applaud this, because less badly guessed geoip data and more reliably self-published data is better: https://datatracker.ietf.org/doc/html/draft-google-self-published-geofeeds ________________________________ From: NANOG on behalf of Chriztoffer Hansen Sent: 07 August 2019 08:27:23 To: nanog at nanog.org Subject: Re: GEO IP Updates Colin Legendre wrote on 06/08/2019 17:10: > We updated... Maxmind, DB-IP, IP Info, IP Geolocation, IPHub. IP2location > > Any others we should update? $DAY_JOB previously had a case. Were it was necessary to contact Akamai. Because they have their own database. -- [ have you enabled IPv6 on something today...? ] [ Chriztoffer Hansen +1 914 3133553 ] [ 0x18dd23c550293098de07052a9dcf2ca008ebd2e8 ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From daknob.mac at gmail.com Wed Aug 7 09:13:44 2019 From: daknob.mac at gmail.com (DaKnOb) Date: Wed, 7 Aug 2019 12:13:44 +0300 Subject: Contact in ATU Message-ID: Hello, Anyone by any chance has any contact info for ATU in Albania? Any type of contact should probably be fine, from what I’ve seen, not necessarily technical. Thanks, Antonis From tony at swalter.com Wed Aug 7 14:50:19 2019 From: tony at swalter.com (Tony Patti) Date: Wed, 7 Aug 2019 14:50:19 +0000 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org>, <20190807023646.51AB87B7BE3@ary.qy> Message-ID: FYI, Bloomberg BusinessWeek published TODAY a 3,200-word article by Felix Gillette entitled "Section 230 Was Supposed to Make the Internet a Better Place. It Failed" https://www.bloomberg.com/news/features/2019-08-07/section-230-was-supposed-to-make-the-internet-a-better-place-it-failed Tony Patti [SW_logo_HighRes] CIO t: (215) 867-8401 f: (215) 268-7184 e: tony at swalter.com w: www.swalter.com -----Original Message----- From: NANOG On Behalf Of Mel Beckman Sent: Tuesday, August 6, 2019 11:36 PM To: John Levine Cc: nanog at nanog.org Subject: Re: What can ISPs do better? Removing racism out of internet John, Please reread my comments. I did not say “carriers” and specifically excluded the FCC’s definition. I said “Common Carriers”, as defined by Common Law. The DMCA asserts that they must operate as CCs under this definition: in order to get protection under Safe Harbor they must function as a “passive conduit” of information. -mel via cell > On Aug 6, 2019, at 7:36 PM, John Levine > wrote: > > In article <6956E76B-E6B7-409F-A636-C7607BFD881C at beckman.org> you write: >> Mehmet, >> >> I’m not sure if you understand the terms under which ISPs operate as “common carriers”, and thus enjoy immunity from lawsuits due to the acts of their customers. > > ISPs in the U.S. are not carriers and never have been. Even the ISPs > that are subsidaries of telcos, which are common carriers for their > telco operations, are not common carriers for their ISPs. > > This should not come as surprise to anyone who's spent 15 minutes > looking at the relevant law. > > ISPs are probably protected by 47 USC 230(c)(1) but all of the case > law I know is related to web sites or hosting providers. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at invaluement.com Wed Aug 7 15:24:57 2019 From: rob at invaluement.com (Rob McEwen) Date: Wed, 7 Aug 2019 11:24:57 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <20190807023646.51AB87B7BE3@ary.qy> Message-ID: <4c74b997-fc31-8fa1-c92e-6a1861dde5cc@invaluement.com> On 8/7/2019 10:50 AM, Tony Patti wrote: > > FYI, /Bloomberg BusinessWeek/ published _TODAY_ a 3,200-word article > by Felix Gillette entitled* > "Section 230 Was Supposed to Make the Internet a Better Place. It Failed"* > https://www.bloomberg.com/news/features/2019-08-07/section-230-was-supposed-to-make-the-internet-a-better-place-it-failed > > If the whole Section 230 gets deleted - and isn't carefully replaced - then many DNSBLs and spam filters and spam filtering technology providers with get sued out of business (even if just by SLAPP lawsuits suddenly making more progress and costing a fortune in attorney feeds). These costs will then get passed onto consumers in the form of either MUCH WORSE spam filtering, or much higher costs for email hosting services. The same is true for Internet content filters, too. Be careful what you wish for, you might get it! -- Rob McEwen -------------- next part -------------- An HTML attachment was scrubbed... URL: From cra at wpi.edu Wed Aug 7 16:15:09 2019 From: cra at wpi.edu (Anderson, Charles R) Date: Wed, 7 Aug 2019 16:15:09 +0000 Subject: [j-nsp] MX10003 rack size In-Reply-To: References: <29AA198D-CE4F-4ACD-8649-662ED2C34E29@steffann.nl> <29AB273E4AA55645BDC361D90B636F8D01967399A3@exchange01.virtual1.local> Message-ID: <20190807161506.iis2fq7jnv3du32x@angus.ind.wpi.edu> 1000mm deep. APC AR3100 racks are 600mm x 1070mm. APC also makes 1200mm deep ones, and 750mm wide ones, and both together. On Wed, Aug 07, 2019 at 04:12:26PM +0000, Richard McGovern wrote: > Pete "1000 deep rack"?? Is that fathoms __ > > Richard McGovern > Sr Sales Engineer, Juniper Networks > 978-618-3342 > > I’d rather be lucky than good, as I know I am not good > I don’t make the news, I just report it > > > On 8/7/19, 6:20 AM, "Pete Webb" wrote: > > No mate, > I made the same mistake. > Minimum you can get away with is 1000 deep racks, and even then you have to leave the front air filter off. > > Pete > > -----Original Message----- > From: juniper-nsp On Behalf Of Sander Steffann > Sent: 30 July 2019 13:32 > To: nanog ; Juniper List > Subject: [j-nsp] MX10003 rack size > > 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 From bzs at theworld.com Wed Aug 7 19:37:48 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 7 Aug 2019 15:37:48 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <4c74b997-fc31-8fa1-c92e-6a1861dde5cc@invaluement.com> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <20190807023646.51AB87B7BE3@ary.qy> <4c74b997-fc31-8fa1-c92e-6a1861dde5cc@invaluement.com> Message-ID: <23883.10380.444534.380235@gargle.gargle.HOWL> I propose that the RIGHT THING TO DO would be to seek out, promote (to both customers and the public), and support various curation services like netnanny. Promoting the idea that third-party curation is a service one can obtain into the public discussion can only be good. -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From kmedcalf at dessus.com Wed Aug 7 22:34:43 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 07 Aug 2019 16:34:43 -0600 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <23883.10380.444534.380235@gargle.gargle.HOWL> Message-ID: On Wednesday, 7 August, 2019 13:38, bzs at theworld.com wrote: >I propose that the RIGHT THING TO DO would be to seek out, promote >(to >both customers and the public), and support various curation >services like netnanny. IANAP (I Am Not A Psychiatrist) however, persons who, when reading or hearing the words of others cannot control the images which leap, unbidden, into their minds causing them to offend themselves or otherwise instill in themselves a self-created state of distress, should, IMHO, seek professional help from a trained and certified mental health professional who may be able to help them overcome their mental disability either through psychotherapy or the administration of psychoactive drugs. I do not think NetNanny is a certified mental health professional in any jurisdication -- at least not those within the NANOG region. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From bzs at theworld.com Thu Aug 8 00:53:29 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 7 Aug 2019 20:53:29 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: <23883.10380.444534.380235@gargle.gargle.HOWL> Message-ID: <23883.29321.242701.110483@gargle.gargle.HOWL> Netnanny is mostly sold for parents to put on their children's access. You're not thinking this through. Promote third-party curation, those who never want to see content they find disturbing can PURCHASE* that service rather than bugging their congressperson to demand that ISPs provide this for everyone for free by law. * No reason it couldn't be ad-supported but I hope you get my point. On August 7, 2019 at 16:34 kmedcalf at dessus.com (Keith Medcalf) wrote: > > On Wednesday, 7 August, 2019 13:38, bzs at theworld.com wrote: > > >I propose that the RIGHT THING TO DO would be to seek out, promote > >(to >both customers and the public), and support various curation > >services like netnanny. > > IANAP (I Am Not A Psychiatrist) however, persons who, when reading or hearing the words of others cannot control the images which leap, unbidden, into their minds causing them to offend themselves or otherwise instill in themselves a self-created state of distress, should, IMHO, seek professional help from a trained and certified mental health professional who may be able to help them overcome their mental disability either through psychotherapy or the administration of psychoactive drugs. > > I do not think NetNanny is a certified mental health professional in any jurisdication -- at least not those within the NANOG region. > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. > > > > -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From bzs at theworld.com Thu Aug 8 00:55:34 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 7 Aug 2019 20:55:34 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <20190807023646.51AB87B7BE3@ary.qy> <4c74b997-fc31-8fa1-c92e-6a1861dde5cc@invaluement.com> <23883.10380.444534.380235@gargle.gargle.HOWL> Message-ID: <23883.29446.82817.46182@gargle.gargle.HOWL> On August 7, 2019 at 18:43 covici at ccs.covici.com (John Covici) wrote: > Well, I don't want any net nannies sensoring the news I get, any ideas > the nanny does not like I will never see (?) Then you wouldn't buy it. Netnanny exists now, do you use it? No? Would you use it? No. Then nothing would change. P.S. Netnanny is an actual product parents can buy to put a filter on their children's access to the internet. I have no interest, it's just become a term for that kind of thing. > On Wed, 07 Aug 2019 15:37:48 -0400, > bzs at theworld.com wrote: > > > > > > I propose that the RIGHT THING TO DO would be to seek out, promote (to > > both customers and the public), and support various curation services > > like netnanny. > > > > Promoting the idea that third-party curation is a service one can > > obtain into the public discussion can only be good. > > > > -- > > -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* > > -- > Your life is like a penny. You're going to lose it. The question is: > How do > you spend it? > > John Covici wb2una > covici at ccs.covici.com -- -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 mehmet at akcin.net Thu Aug 8 03:02:57 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 7 Aug 2019 20:02:57 -0700 Subject: Mx204 alternative Message-ID: Greetings, I am looking for some suggestions on alternatives to mx204. Any recommendations on something more affordable which can handle full routing tables from two providers? Prefer Juniper but happy to look alternatives. Min 6-8 10G ports are required 1G support required Thanks in advance! Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at wicks.co.nz Thu Aug 8 03:23:37 2019 From: tony at wicks.co.nz (Tony Wicks) Date: Thu, 8 Aug 2019 15:23:37 +1200 Subject: Mx204 alternative In-Reply-To: References: Message-ID: <003801d54d98$ab8697b0$0293c710$@wicks.co.nz> Nokia 7750 sr-1. From: NANOG On Behalf Of Mehmet Akcin Sent: Thursday, 8 August 2019 3:03 PM To: nanog Subject: Mx204 alternative Greetings, I am looking for some suggestions on alternatives to mx204. Any recommendations on something more affordable which can handle full routing tables from two providers? Prefer Juniper but happy to look alternatives. Min 6-8 10G ports are required 1G support required Thanks in advance! Mehmet -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet at akcin.net Thu Aug 8 03:29:50 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 7 Aug 2019 20:29:50 -0700 Subject: Mx204 alternative In-Reply-To: <003801d54d98$ab8697b0$0293c710$@wicks.co.nz> References: <003801d54d98$ab8697b0$0293c710$@wicks.co.nz> Message-ID: Thank you! Something within 2U (max) form factor :) On Wed, Aug 7, 2019 at 8:23 PM Tony Wicks wrote: > Nokia 7750 sr-1. > > > > > > *From:* NANOG *On Behalf Of *Mehmet Akcin > *Sent:* Thursday, 8 August 2019 3:03 PM > *To:* nanog > *Subject:* Mx204 alternative > > > > Greetings, > > > > I am looking for some suggestions on alternatives to mx204. > > > > Any recommendations on something more affordable which can handle full > routing tables from two providers? > > > > Prefer Juniper but happy to look alternatives. > > Min 6-8 10G ports are required > > 1G support required > > > > Thanks in advance! > > > > Mehmet > > -- > > Mehmet > +1-424-298-1903 > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at wicks.co.nz Thu Aug 8 03:32:35 2019 From: tony at wicks.co.nz (Tony Wicks) Date: Thu, 8 Aug 2019 15:32:35 +1200 Subject: Mx204 alternative In-Reply-To: References: <003801d54d98$ab8697b0$0293c710$@wicks.co.nz> Message-ID: <006e01d54d99$eb9d7e80$c2d87b80$@wicks.co.nz> It’s a bit more expensive and higher capability (1.2tb vs 400G) than the MX204. But the form factor and capability is very impressive for a little box. From: Mehmet Akcin Sent: Thursday, 8 August 2019 3:30 PM To: Tony Wicks Cc: nanog Subject: Re: Mx204 alternative Thank you! Something within 2U (max) form factor :) On Wed, Aug 7, 2019 at 8:23 PM Tony Wicks > wrote: Nokia 7750 sr-1. From: NANOG > On Behalf Of Mehmet Akcin Sent: Thursday, 8 August 2019 3:03 PM To: nanog > Subject: Mx204 alternative Greetings, I am looking for some suggestions on alternatives to mx204. Any recommendations on something more affordable which can handle full routing tables from two providers? Prefer Juniper but happy to look alternatives. Min 6-8 10G ports are required 1G support required Thanks in advance! Mehmet -- Mehmet +1-424-298-1903 -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Thu Aug 8 03:33:37 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 7 Aug 2019 23:33:37 -0400 Subject: Mx204 alternative In-Reply-To: References: Message-ID: On 8/7/19 11:02 PM, Mehmet Akcin wrote: > I am looking for some suggestions on alternatives to mx204. > > Any recommendations on something more affordable which can handle full > routing tables from two providers? > > Prefer Juniper but happy to look alternatives. > Min 6-8 10G ports are required > 1G support required Extreme (ex Brocade) SLX9540 will do full tables from a couple providers in a local edge scenario with their "OptiScale" FIB optimization/route caching, but the whole FIB won't fit in hardware. Bandwidth is very generous (up to 48x10G + 6x100G), and prices are reasonable. You wouldn't need any of the stupid port licenses, just the advanced feature license, so it should be about 25-40% more than an MX204 based on public pricing I've seen. That would get you 24x10G + 24x1G (the rest of the hardware is all there just locked out). The SLX9650 will supposedly (if marketing and my SEs are to believed) do 4M IPv4 in hardware FIB, less if you want IPv6, too but still full tables of both with ample room for L2 MACs, next-hops, and MPLS. Bandwidth is, well, "Extreme" at I think 24x25G + 12x100G (25G breakout capable, all 25G also capable of 1G/10G). Pricing is supposedly "about double" a 9540. Be advised that the control plane SOFTWARE is NOT as mature as JunOS. It's being built up rapidly, but there's still a lot of stuff missing. I have not, so far, run into any of the weird glitches that I've seen on older Foundry/Brocade products, though, so that's good. There's also no oddball restrictions about port provisioning like the MX204 has. Control plane HARDWARE is well more than capable with something like 16GB (or maybe 32?) of RAM and a Xeon CPU. There's actually a fully supported option for a guest VM for local analytics, SDN, etc. in remote scenarios. If you just want to push packets, they're nice boxes. If you want "high touch" service provider features, I think you may find them lacking. They're worth looking at, though, if only because of the price/performance ratio. Arista has some similar boxes with similar caveats in terms of infantile software. MX204 is a very nice pizza box router for service providers. I'm not aware of anything quite like it in terms of having a mature control plane. I like the JunOS config language better than Cisco-style that most other folks use. -- Brandon Martin From mehmet at akcin.net Thu Aug 8 03:53:32 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 7 Aug 2019 20:53:32 -0700 Subject: Mx204 alternative In-Reply-To: References: Message-ID: Thank you! Very useful Certainly i have concerns about the software as well On Wed, Aug 7, 2019 at 8:35 PM Brandon Martin wrote: > On 8/7/19 11:02 PM, Mehmet Akcin wrote: > > I am looking for some suggestions on alternatives to mx204. > > > > Any recommendations on something more affordable which can handle full > > routing tables from two providers? > > > > Prefer Juniper but happy to look alternatives. > > Min 6-8 10G ports are required > > 1G support required > > Extreme (ex Brocade) SLX9540 will do full tables from a couple providers > in a local edge scenario with their "OptiScale" FIB optimization/route > caching, but the whole FIB won't fit in hardware. Bandwidth is very > generous (up to 48x10G + 6x100G), and prices are reasonable. You > wouldn't need any of the stupid port licenses, just the advanced feature > license, so it should be about 25-40% more than an MX204 based on public > pricing I've seen. That would get you 24x10G + 24x1G (the rest of the > hardware is all there just locked out). > > The SLX9650 will supposedly (if marketing and my SEs are to believed) do > 4M IPv4 in hardware FIB, less if you want IPv6, too but still full > tables of both with ample room for L2 MACs, next-hops, and MPLS. > Bandwidth is, well, "Extreme" at I think 24x25G + 12x100G (25G breakout > capable, all 25G also capable of 1G/10G). Pricing is supposedly "about > double" a 9540. > > Be advised that the control plane SOFTWARE is NOT as mature as JunOS. > It's being built up rapidly, but there's still a lot of stuff missing. > I have not, so far, run into any of the weird glitches that I've seen on > older Foundry/Brocade products, though, so that's good. There's also no > oddball restrictions about port provisioning like the MX204 has. > Control plane HARDWARE is well more than capable with something like > 16GB (or maybe 32?) of RAM and a Xeon CPU. There's actually a fully > supported option for a guest VM for local analytics, SDN, etc. in remote > scenarios. > > If you just want to push packets, they're nice boxes. If you want "high > touch" service provider features, I think you may find them lacking. > They're worth looking at, though, if only because of the > price/performance ratio. > > Arista has some similar boxes with similar caveats in terms of infantile > software. > > MX204 is a very nice pizza box router for service providers. I'm not > aware of anything quite like it in terms of having a mature control > plane. I like the JunOS config language better than Cisco-style that > most other folks use. > -- > Brandon Martin > -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rubensk at gmail.com Thu Aug 8 04:43:21 2019 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 8 Aug 2019 01:43:21 -0300 Subject: Mx204 alternative In-Reply-To: References: Message-ID: If it's not for an US company, then a Huawei NE-20 could be in order. The entry model fits 2U. Rubens On Thu, Aug 8, 2019 at 12:04 AM Mehmet Akcin wrote: > Greetings, > > I am looking for some suggestions on alternatives to mx204. > > Any recommendations on something more affordable which can handle full > routing tables from two providers? > > Prefer Juniper but happy to look alternatives. > Min 6-8 10G ports are required > 1G support required > > Thanks in advance! > > Mehmet > -- > Mehmet > +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcarpen at network1.net Thu Aug 8 04:46:04 2019 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 8 Aug 2019 00:46:04 -0400 (EDT) Subject: Mx204 alternative In-Reply-To: References: Message-ID: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> If you don't require redundant routing engines, there is nothing from Juniper that will cost less and have the capacity you require. In fact, there really aren't any cheaper MX options at all, other than the kneecapped MX80 and MX104 variants. MX204 is really a nice box. I only wish they had a redundant version. Is price your only concern with the MX204? You might not need the full blown -R or -IR version, so the list price would only be ~$45K. I'm not too familiar with other vendors, so I'll leave that to others. thanks, -Randy ----- On Aug 7, 2019, at 11:02 PM, Mehmet Akcin wrote: > Greetings, > I am looking for some suggestions on alternatives to mx204. > Any recommendations on something more affordable which can handle full routing > tables from two providers? > Prefer Juniper but happy to look alternatives. > Min 6-8 10G ports are required > 1G support required > Thanks in advance! > Mehmet > -- > Mehmet > +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From baldur.norddahl at gmail.com Thu Aug 8 06:33:08 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 8 Aug 2019 08:33:08 +0200 Subject: Mx204 alternative In-Reply-To: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: 45k? No no, the mx204 with enough license to do BGP is more like 20k - 25k or less. It is actually quite cheap, so I doubt the OP will find anything much cheaper without going used or do a software router. I feel it should be mentioned that a Linux box with 4x10G NIC and some random switch as port expander also will be able to fulfil the requirements and for a fraction of any other solution. Regards Baldur tor. 8. aug. 2019 06.47 skrev Randy Carpenter : > If you don't require redundant routing engines, there is nothing from > Juniper that will cost less and have the capacity you require. In fact, > there really aren't any cheaper MX options at all, other than the > kneecapped MX80 and MX104 variants. MX204 is really a nice box. I only wish > they had a redundant version. > > Is price your only concern with the MX204? You might not need the full > blown -R or -IR version, so the list price would only be ~$45K. > > I'm not too familiar with other vendors, so I'll leave that to others. > > thanks, > -Randy > > ----- On Aug 7, 2019, at 11:02 PM, Mehmet Akcin wrote: > > Greetings, > > I am looking for some suggestions on alternatives to mx204. > > Any recommendations on something more affordable which can handle full > routing tables from two providers? > > Prefer Juniper but happy to look alternatives. > Min 6-8 10G ports are required > 1G support required > > Thanks in advance! > > Mehmet > -- > Mehmet > +1-424-298-1903 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcarpen at network1.net Thu Aug 8 07:09:00 2019 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 8 Aug 2019 03:09:00 -0400 (EDT) Subject: Mx204 alternative In-Reply-To: References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: <1328927806.140673.1565248140622.JavaMail.zimbra@network1.net> ~$45k is the US list price... typical discount applies :-) thanks, -Randy ----- On Aug 8, 2019, at 2:33 AM, Baldur Norddahl wrote: > 45k? No no, the mx204 with enough license to do BGP is more like 20k - 25k or > less. It is actually quite cheap, so I doubt the OP will find anything much > cheaper without going used or do a software router. > I feel it should be mentioned that a Linux box with 4x10G NIC and some random > switch as port expander also will be able to fulfil the requirements and for a > fraction of any other solution. > Regards > Baldur > tor. 8. aug. 2019 06.47 skrev Randy Carpenter < [ mailto:rcarpen at network1.net | > rcarpen at network1.net ] >: >> If you don't require redundant routing engines, there is nothing from Juniper >> that will cost less and have the capacity you require. In fact, there really >> aren't any cheaper MX options at all, other than the kneecapped MX80 and MX104 >> variants. MX204 is really a nice box. I only wish they had a redundant version. >> Is price your only concern with the MX204? You might not need the full blown -R >> or -IR version, so the list price would only be ~$45K. >> I'm not too familiar with other vendors, so I'll leave that to others. >> thanks, >> -Randy >> ----- On Aug 7, 2019, at 11:02 PM, Mehmet Akcin < [ mailto:mehmet at akcin.net | >> mehmet at akcin.net ] > wrote: >>> Greetings, >>> I am looking for some suggestions on alternatives to mx204. >>> Any recommendations on something more affordable which can handle full routing >>> tables from two providers? >>> Prefer Juniper but happy to look alternatives. >>> Min 6-8 10G ports are required >>> 1G support required >>> Thanks in advance! >>> Mehmet >>> -- >>> Mehmet >>> +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian at olddog.co.uk Thu Aug 8 10:32:02 2019 From: adrian at olddog.co.uk (Adrian Farrel) Date: Thu, 8 Aug 2019 11:32:02 +0100 Subject: GEO IP Updates In-Reply-To: References: , <03d0c29a-b746-1e00-c349-b378fdf7e0da@netravnen.de> Message-ID: <01a901d54dd4$8818cd70$984a6850$@olddog.co.uk> Hey folk, Martijn Schmidt said. > They're also working on getting the format standardised in the IETF. I > applaud this, because less badly guessed geoip data and more reliably > self-published data is better: > > https://datatracker.ietf.org/doc/html/draft-google-self-published-geofeeds Just a quick note that this document is being advanced for publication as an Independent Stream [1] RFC. That means it is not getting IETF review or consensus and will not be an IETF RFC or any kind of standard. It is important to recognise that not all RFCs are IETF RFCs. Publication on the Independent Stream is a way to produce RFCs that describe proprietary protocols, provide commentary on IETF work, or offer contrary opinions. While the Independent Stream RFCs are held to the same editorial standards as other RFCs, their technical content is not subject to the same level of scrutiny. Reviews of drafts on the Independent Stream are always welcome. You can send comments and thoughts direct to the authors or to me as Independent Submissions Editor via rfc-ise at rfc-editor.org . Thanks, Adrian -- Adrian Farrel Independent Submissions Editor (ISE) mailto: rfc-ise at rfc-editor.org [1] https://datatracker.ietf.org/doc/rfc4846/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at radu-adrian.feurdean.net Thu Aug 8 10:50:25 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Thu, 08 Aug 2019 12:50:25 +0200 Subject: Mx204 alternative In-Reply-To: References: <003801d54d98$ab8697b0$0293c710$@wicks.co.nz> Message-ID: Hi, SR1 (without s) is 2u high, bit it doesn't have 1G ports. It doesn't even have "native" 10G ports. Only 40/100G, with 4x10G optics for 10G. For 1G you would need a 7210 in sattelite mode, which is one extra U + $$$. Otherwise very nice box... On Thu, Aug 8, 2019, at 05:30, Mehmet Akcin wrote: > Thank you! Something within 2U (max) form factor :) > > On Wed, Aug 7, 2019 at 8:23 PM Tony Wicks wrote: > > Nokia 7750 sr-1.____ From eric.kuhnke at gmail.com Thu Aug 8 12:20:39 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Thu, 8 Aug 2019 05:20:39 -0700 Subject: Mx204 alternative In-Reply-To: References: Message-ID: I am not certain on the value of having 1GbE interfaces natively on a $25k plus router in the year 2019. Pair the router with a nice 1RU 1/10GbE switch installed directly next to it with full metro Ethernet layer 2 feature set. Anything that needs a 1GbE inteface, attach it to that switch, give the switch a single 10GbE port to the router, and create the 1Gbps on the router as a subinterface. We have reached the point in 10GbE being so low cost that it should really be the minimum port size for a lot of things. I recently bought an Intel chipset two port SFP+ daughtercard for a Dell server (part c63dv for an old r720) on eBay for $40. On Wed, Aug 7, 2019, 8:04 PM Mehmet Akcin wrote: > Greetings, > > I am looking for some suggestions on alternatives to mx204. > > Any recommendations on something more affordable which can handle full > routing tables from two providers? > > Prefer Juniper but happy to look alternatives. > Min 6-8 10G ports are required > 1G support required > > Thanks in advance! > > Mehmet > -- > Mehmet > +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at ninjabadger.net Thu Aug 8 14:50:37 2019 From: tom at ninjabadger.net (Tom Hill) Date: Thu, 8 Aug 2019 15:50:37 +0100 Subject: Mx204 alternative In-Reply-To: References: Message-ID: <36dc2678-3605-b9c0-8a1a-1f2bbf89308e@ninjabadger.net> On 08/08/2019 04:02, Mehmet Akcin wrote: > > I am looking for some suggestions on alternatives to mx204.  > > Any recommendations on something more affordable which can handle full > routing tables from two providers? > > Prefer Juniper but happy to look alternatives. > Min 6-8 10G ports are required > 1G support required No-one has mentioned it yet, so for completeness big C have the ASR 9901 (not 9001) with traditional router bits in it. A portion of the 10G ports on it are capable of 1/10G. Regards, -- Tom From tom at ninjabadger.net Thu Aug 8 14:57:13 2019 From: tom at ninjabadger.net (Tom Hill) Date: Thu, 8 Aug 2019 15:57:13 +0100 Subject: [j-nsp] MX10003 rack size In-Reply-To: <20190807161506.iis2fq7jnv3du32x@angus.ind.wpi.edu> References: <29AA198D-CE4F-4ACD-8649-662ED2C34E29@steffann.nl> <29AB273E4AA55645BDC361D90B636F8D01967399A3@exchange01.virtual1.local> <20190807161506.iis2fq7jnv3du32x@angus.ind.wpi.edu> Message-ID: <8c950a85-d3ca-ff6c-c394-825a1964982e@ninjabadger.net> On 07/08/2019 17:15, Anderson, Charles R wrote: > 1000mm deep. APC AR3100 racks are 600mm x 1070mm. APC also makes > 1200mm deep ones, and 750mm wide ones, and both together. Unsure as to why this was cross-posted, but... Many vendors do these sizes now. 600x1200 is rather useful when you have meter-long servers and need to get four 0U PDUs in at the back. :) Neatly fits on to common 600mm² footprints, too. I quite liked 750mm APCs, but last I looked I recall that they've shifted to 800mm wide now? Instead of having to do 4x750 racks in 5x600 footprints to line them up, you can now do 3x800 racks in 4x600 footprints. Fewer snowflake racks messing up the rack/footprint alignment, and you get more room per rack. -- Tom From bellwood at inoc.net Wed Aug 7 13:40:11 2019 From: bellwood at inoc.net (Brian Ellwood) Date: Wed, 7 Aug 2019 09:40:11 -0400 Subject: Salliemae.com Message-ID: Any domain/DNS administrators for Salliemae on the list that could contact me directly or perhaps take a look at the DNSSEC implementation on the domain? Resolvers validating DNSSEC are unable to resolve the domain: http://dnsviz.net/d/salliemae.com/dnssec/ — Brian Ellwood Senior Systems Engineer INOC Data Centers O: 518-689-4350 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3880 bytes Desc: not available URL: From ggrabow62 at gmail.com Wed Aug 7 14:15:26 2019 From: ggrabow62 at gmail.com (Greg Grabowski) Date: Wed, 7 Aug 2019 07:15:26 -0700 Subject: Next Generation Lan Message-ID: Hello Networkers, We are looking for something to manage our LAN. This would include all the usual suspects. PSIRT or similar notifications on code, automation of networks, micro segmentation all in an overlay fabric, streaming telemetry. Of course Cisco has DNA Center which is not to impressive at this time. Maybe when it's more mature, we would also like to be vendor neutral if possible. Just wondering what other folks are doing to accommodate the next generation lan. EVPN, VXLAN? etc. We are running routed access as well. Thanks in advance, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From covici at ccs.covici.com Wed Aug 7 22:43:49 2019 From: covici at ccs.covici.com (John Covici) Date: Wed, 07 Aug 2019 18:43:49 -0400 Subject: What can ISPs do better? Removing racism out of internet In-Reply-To: <23883.10380.444534.380235@gargle.gargle.HOWL> References: <6956E76B-E6B7-409F-A636-C7607BFD881C@beckman.org> <20190807023646.51AB87B7BE3@ary.qy> <4c74b997-fc31-8fa1-c92e-6a1861dde5cc@invaluement.com> <23883.10380.444534.380235@gargle.gargle.HOWL> Message-ID: Well, I don't want any net nannies sensoring the news I get, any ideas the nanny does not like I will never see (?) On Wed, 07 Aug 2019 15:37:48 -0400, bzs at theworld.com wrote: > > > I propose that the RIGHT THING TO DO would be to seek out, promote (to > both customers and the public), and support various curation services > like netnanny. > > Promoting the idea that third-party curation is a service one can > obtain into the public discussion can only be good. > > -- > -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* -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una covici at ccs.covici.com From anushah at icsi.berkeley.edu Thu Aug 8 14:07:30 2019 From: anushah at icsi.berkeley.edu (Anushah Hossain) Date: Thu, 8 Aug 2019 10:07:30 -0400 Subject: Research project on blacklists Message-ID: Hi all, My colleagues and I at UC Berkeley and the International Computer Science Institute are working on a project evaluating third-party blacklists. As part of that, we're interested in hearing how you utilize them, and what you perceive as their strengths and weaknesses. If you have five to ten minutes and are interested in sharing your thoughts, you can fill out our anonymous survey here, or respond to me directly off-list: https://berkeley.qualtrics.com/jfe/form/SV_200mg5hnQiAOgUl There is also an option in the survey to opt-in to receiving a notification once the research is made public. Apologies if you received this message before! We've tried to minimize cross-posting as we realize several groups share members. Best, Anushah -- Anushah Hossain, PhD Student Energy and Resources Group, UC Berkeley -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj at pcguys.us Thu Aug 8 17:35:09 2019 From: tj at pcguys.us (TJ Trout) Date: Thu, 8 Aug 2019 10:35:09 -0700 Subject: Ookla geo IP data contact? Message-ID: Has anyone had success with getting Ookla / Maxmind to update subnets whois data? I've submitted the correction request with Maxmind ten times over the last 5 years and all of our resources still show the previous allocation owner as the 'isp' when visiting speed test.net Thanks TJ Trout Volt Broadband -------------- next part -------------- An HTML attachment was scrubbed... URL: From spoofer-info at caida.org Thu Aug 8 17:00:05 2019 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Thu, 8 Aug 2019 10:00:05 -0700 Subject: Spoofer Report for NANOG for Jul 2019 Message-ID: <201908081700.x78H05ZI003270@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 Jul 2019: ASN Name Fixed-By 2828 XO-AS15 2019-07-12 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Jul 2019: ASN Name First-Spoofed Last-Spoofed 6939 HURRICANE 2016-02-22 2019-07-27 577 BACOM 2016-03-09 2019-07-06 209 CENTURYLINK-US-LEGACY-QWEST 2016-08-16 2019-07-31 6128 CABLE-NET-1 2016-09-03 2019-07-30 27364 ACS-INTERNET 2016-09-27 2019-07-25 20412 CLARITY-TELECOM 2016-09-30 2019-07-29 6181 FUSE-NET 2016-10-10 2019-07-27 25787 ROWE-NETWORKS 2016-10-21 2019-07-27 32440 LONI 2016-11-03 2019-07-26 2828 XO-AS15 2016-11-08 2019-07-29 12083 WOW-INTERNET 2016-11-09 2019-07-29 13427 SOFTCOM-INTERNET-COMMUNICATION 2016-11-14 2019-07-31 21832 KELLINCOM-1 2017-02-03 2019-07-31 18451 LESNET 2017-02-22 2019-07-23 26253 SCINTERNET 2017-06-30 2019-07-08 63296 AMARILLO-WIRELESS 2017-09-01 2019-07-25 546 PARSONS-PGS-1 2017-11-20 2019-07-30 54540 INCERO 2018-01-15 2019-07-29 12222 AKAMAI 2018-02-14 2019-07-10 4201 ORST 2018-04-19 2019-07-30 225 VIRGINIA 2018-06-18 2019-07-30 33452 RW 2018-09-19 2019-07-28 20448 VPNTRANET-LLC 2018-09-20 2019-07-25 393437 KLAYER 2018-12-21 2019-07-17 63275 RADIOWIRE 2019-02-07 2019-07-31 8047 GCI 2019-04-11 2019-07-31 10745 ARIN-ASH-CHA 2019-04-29 2019-07-25 6058 NORTHWESTEL-INC 2019-05-06 2019-07-31 46573 AS-GLobalf 2019-05-16 2019-07-01 138576 2019-05-21 2019-07-27 19751 CCRTC 2019-06-06 2019-07-29 33387 DATASHACK 2019-06-06 2019-07-26 16787 CHARTER-16787 2019-06-17 2019-07-29 29933 OFF-CAMPUS-TELECOMMUNICATIONS 2019-07-15 2019-07-15 36728 EMERYTELCOM 2019-07-26 2019-07-26 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 josh at imaginenetworksllc.com Thu Aug 8 18:01:44 2019 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 8 Aug 2019 14:01:44 -0400 Subject: Ookla geo IP data contact? In-Reply-To: References: Message-ID: The name is from WHOIS records. The location is from Maxmind. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Aug 8, 2019 at 1:36 PM TJ Trout wrote: > Has anyone had success with getting Ookla / Maxmind to update subnets > whois data? I've submitted the correction request with Maxmind ten times > over the last 5 years and all of our resources still show the previous > allocation owner as the 'isp' when visiting speed test.net > > Thanks > > TJ Trout > Volt Broadband > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at wicks.co.nz Thu Aug 8 18:40:01 2019 From: tony at wicks.co.nz (Tony Wicks) Date: Fri, 9 Aug 2019 06:40:01 +1200 Subject: Mx204 alternative In-Reply-To: References: <003801d54d98$ab8697b0$0293c710$@wicks.co.nz> Message-ID: <005501d54e18$b1cd6fb0$15684f10$@wicks.co.nz> Yes, good point, I was under the impression that it would take the 12 port 10/1 mda-e card but on looking closer it appears it only supports the high capacity mda-e-xp (6x100/40/10 ports or 12x100/40/10 ports) cards. This means, as you say if you want physical 10G or lower ports then a 7210-sas-sx64 would be needed which is less than ideal. -----Original Message----- From: NANOG On Behalf Of Radu-Adrian Feurdean Sent: Thursday, 8 August 2019 10:50 PM To: nanog at nanog.org Subject: Re: Mx204 alternative Hi, SR1 (without s) is 2u high, bit it doesn't have 1G ports. It doesn't even have "native" 10G ports. Only 40/100G, with 4x10G optics for 10G. For 1G you would need a 7210 in sattelite mode, which is one extra U + $$$. Otherwise very nice box... From tarko at lanparty.ee Thu Aug 8 18:55:08 2019 From: tarko at lanparty.ee (Tarko Tikan) Date: Thu, 8 Aug 2019 21:55:08 +0300 Subject: Mx204 alternative In-Reply-To: <005501d54e18$b1cd6fb0$15684f10$@wicks.co.nz> References: <003801d54d98$ab8697b0$0293c710$@wicks.co.nz> <005501d54e18$b1cd6fb0$15684f10$@wicks.co.nz> Message-ID: <4bac344d-5af4-1155-28ac-98d34e8b2954@lanparty.ee> hey, > This > means, as you say if you want physical 10G or lower ports then a> 7210-sas-sx64 would be needed which is less than ideal. Or you could talk to your account team, there are some new MDAs coming for IOM-5 and SR-1 that might suit the 10G/1G requirements without breakout or satellite. -- tarko From kmedcalf at dessus.com Thu Aug 8 19:31:03 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 08 Aug 2019 13:31:03 -0600 Subject: Research project on blacklists In-Reply-To: Message-ID: Cannot access your website. Just has a spinning colostomy bag. Too much malicious javascript and malicious trackers. If you expect people to visit the website, perhaps you should make it more useable, because at the moment, it is completely and utterly useless! And there is no way I am going to turn off security in order to access crap promulgated by idiots! -- 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 Anushah >Hossain >Sent: Thursday, 8 August, 2019 08:08 >To: nanog at nanog.org >Subject: Research project on blacklists > >Hi all, > >My colleagues and I at UC Berkeley and the International Computer >Science Institute are working on a project evaluating third-party >blacklists. As part of that, we're interested in hearing how you >utilize them, and what you perceive as their strengths and >weaknesses. If you have five to ten minutes and are interested in >sharing your thoughts, you can fill out our anonymous survey here, or >respond to me directly off-list: >https://berkeley.qualtrics.com/jfe/form/SV_200mg5hnQiAOgUl > >There is also an option in the survey to opt-in to receiving a >notification once the research is made public. > >Apologies if you received this message before! We've tried to >minimize cross-posting as we realize several groups share members. > >Best, >Anushah > >-- > >Anushah Hossain, PhD Student >Energy and Resources Group, UC Berkeley From jhellenthal at dataix.net Thu Aug 8 19:43:21 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Thu, 8 Aug 2019 14:43:21 -0500 Subject: Research project on blacklists In-Reply-To: References: Message-ID: <5B2E79EB-4CE9-4F7C-9207-4BA2FDC5C39D@dataix.net> Just as well as the proper signature divider in an email is actually “dash dash space” \o/ Site works just fine. Doubt javascript here is of any concern to anyone whatsoever. Just sayin > On Aug 8, 2019, at 14:31, Keith Medcalf wrote: > > > Cannot access your website. Just has a spinning colostomy bag. Too much malicious javascript and malicious trackers. > > If you expect people to visit the website, perhaps you should make it more useable, because at the moment, it is completely and utterly useless! > > And there is no way I am going to turn off security in order to access crap promulgated by idiots! > > -- > 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 Anushah >> Hossain >> Sent: Thursday, 8 August, 2019 08:08 >> To: nanog at nanog.org >> Subject: Research project on blacklists >> >> Hi all, >> >> My colleagues and I at UC Berkeley and the International Computer >> Science Institute are working on a project evaluating third-party >> blacklists. As part of that, we're interested in hearing how you >> utilize them, and what you perceive as their strengths and >> weaknesses. If you have five to ten minutes and are interested in >> sharing your thoughts, you can fill out our anonymous survey here, or >> respond to me directly off-list: >> https://berkeley.qualtrics.com/jfe/form/SV_200mg5hnQiAOgUl >> >> There is also an option in the survey to opt-in to receiving a >> notification once the research is made public. >> >> Apologies if you received this message before! We've tried to >> minimize cross-posting as we realize several groups share members. >> >> Best, >> Anushah >> >> -- >> >> Anushah Hossain, PhD Student >> Energy and Resources Group, UC Berkeley > > > — J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume. From amitchell at isipp.com Thu Aug 8 19:50:17 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Thu, 8 Aug 2019 13:50:17 -0600 Subject: Research project on blacklists In-Reply-To: <5B2E79EB-4CE9-4F7C-9207-4BA2FDC5C39D@dataix.net> References: <5B2E79EB-4CE9-4F7C-9207-4BA2FDC5C39D@dataix.net> Message-ID: RESEARCHER'S NOTES, DAY 1: I and my colleagues have observed the operators and patrons of blacklists in the wild. They appear to be hostile and combative. We hypothesize that they will have trouble mating. --- From rfg at tristatelogic.com Thu Aug 8 19:53:45 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 08 Aug 2019 12:53:45 -0700 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 Message-ID: <18117.1565294025@segfault.tristatelogic.com> Corporate identity theft is a simple ploy which may be used to illicitly obtain valuable IPv4 address space. Actual use of this fradulent ploy was first described publicly in April, 2008 (https://wapo.st/2YLEhlZ). Quite simply, a party bent on undertaking this ploy may just search the publicly available IP block WHOIS records, looking for abandoned and unrouted IPv4 address blocks belonging to companies or organizations which no longer exist. Upon finding any such, the thief may simply undertake to formally register, with relevant government authorities, a new corporate entity with the same or a very similar name as the now defunct entity that is still listed in the WHOIS records as the registrant of the coveted IPv4 address block(s). Note that so-called "legacy" address blocks, i.e. those which were assigned prior to the formation of ARIN in early 1997, are especially prized by IPv4 address thieves because such blocks may be less subject to effective control or regulation by Regional Internet Registries. Publicly available evidence strongly suggests that a corporate identity theft has occurred with respect to a former Delaware corporate entity known as Azuki, LLC and also with respect to its valuable legacy IPv4 address block, 216.179.128.0/17. The corporate search function of the Delaware Secretary of State's web site may be used to obtain records relevant to corporate entities registered in Delaware: https://icis.corp.delaware.gov/Ecorp/EntitySearch/NameSearch.aspx At present, the Delaware SoS's web site indicates that there are or have been two different corporate entities, both named Azuki, LLC, that have been registered in the State of Delaware. The file numbers for these entities are 2810116 and 4751384. The former entity was first registered in Delaware on or about 10/20/1997. It's current operating status cannot be known without paying a fee. My own personal speculation is that it most likely ceased operation well more than a decade ago. The latter entity was registered in Delaware on or about 11/9/2009. According to the current live ARIN WHOIS record for the 216.179.128.0/17 address block (NET-216-179-128-0-1), this block was first allocated by ARIN to Azuki, LLC on or about 1999-01-07. Quite obviously, this assignment must have been made by ARIN to the original 1997 Azuki, LLC because the one that was registered in Delaware in 2009 did not yet exist at that time. Nontheless the mailing address currently present in the ARIN WHOIS record for the 216.179.128.0/17 IPv4 address block, and the one which is also present in the ARIN WHOIS record for the 2009 vintage ASN, AS13389 (Azuki, LLC), i.e. 3500 South DuPont Hwy, Dover, DE, 19901, matches exactly with the address given in Delaware corporate records for the particular Azuki, LLC that was registered in Delaware in 2009. (The corporate address that is still on file in Delaware for the original 1997 Azuki, LLC is located in a different Delaware city altogether.) These evident inconsistancies, by themselves, are strongly indicative of a probable case of corporate identity theft. Additional indicators are however also present in this case. In particular, the contact email address for both the Azuki, LLC ASN (AS13389) and the Azuki, LLC IPv4 address block (216.179.128.0/17), i.e. tech_dep (at) azukinet.com, make reference to the azukinet.com domain which was, according to the relevant GoDaddy WHOIS record, registered anew on or about 2011-05-12, some twelve years -after- the original assignment, by ARIN, of the 216.179.128.0/17 block to Azuki, LLC. The absence of evidence of the contnuous registration of this one and only contact domain name since the original 1999 assignment, by ARIN, of the 216.179.128.0/17 address block also tends to support the theory that this valuable address block has been illicitly and perhaps illegally appropriated by some party or parties unknown, and specifically via the fradulent ruse of a corporate identity theft. Quite simply, my theory is that following the demise of the original Azuki, LLC, sometime in the 2000s, some enterprising crook registered the domain name azukinet.com in order to successfully impersonate the actual and original Azuki, LLC, specifically when interacting with ARIN staff members. This simple ruse appears to have worked successfully for its intended purpose. Additionally, attempts to call the contact phone number for Azuki, LLC, (+1-213-304-6809) as currently listed in both the relevant ASN and the relevant IP block WHOIS records, during normal business hours, Eastern Daylight Time, yield only an anonymous answering machine recording. (The recorded message does not even state the company name.) This is yet another indicator of possible deliberate deception. Last but not least, the widely-respected Spamhaus anti-spam organization has had the entirety of the 216.179.128.0/17 block listed on its anti-spam SBL list since 2019-06-08, i.e. two full months, dating backwards from today: https://www.spamhaus.org/sbl/query/SBL103083 This listing, together with additional data from passive DNS and reverse DNS scans suggest that the 216.179.128.0/17 block has been and is being used for less than entirely admirable purposes. This is yet another persuasive indicator of the possible/probable theft of the block. I will shortly be informing both hostmaster (at) arin.net and also the folks at Spamhaus of all of the above factual findings. I did however want to share this information also with the NANOG community. Some or all of you may wish to drop all packets from addresses currently announced by AS13389, and/or may wish to encourage the direct peers of AS13389 to review those peering arrangements. Of course, my exposition of all of the above facts and indicators may perhaps also serve to further educate members of the community regarding what to look for when and if suspicions are cast upon a particular IP block or ASN. In the 2008 case referenced above, which involved self-evident corporate identity theft as a ruse to steal IPv4 address assets, ARIN apparently elected not to actively seek the involvement of law enforcement, even though the multiple clearly fraudulent actions undertaken in that case were altogether apparent and were clearly perpetrated quite deliberately and directly against ARIN. In multiple more recent instances in which ARIN has, allegedly, been targeted and defrauded, ARIN appears to have become more proactive in seeking the involvement of criminal law enforcement. Specifically, in addition to the well-publicized, notorious, and ongoing "Micfo" case, a less well reported federal criminal case (3:18-cr-04683-GPC), filed the Southern District of California last year, is currently ongoing. This case also and likewise attempts to hold to account, criminally, a different set of actors who also are alleged to have perpetrated a rather elaborate fraud against ARIN for the purpose of illicitly obtaining control over a number of IPv4 address blocks. Personally, I am gratified that ARIN is nowadays taking this more forward leaning posture towards those criminal actors who would attempt to use fraud and deception to surreptitiously obtain IPv4 address blocks. I do also hope that if the tenative conclusions of this public report are borne out by subsequent investigation, that ARIN will again and likewise seek an appropriate response from elements of the criminal law enforcement community. We cannot have and should not have these kinds of events happening again and again. Some appropriate deterrence against ALL of these kinds of crooks is therefore no longer optional. Regards, rfg From ryan.landry at gmail.com Thu Aug 8 19:55:17 2019 From: ryan.landry at gmail.com (Ryan Landry) Date: Thu, 8 Aug 2019 12:55:17 -0700 Subject: Research project on blacklists In-Reply-To: References: Message-ID: Anushah, I'm replying simply to inform you that your site works just fine, in multiple browsers, with and without ad/script blockers in place, in hopes to counteract the particularly unwelcoming email by Mr. Medcalf. Minus a handful of smaller voices, you should hopefully find our community to be more supportive. Good luck on your research project. -Ryan Landry On Thu, Aug 8, 2019 at 9:56 AM Anushah Hossain wrote: > Hi all, > > My colleagues and I at UC Berkeley and the International Computer Science > Institute are working on a project evaluating third-party blacklists. As > part of that, we're interested in hearing how you utilize them, and what > you perceive as their strengths and weaknesses. If you have five to ten > minutes and are interested in sharing your thoughts, you can fill out our > anonymous survey here, or respond to me directly off-list: > https://berkeley.qualtrics.com/jfe/form/SV_200mg5hnQiAOgUl > > There is also an option in the survey to opt-in to receiving a > notification once the research is made public. > > Apologies if you received this message before! We've tried to minimize > cross-posting as we realize several groups share members. > > Best, > Anushah > > -- > Anushah Hossain, PhD Student > Energy and Resources Group, UC Berkeley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmedcalf at dessus.com Thu Aug 8 20:05:11 2019 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 08 Aug 2019 14:05:11 -0600 Subject: Research project on blacklists In-Reply-To: <5B2E79EB-4CE9-4F7C-9207-4BA2FDC5C39D@dataix.net> Message-ID: <329670da8919704285b15222b68c8c34@mail.dessus.com> On Thursday, 8 August, 2019 13:43, J. Hellenthal wrote: >Just as well as the proper signature divider in an email is actually >“dash dash space” >\o/ >Site works just fine. Doubt javascript here is of any concern to >anyone whatsoever. >Just sayin qualtics.com loads a blacklisted malicious tracker from itself. The fact that it is the first party does not detract from the fact it is loading a malicious tracker and that the loading of that malicious tracking javascript is blocked. Blocking the tracker precludes the rest of the page from "working". And yes, I know the sig seperator is -- (dash dash space). Are you saying that my MUA is buggering it up again? -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. From lyle at lcrcomputer.net Thu Aug 8 20:09:06 2019 From: lyle at lcrcomputer.net (Lyle Giese) Date: Thu, 8 Aug 2019 15:09:06 -0500 Subject: Research project on blacklists In-Reply-To: References: <5B2E79EB-4CE9-4F7C-9207-4BA2FDC5C39D@dataix.net> Message-ID: This is one of the best and funnest emails I have seen in a long time! Thank you, Anne! Lyle Giese On 8/8/2019 2:50 PM, Anne P. Mitchell, Esq. wrote: > RESEARCHER'S NOTES, DAY 1: > > I and my colleagues have observed the operators and patrons of blacklists in the wild. They appear to be hostile and combative. We hypothesize that they will have trouble mating. > > --- From lee.howard at retevia.net Thu Aug 8 20:15:01 2019 From: lee.howard at retevia.net (Lee Howard) Date: Thu, 8 Aug 2019 16:15:01 -0400 Subject: MAP-E In-Reply-To: References: Message-ID: <8475bfe9-9c93-7983-1a45-b46daeafc632@retevia.net> On 8/2/19 1:10 PM, JORDI PALET MARTINEZ via NANOG wrote: > > The cost of sharing IPs in a static way, is that services such as Sony > Playstation Network will put those addresses in the black list, so you > need to buy more addresses. This hasn’t been the case for > 464XLAT/NAT64, which shares the addresses dynamically. > > Furthermore, if some users need less ports than others, you > “infra-utilize” those addresses, which again is not the case for > 464XLAT/NAT64. Each user gets automatically as many ports as he needs > at every moment. > > So, you save money in terms of addresses, that you can invest in a > couple of servers running a redundant NAT64 setup > (https://www.jool.mx/en/session-synchronization.html). Those servers > can be actually VMs, so you don’t need dedicated hardware, especially > because when you deploy IPv6 with 464XLAT, typically 75% (and going > up) of you traffic will be IPv6 and only 25% will go thru the NAT64. > You work on much smaller networks than I do if a "couple of servers running Jool" can handle your load.  Jool is great, and the team that built it is great, but a couple of 10Gbps NICs on a pizza box doesn't go very far. I've tried 100Gbps and can't get the throughput with any normal CPU. Hoping to get back to it and run some actual measurements. Lee > Regards, > > Jordi > > @jordipalet > > El 2/8/19 18:24, "NANOG en nombre de Baldur Norddahl" > en nombre de > baldur.norddahl at gmail.com > escribió: > > The goal is to minimize cost. Assuming 4 bits for the MAP routing (16 > users sharing one IPv4), leaving 12 bits for customer ports (4096 > ports) and a current price of USD 20 per IPv4 address, this gives a > cost of USD 1.25 per user for a fully redundant solution. For us it is > even cheaper as we can recirculate existing address space. > > Regards, > > Baldur > > On Fri, Aug 2, 2019 at 5:32 PM JORDI PALET MARTINEZ > > wrote: > > I understand that, but the inconvenient is the fix allocation of > ports per client, and not all the clients use the same number of > ports. Every option has good and bad things. > > MAP is less efficient in terms of maximizing the “use” of the > existing IPv4 addresses. > > https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ > > Regards, > > Jordi > > @jordipalet > > El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" > en > nombre de baldur.norddahl at gmail.com > > escribió: > > Hi Jordi > > My alternative to MAP-E is plain old NAT 444 dual stack. I am > trying to avoid the expense and operative nightmare of having to > run a redundant NAT server setup with thousands of users. MAP is > the only alternative that avoids a provider run NAT server. > > Regards, > > Baldur > > On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG > > wrote: > > Ask the vendor to support RFC8585. > > Also, you can do it with OpenWRT. > > I think 464XLAT is a better option and both of them are > supported by OpenWRT. > > You can also use OpenSource (Jool) for the NAT64. > > Regards, > > Jordi > > @jordipalet > > El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" > en > nombre de baldur.norddahl at gmail.com > > escribió: > > Hello > > Are there any known public deployments of MAP-E? What about > CPE routers with support? > > The pricing on IPv4 is now at USD 20/address so I am thinking > we are forced to go the CGN route going forward. Of all the > options, MAP-E appears to be the most elegant. Just add/remove > some more headers on a packet and route it as normal. No need > to invest in anything as our core routers can already do that. > No worries about scale. > > BUT - our current CPE has zero support. We are too small that > they will make this feature just for us, so I need to convince > them there is going to be a demand. Alternatively I need to > find a different CPE vendor that has MAP-E support, but are > there any? > > What is holding MAP-E back?  In my view MAP-E could be the end > game for IPv4. Customers get full IPv6 and enough of IPv4 to > be somewhat compatible. The ISP networks are not forced to do > a lot of processing such as CGN otherwise requires. > > I read some posts from Japan where users are reporting a > deployment of MAP-E. Anyone know about that? > > Regards, > > Baldur > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be > privileged or confidential. The information is intended to be > for the exclusive use of the individual(s) named above and > further non-explicilty authorized disclosure, copying, > distribution or use of the contents of this information, even > if partially, including attached files, is strictly prohibited > and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even > if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must > reply to the original sender to inform about this > communication and delete it. > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be > privileged or confidential. The information is intended to be for > the exclusive use of the individual(s) named above and further > non-explicilty authorized disclosure, copying, distribution or use > of the contents of this information, even if partially, including > attached files, is strictly prohibited and will be considered a > criminal offense. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, > is strictly prohibited, will be considered a criminal offense, so > you must reply to the original sender to inform about this > communication and delete it. > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents of > this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lee.howard at retevia.net Thu Aug 8 20:18:08 2019 From: lee.howard at retevia.net (Lee Howard) Date: Thu, 8 Aug 2019 16:18:08 -0400 Subject: MAP-E In-Reply-To: References: Message-ID: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> On 8/2/19 11:39 AM, Jay Hanke wrote: > Is there a summary presentation someplace laying out the options that > are active in the wild with some deployment stats? I can't think of a public presentation off the top of my head that explains how each major transition technology works, and the pros and cons of each. There must be one, but it's hard to cover the major options in an hour. If you want to know who is using any given transition technology, there's this crowd-sourced list: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0 Very brief summary of options: NAT444. Your basic NAT, plus NAT again. You really need to deploy IPv6, too, or all your traffic will go through a translator (everything else below assumes native IPv6 is deployed). State information can get expensive. Well understood. Dual-stack Lite. CPE sends IPv4 traffic through an IPv6 tunnel (softwire) to a pre-configured DS-Lite box, which does NAT44. Works fine, deployed at scale (see sheet above), but keeping state on lots of NAT44 can get expensive at scale. NAT64. IPv6-only to users. DNS resolver given in provisioning information is a DNS64 server. When it does a lookup but there's no AAAA, it invents one based on the A record (e.g., 2001:db8:64::). The IPv6 prefix in the invented AAAA is actually a NAT64 translator. Pro: no CPE support required, well understood. Con: No support for IPv4-only stuff in the prem, breaks DNSSEC. 464xlat. IPv6-only between CE and NAT64. Any IPv4 traffic the CPE receives, it translates to IPv6 and forwards to a destination that's the NAT64 server, which translates again. Pro: widely deployed at scale on mobile networks. Con: Very little CPE support in home routers. MAP-T, MAP-E. IPv6-only between CE and Border Relay (BR). CPE is provisioned with an IPv4 address and a range of ports. It does basic NAT44, but only uses the reserved ports. Then it translates to IPv6 (MAP-T) or encapsulates in IPv6 (MAP-E) and forwards to the configured Border Relay (BR), which changes it to IPv4. Pro: Stateless, very efficient. Con: Very little CPE support in home routers. Jordi is going to tell me there's plenty of support for 464xlat. However, you can't go into any old electronics store in North America and buy a home gateway with support for 464xlat or MAP. You can't buy them directly from a vendor, unless you're large enough to request a specific firmware build. Yes, you can get support from OpenWRT, but that's probably not how you want your support team spending their time. CPE support is the next big frontier in IPv6 deployment. Lee > > On Fri, Aug 2, 2019 at 10:34 AM JORDI PALET MARTINEZ via NANOG > wrote: >> I understand that, but the inconvenient is the fix allocation of ports per client, and not all the clients use the same number of ports. Every option has good and bad things. >> >> >> >> MAP is less efficient in terms of maximizing the “use” of the existing IPv4 addresses. >> >> >> >> https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ >> >> >> >> >> >> Regards, >> >> Jordi >> >> @jordipalet >> >> >> >> >> >> >> >> El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" escribió: >> >> >> >> Hi Jordi >> >> >> >> My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid the expense and operative nightmare of having to run a redundant NAT server setup with thousands of users. MAP is the only alternative that avoids a provider run NAT server. >> >> >> >> Regards, >> >> >> >> Baldur >> >> >> >> >> >> On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG wrote: >> >> Ask the vendor to support RFC8585. >> >> >> >> Also, you can do it with OpenWRT. >> >> >> >> I think 464XLAT is a better option and both of them are supported by OpenWRT. >> >> >> >> You can also use OpenSource (Jool) for the NAT64. >> >> >> >> Regards, >> >> Jordi >> >> @jordipalet >> >> >> >> >> >> >> >> El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" escribió: >> >> >> >> Hello >> >> >> >> Are there any known public deployments of MAP-E? What about CPE routers with support? >> >> >> >> The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to go the CGN route going forward. Of all the options, MAP-E appears to be the most elegant. Just add/remove some more headers on a packet and route it as normal. No need to invest in anything as our core routers can already do that. No worries about scale. >> >> >> >> BUT - our current CPE has zero support. We are too small that they will make this feature just for us, so I need to convince them there is going to be a demand. Alternatively I need to find a different CPE vendor that has MAP-E support, but are there any? >> >> >> >> What is holding MAP-E back? In my view MAP-E could be the end game for IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP networks are not forced to do a lot of processing such as CGN otherwise requires. >> >> >> >> I read some posts from Japan where users are reporting a deployment of MAP-E. Anyone know about that? >> >> >> >> Regards, >> >> >> >> Baldur >> >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> > From valdis.kletnieks at vt.edu Thu Aug 8 20:22:22 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Thu, 08 Aug 2019 16:22:22 -0400 Subject: Research project on blacklists In-Reply-To: References: Message-ID: <141757.1565295742@turing-police> On Thu, 08 Aug 2019 13:31:03 -0600, "Keith Medcalf" said: > Cannot access your website. Just has a spinning colostomy bag. I'm almost afraid to ask if that's the site itself doing javascript/CSS, or the browser, or a browser extension, or if the Unicode guys have totally gone off the deep end on the emoji pages... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From jayhanke at gmail.com Thu Aug 8 20:55:02 2019 From: jayhanke at gmail.com (Jay Hanke) Date: Thu, 8 Aug 2019 15:55:02 -0500 Subject: MAP-E In-Reply-To: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> References: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> Message-ID: > I can't think of a public presentation off the top of my head that > explains how each major transition technology works, and the pros and > cons of each. There must be one, but it's hard to cover the major > options in an hour. Actually your post is better than a presentation. I was quite surprised at the adoption rate of DS-Lite. There must be some pretty decent B4 implementations with that many operators deployed. Even though the spreadsheet is small sample size, there isn't much DS-lite deployment in the US. So from 10k feet, MAP-E is basically the same thing as DS-Lite except for the location of the NAT? From lstewart at inap.com Thu Aug 8 21:00:02 2019 From: lstewart at inap.com (Landon Stewart) Date: Thu, 8 Aug 2019 14:00:02 -0700 Subject: How often does Google's Safe Browsing system expire URLs that are 404? Message-ID: Hello, Numerous customers that have had phishing issues reported to them as a result of Google’s Safe Browsing program have taken care of said issues. The URL(s) reported to them either return a 404 or 5xx error but the URL stays listed, according to the GSB’s API, for weeks afterwards. Does anyone know: 1) Is there some kind of expiry time on URLs flagged as unsafe by GSB 2) Is there some way for *us* (the provider) to trigger a review of the URL to speed this process up? Harassing the client to login to the webmaster portal and request a review can be a cat herding exercise. Thanks for any info you might have. — Landon Stewart Lead Analyst - Abuse and Security Management INAP® 📧 lstewart at inap.com 🌍 www.inap.com -------------- 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 tim.h at bendtel.com Thu Aug 8 21:06:54 2019 From: tim.h at bendtel.com (Tim Howe) Date: Thu, 8 Aug 2019 14:06:54 -0700 Subject: Ookla geo IP data contact? In-Reply-To: References: Message-ID: <20190808140654.232ac1c7@Morty> On Thu, 8 Aug 2019 10:35:09 -0700 TJ Trout wrote: > Has anyone had success with getting Ookla / Maxmind to update subnets whois > data? I've submitted the correction request with Maxmind ten times over the > last 5 years and all of our resources still show the previous allocation > owner as the 'isp' when visiting speed test.net We have a prefix that Ookla thinks is in Kansas, even though we are the only owner of the space and it has never been assigned to anyone outside of Oregon. Maxmind seems to have the correct info for it. We have not been able to figure out how that happened or how to get it fixed. --TimH From baldur.norddahl at gmail.com Thu Aug 8 21:16:00 2019 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Thu, 8 Aug 2019 23:16:00 +0200 Subject: Mx204 alternative In-Reply-To: References: Message-ID: Hello How about Juniper vMX? 8x 10G is no problem in a 2U server. Two Intel X710 NICs with 4 interfaces on each. I found this guide: https://gbe0.com/networking/juniper/vmx/ubuntu-14-04-kvm-host-setup-for-juniper-vmx Regards Baldur On Thu, Aug 8, 2019 at 5:04 AM Mehmet Akcin wrote: > Greetings, > > I am looking for some suggestions on alternatives to mx204. > > Any recommendations on something more affordable which can handle full > routing tables from two providers? > > Prefer Juniper but happy to look alternatives. > Min 6-8 10G ports are required > 1G support required > > Thanks in advance! > > Mehmet > -- > Mehmet > +1-424-298-1903 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj at pcguys.us Thu Aug 8 21:21:46 2019 From: tj at pcguys.us (TJ Trout) Date: Thu, 8 Aug 2019 14:21:46 -0700 Subject: Ookla geo IP data contact? In-Reply-To: References: Message-ID: How does one request Ookla to update their database to reflect the proper whois owner of a netblock? The process must not be automated because these netblocks have been under a new name for 3 to 5 years now. On Thu, Aug 8, 2019, 11:02 AM Josh Luthman wrote: > The name is from WHOIS records. The location is from Maxmind. > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > > On Thu, Aug 8, 2019 at 1:36 PM TJ Trout wrote: > >> Has anyone had success with getting Ookla / Maxmind to update subnets >> whois data? I've submitted the correction request with Maxmind ten times >> over the last 5 years and all of our resources still show the previous >> allocation owner as the 'isp' when visiting speed test.net >> >> Thanks >> >> TJ Trout >> Volt Broadband >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu Aug 8 21:24:53 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 08 Aug 2019 23:24:53 +0200 Subject: MAP-E In-Reply-To: <8475bfe9-9c93-7983-1a45-b46daeafc632@retevia.net> References: <8475bfe9-9c93-7983-1a45-b46daeafc632@retevia.net> Message-ID: Hi Lee, I recall the original sender of this post indicated a small number of users, that’s why I responded that. Regards, Jordi @jordipalet El 8/8/19 22:17, "NANOG en nombre de Lee Howard" escribió: On 8/2/19 1:10 PM, JORDI PALET MARTINEZ via NANOG wrote: The cost of sharing IPs in a static way, is that services such as Sony Playstation Network will put those addresses in the black list, so you need to buy more addresses. This hasn’t been the case for 464XLAT/NAT64, which shares the addresses dynamically. Furthermore, if some users need less ports than others, you “infra-utilize” those addresses, which again is not the case for 464XLAT/NAT64. Each user gets automatically as many ports as he needs at every moment. So, you save money in terms of addresses, that you can invest in a couple of servers running a redundant NAT64 setup (https://www.jool.mx/en/session-synchronization.html). Those servers can be actually VMs, so you don’t need dedicated hardware, especially because when you deploy IPv6 with 464XLAT, typically 75% (and going up) of you traffic will be IPv6 and only 25% will go thru the NAT64. You work on much smaller networks than I do if a "couple of servers running Jool" can handle your load. Jool is great, and the team that built it is great, but a couple of 10Gbps NICs on a pizza box doesn't go very far. I've tried 100Gbps and can't get the throughput with any normal CPU. Hoping to get back to it and run some actual measurements. Lee Regards, Jordi @jordipalet El 2/8/19 18:24, "NANOG en nombre de Baldur Norddahl" escribió: The goal is to minimize cost. Assuming 4 bits for the MAP routing (16 users sharing one IPv4), leaving 12 bits for customer ports (4096 ports) and a current price of USD 20 per IPv4 address, this gives a cost of USD 1.25 per user for a fully redundant solution. For us it is even cheaper as we can recirculate existing address space. Regards, Baldur On Fri, Aug 2, 2019 at 5:32 PM JORDI PALET MARTINEZ wrote: I understand that, but the inconvenient is the fix allocation of ports per client, and not all the clients use the same number of ports. Every option has good and bad things. MAP is less efficient in terms of maximizing the “use” of the existing IPv4 addresses. https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ Regards, Jordi @jordipalet El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" escribió: Hi Jordi My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid the expense and operative nightmare of having to run a redundant NAT server setup with thousands of users. MAP is the only alternative that avoids a provider run NAT server. Regards, Baldur On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG wrote: Ask the vendor to support RFC8585. Also, you can do it with OpenWRT. I think 464XLAT is a better option and both of them are supported by OpenWRT. You can also use OpenSource (Jool) for the NAT64. Regards, Jordi @jordipalet El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" escribió: Hello Are there any known public deployments of MAP-E? What about CPE routers with support? The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to go the CGN route going forward. Of all the options, MAP-E appears to be the most elegant. Just add/remove some more headers on a packet and route it as normal. No need to invest in anything as our core routers can already do that. No worries about scale. BUT - our current CPE has zero support. We are too small that they will make this feature just for us, so I need to convince them there is going to be a demand. Alternatively I need to find a different CPE vendor that has MAP-E support, but are there any? What is holding MAP-E back? In my view MAP-E could be the end game for IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP networks are not forced to do a lot of processing such as CGN otherwise requires. I read some posts from Japan where users are reporting a deployment of MAP-E. Anyone know about that? Regards, Baldur ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu Aug 8 21:31:02 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 08 Aug 2019 23:31:02 +0200 Subject: MAP-E In-Reply-To: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> References: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> Message-ID: <4E21CA24-B1E9-4BCB-8298-3A3D37724F41@consulintel.es> The point is that the situation is that same for *all* the transition mechanisms, except DS-Lite, which was the first one. Even lw4o6, which is a better choice than DS-LITE is not well supported even the CE is basically doing the same! I've a recent presentation in the last APNIC meeting, which is also recorded in youtube: https://conference.apnic.net/47/program/schedule/#/day/11/ipv4aas-tutorial-and-hands-on---part-1 Regards, Jordi @jordipalet El 8/8/19 22:21, "NANOG en nombre de Lee Howard" escribió: On 8/2/19 11:39 AM, Jay Hanke wrote: > Is there a summary presentation someplace laying out the options that > are active in the wild with some deployment stats? I can't think of a public presentation off the top of my head that explains how each major transition technology works, and the pros and cons of each. There must be one, but it's hard to cover the major options in an hour. If you want to know who is using any given transition technology, there's this crowd-sourced list: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0 Very brief summary of options: NAT444. Your basic NAT, plus NAT again. You really need to deploy IPv6, too, or all your traffic will go through a translator (everything else below assumes native IPv6 is deployed). State information can get expensive. Well understood. Dual-stack Lite. CPE sends IPv4 traffic through an IPv6 tunnel (softwire) to a pre-configured DS-Lite box, which does NAT44. Works fine, deployed at scale (see sheet above), but keeping state on lots of NAT44 can get expensive at scale. NAT64. IPv6-only to users. DNS resolver given in provisioning information is a DNS64 server. When it does a lookup but there's no AAAA, it invents one based on the A record (e.g., 2001:db8:64::). The IPv6 prefix in the invented AAAA is actually a NAT64 translator. Pro: no CPE support required, well understood. Con: No support for IPv4-only stuff in the prem, breaks DNSSEC. 464xlat. IPv6-only between CE and NAT64. Any IPv4 traffic the CPE receives, it translates to IPv6 and forwards to a destination that's the NAT64 server, which translates again. Pro: widely deployed at scale on mobile networks. Con: Very little CPE support in home routers. MAP-T, MAP-E. IPv6-only between CE and Border Relay (BR). CPE is provisioned with an IPv4 address and a range of ports. It does basic NAT44, but only uses the reserved ports. Then it translates to IPv6 (MAP-T) or encapsulates in IPv6 (MAP-E) and forwards to the configured Border Relay (BR), which changes it to IPv4. Pro: Stateless, very efficient. Con: Very little CPE support in home routers. Jordi is going to tell me there's plenty of support for 464xlat. However, you can't go into any old electronics store in North America and buy a home gateway with support for 464xlat or MAP. You can't buy them directly from a vendor, unless you're large enough to request a specific firmware build. Yes, you can get support from OpenWRT, but that's probably not how you want your support team spending their time. CPE support is the next big frontier in IPv6 deployment. Lee > > On Fri, Aug 2, 2019 at 10:34 AM JORDI PALET MARTINEZ via NANOG > wrote: >> I understand that, but the inconvenient is the fix allocation of ports per client, and not all the clients use the same number of ports. Every option has good and bad things. >> >> >> >> MAP is less efficient in terms of maximizing the “use” of the existing IPv4 addresses. >> >> >> >> https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ >> >> >> >> >> >> Regards, >> >> Jordi >> >> @jordipalet >> >> >> >> >> >> >> >> El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" escribió: >> >> >> >> Hi Jordi >> >> >> >> My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid the expense and operative nightmare of having to run a redundant NAT server setup with thousands of users. MAP is the only alternative that avoids a provider run NAT server. >> >> >> >> Regards, >> >> >> >> Baldur >> >> >> >> >> >> On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG wrote: >> >> Ask the vendor to support RFC8585. >> >> >> >> Also, you can do it with OpenWRT. >> >> >> >> I think 464XLAT is a better option and both of them are supported by OpenWRT. >> >> >> >> You can also use OpenSource (Jool) for the NAT64. >> >> >> >> Regards, >> >> Jordi >> >> @jordipalet >> >> >> >> >> >> >> >> El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" escribió: >> >> >> >> Hello >> >> >> >> Are there any known public deployments of MAP-E? What about CPE routers with support? >> >> >> >> The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to go the CGN route going forward. Of all the options, MAP-E appears to be the most elegant. Just add/remove some more headers on a packet and route it as normal. No need to invest in anything as our core routers can already do that. No worries about scale. >> >> >> >> BUT - our current CPE has zero support. We are too small that they will make this feature just for us, so I need to convince them there is going to be a demand. Alternatively I need to find a different CPE vendor that has MAP-E support, but are there any? >> >> >> >> What is holding MAP-E back? In my view MAP-E could be the end game for IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible. The ISP networks are not forced to do a lot of processing such as CGN otherwise requires. >> >> >> >> I read some posts from Japan where users are reporting a deployment of MAP-E. Anyone know about that? >> >> >> >> Regards, >> >> >> >> Baldur >> >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Thu Aug 8 21:32:23 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 08 Aug 2019 23:32:23 +0200 Subject: MAP-E In-Reply-To: References: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> Message-ID: <163FEAB7-3EA3-434F-A369-BC20FAA2A45D@consulintel.es> I think the only reason DS-Lite got more implementations is that it was the first and "only" choice or IPv6-only with IPv4aaS. Regards, Jordi @jordipalet El 8/8/19 22:57, "NANOG en nombre de Jay Hanke" escribió: > I can't think of a public presentation off the top of my head that > explains how each major transition technology works, and the pros and > cons of each. There must be one, but it's hard to cover the major > options in an hour. Actually your post is better than a presentation. I was quite surprised at the adoption rate of DS-Lite. There must be some pretty decent B4 implementations with that many operators deployed. Even though the spreadsheet is small sample size, there isn't much DS-lite deployment in the US. So from 10k feet, MAP-E is basically the same thing as DS-Lite except for the location of the NAT? ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From astephens at ptera.com Thu Aug 8 21:40:17 2019 From: astephens at ptera.com (Art Stephens) Date: Thu, 8 Aug 2019 14:40:17 -0700 Subject: BGP router question Message-ID: Hope this is not too off topic but can any one advise if a Dell S4048-ON can support full ebgp routes? -- Arthur Stephens Senior Network Administrator Ptera Inc. PO Box 135 24001 E Mission Suite 50 Liberty Lake, WA 99019 509-927-7837 ptera.com | facebook.com/PteraInc | twitter.com/Ptera ----------------------------------------------------------------------------- "This message may contain confidential and/or propriety information, and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company." -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.py at tsisemi.com Thu Aug 8 21:49:48 2019 From: michel.py at tsisemi.com (Michel Py) Date: Thu, 8 Aug 2019 21:49:48 +0000 Subject: BGP router question In-Reply-To: References: Message-ID: <58b56d74704d4415ab02746abedc26c7@CRA114.am.necel.com> > Art Stephens > ope this is not too off topic but can any one advise if a Dell S4048-ON can support full ebgp routes? RTFM : https://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Documents/Dell-EMC-Networking-S4048-ON-Spec-Sheet.pdf 128K IPv4 routes. 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 phil.lavin at cloudcall.com Thu Aug 8 21:50:00 2019 From: phil.lavin at cloudcall.com (Phil Lavin) Date: Thu, 8 Aug 2019 21:50:00 +0000 Subject: BGP router question In-Reply-To: References: Message-ID: <3075473E-64D3-4E36-96CF-9A3984A555CE@cloudcall.com> On 8 Aug 2019, at 22:40, Art Stephens > wrote: Hope this is not too off topic but can any one advise if a Dell S4048-ON can support full ebgp routes? Datasheet (https://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Documents/Dell-EMC-Networking-S4048-ON-Spec-Sheet.pdf) says 128k v4 routes, so no -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at wicks.co.nz Thu Aug 8 21:52:04 2019 From: tony at wicks.co.nz (Tony Wicks) Date: Fri, 9 Aug 2019 09:52:04 +1200 Subject: Mx204 alternative In-Reply-To: References: Message-ID: <00ba01d54e33$85036af0$8f0a40d0$@wicks.co.nz> VMX (and VSR) throughput capacity pricing is excessive once you get over about 20G from what I have seen. From: NANOG On Behalf Of Baldur Norddahl Sent: Friday, 9 August 2019 9:16 AM To: nanog at nanog.org Subject: Re: Mx204 alternative Hello How about Juniper vMX? 8x 10G is no problem in a 2U server. Two Intel X710 NICs with 4 interfaces on each. I found this guide: https://gbe0.com/networking/juniper/vmx/ubuntu-14-04-kvm-host-setup-for-juniper-vmx Regards Baldur -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Thu Aug 8 22:10:48 2019 From: cb.list6 at gmail.com (Ca By) Date: Fri, 9 Aug 2019 07:10:48 +0900 Subject: MAP-E In-Reply-To: <8475bfe9-9c93-7983-1a45-b46daeafc632@retevia.net> References: <8475bfe9-9c93-7983-1a45-b46daeafc632@retevia.net> Message-ID: On Fri, Aug 9, 2019 at 5:17 AM Lee Howard wrote: > > On 8/2/19 1:10 PM, JORDI PALET MARTINEZ via NANOG wrote: > > The cost of sharing IPs in a static way, is that services such as Sony > Playstation Network will put those addresses in the black list, so you need > to buy more addresses. This hasn’t been the case for 464XLAT/NAT64, which > shares the addresses dynamically. > > > > Furthermore, if some users need less ports than others, you > “infra-utilize” those addresses, which again is not the case for > 464XLAT/NAT64. Each user gets automatically as many ports as he needs at > every moment. > > > > So, you save money in terms of addresses, that you can invest in a couple > of servers running a redundant NAT64 setup ( > https://www.jool.mx/en/session-synchronization.html). Those servers can > be actually VMs, so you don’t need dedicated hardware, especially because > when you deploy IPv6 with 464XLAT, typically 75% (and going up) of you > traffic will be IPv6 and only 25% will go thru the NAT64. > > You work on much smaller networks than I do if a "couple of servers > running Jool" can handle your load. Jool is great, and the team that built > it is great, but a couple of 10Gbps NICs on a pizza box doesn't go very > far. I've tried 100Gbps and can't get the throughput with any normal CPU. > Hoping to get back to it and run some actual measurements. > > > Lee > > NAT64 / 464xlat / MAP all lend themselves well to regionalization / edge distribution. That’s how i roll 464xlat. Either with anycast of the well know prefix or dns64 or “dns view” base segmentation. Asking for a single box to do a 100g of nat state may be the wrong question. Worth noting, Yandex, a big shop, sponsored adding 464xlat CLAT to FreeBSD https://www.freebsd.org/releases/11.3R/relnotes.html#network-general > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 2/8/19 18:24, "NANOG en nombre de Baldur Norddahl" < > nanog-bounces at nanog.org en nombre de baldur.norddahl at gmail.com> escribió: > > > > The goal is to minimize cost. Assuming 4 bits for the MAP routing (16 > users sharing one IPv4), leaving 12 bits for customer ports (4096 ports) > and a current price of USD 20 per IPv4 address, this gives a cost of USD > 1.25 per user for a fully redundant solution. For us it is even cheaper as > we can recirculate existing address space. > > > > Regards, > > > > Baldur > > > > > > On Fri, Aug 2, 2019 at 5:32 PM JORDI PALET MARTINEZ < > jordi.palet at consulintel.es> wrote: > > I understand that, but the inconvenient is the fix allocation of ports per > client, and not all the clients use the same number of ports. Every option > has good and bad things. > > > > MAP is less efficient in terms of maximizing the “use” of the existing > IPv4 addresses. > > > > https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/ > > > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" < > nanog-bounces at nanog.org en nombre de baldur.norddahl at gmail.com> escribió: > > > > Hi Jordi > > > > My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to > avoid the expense and operative nightmare of having to run a redundant NAT > server setup with thousands of users. MAP is the only alternative that > avoids a provider run NAT server. > > > > Regards, > > > > Baldur > > > > > > On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG < > nanog at nanog.org> wrote: > > Ask the vendor to support RFC8585. > > > > Also, you can do it with OpenWRT. > > > > I think 464XLAT is a better option and both of them are supported by > OpenWRT. > > > > You can also use OpenSource (Jool) for the NAT64. > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" < > nanog-bounces at nanog.org en nombre de baldur.norddahl at gmail.com> escribió: > > > > Hello > > > > Are there any known public deployments of MAP-E? What about CPE routers > with support? > > > > The pricing on IPv4 is now at USD 20/address so I am thinking we are > forced to go the CGN route going forward. Of all the options, MAP-E appears > to be the most elegant. Just add/remove some more headers on a packet and > route it as normal. No need to invest in anything as our core routers can > already do that. No worries about scale. > > > > BUT - our current CPE has zero support. We are too small that they will > make this feature just for us, so I need to convince them there is going to > be a demand. Alternatively I need to find a different CPE vendor that has > MAP-E support, but are there any? > > > > What is holding MAP-E back? In my view MAP-E could be the end game for > IPv4. Customers get full IPv6 and enough of IPv4 to be somewhat compatible. > The ISP networks are not forced to do a lot of processing such as CGN > otherwise requires. > > > > I read some posts from Japan where users are reporting a deployment of > MAP-E. Anyone know about that? > > > > Regards, > > > > Baldur > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clegendre at coextro.com Thu Aug 8 22:59:35 2019 From: clegendre at coextro.com (Colin Legendre) Date: Thu, 8 Aug 2019 18:59:35 -0400 Subject: Ookla geo IP data contact? In-Reply-To: References: Message-ID: Update is done to Maxmind at https://support.maxmind.com/geoip-data-correction-request/ One tab for location.. other tab for ISP/Org --- Colin Legendre President and CTO Coextro - Unlimited. Fast. Reliable. w: www.coextro.com e: clegendre at coextro.com p: 647-693-7686 ext.101 m: 416-560-8502 f: 647-693-7601 On Thu, Aug 8, 2019 at 5:23 PM TJ Trout wrote: > How does one request Ookla to update their database to reflect the proper > whois owner of a netblock? The process must not be automated because these > netblocks have been under a new name for 3 to 5 years now. > > On Thu, Aug 8, 2019, 11:02 AM Josh Luthman > wrote: > >> The name is from WHOIS records. The location is from Maxmind. >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> >> On Thu, Aug 8, 2019 at 1:36 PM TJ Trout wrote: >> >>> Has anyone had success with getting Ookla / Maxmind to update subnets >>> whois data? I've submitted the correction request with Maxmind ten times >>> over the last 5 years and all of our resources still show the previous >>> allocation owner as the 'isp' when visiting speed test.net >>> >>> Thanks >>> >>> TJ Trout >>> Volt Broadband >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohta at necom830.hpcl.titech.ac.jp Fri Aug 9 01:00:13 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 9 Aug 2019 10:00:13 +0900 Subject: MAP-E In-Reply-To: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> References: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> Message-ID: Lee Howard wrote: > MAP-T, MAP-E. IPv6-only between CE and Border Relay (BR). CPE is > provisioned with an IPv4 address and a range of ports. It does basic > NAT44, but only uses the reserved ports. Then it translates to IPv6 > (MAP-T) or encapsulates in IPv6 (MAP-E) and forwards to the configured > Border Relay (BR), which changes it to IPv4. Pro: Stateless, very > efficient. Con: Very little CPE support in home routers. So, all we need is NAT44 CPE, which only uses a reserved block of ports, which is (semi) statically configured by ISP operated gateway. Pro: Stateless, very efficient, no IPv6 necessary Con: No current CPE support. As for protocol, assuming port mapping on UPnP gateway is statically configured by ISPs not changable from CPE side, GetListOfPortMappings() of UPnP should be useful for CPEs to know range of ports to be used by them. Masataka Ohta From bernat at luffy.cx Fri Aug 9 05:32:00 2019 From: bernat at luffy.cx (Vincent Bernat) Date: Fri, 09 Aug 2019 07:32:00 +0200 Subject: MAP-E In-Reply-To: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> (Lee Howard's message of "Thu, 8 Aug 2019 16:18:08 -0400") References: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> Message-ID: <87h86qj44v.fsf@luffy.cx> ❦ 8 août 2019 16:18 -04, Lee Howard : > NAT64. IPv6-only to users. DNS resolver given in provisioning > information is a DNS64 server. When it does a lookup but there's no > AAAA, it invents one based on the A record (e.g., 2001:db8:64:: address>). The IPv6 prefix in the invented AAAA is actually a NAT64 > translator. Pro: no CPE support required, well understood. Con: No > support for IPv4-only stuff in the prem, breaks DNSSEC. Is there a known deployment for a medium/large ISP? Thanks. -- Wrinkles should merely indicate where smiles have been. -- Mark Twain From swmike at swm.pp.se Fri Aug 9 05:59:18 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 9 Aug 2019 07:59:18 +0200 (CEST) Subject: MAP-E In-Reply-To: References: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> Message-ID: On Thu, 8 Aug 2019, Jay Hanke wrote: > Actually your post is better than a presentation. I was quite surprised > at the adoption rate of DS-Lite. There must be some pretty decent B4 > implementations with that many operators deployed. The DOCSIS residential gateway vendors seem to have converged on ds.lite, probably because it was the first one out the gate. I've seen support for this on RGs for other WAN technologies. It's not great, but it's what has the most support in devices available. Lots of ds.lite is in Germany, and most/all the cable operators there have converged on ds.lite. This is not uncommon that several operators in a country converge on a similar strategy. Engineers moving employment between operators bring with them the know-how and do the same thing over again at the new place, and also there is a kind of "herd immunity" against customer complaints if your deployment and service offering has similar properties to most of your competitors in the country. -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at radu-adrian.feurdean.net Fri Aug 9 06:06:47 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Fri, 09 Aug 2019 08:06:47 +0200 Subject: Mx204 alternative In-Reply-To: <36dc2678-3605-b9c0-8a1a-1f2bbf89308e@ninjabadger.net> References: <36dc2678-3605-b9c0-8a1a-1f2bbf89308e@ninjabadger.net> Message-ID: On Thu, Aug 8, 2019, at 16:51, Tom Hill wrote: > No-one has mentioned it yet, so for completeness big C have the ASR 9901 Weren't we talking about "decently priced" ? > (not 9001) with traditional router bits in it. 9001, while approaching EoL, can be a good solution if your needs are limited : 8x10G + 20x1G, you should get it for a good price - refurbished. From saku at ytti.fi Fri Aug 9 06:12:54 2019 From: saku at ytti.fi (Saku Ytti) Date: Fri, 9 Aug 2019 09:12:54 +0300 Subject: Mx204 alternative In-Reply-To: References: <36dc2678-3605-b9c0-8a1a-1f2bbf89308e@ninjabadger.net> Message-ID: On Fri, 9 Aug 2019 at 09:09, Radu-Adrian Feurdean wrote: > On Thu, Aug 8, 2019, at 16:51, Tom Hill wrote: > > No-one has mentioned it yet, so for completeness big C have the ASR 9901 > > Weren't we talking about "decently priced" ? ASR9901 and MX204 being wildly differently priced is market inefficiency. It's difficult for me to see, how CSCO could justify the premium for any volume order. Either sell at market or lose sale. > > (not 9001) with traditional router bits in it. > > 9001, while approaching EoL, can be a good solution if your needs are limited : 8x10G + 20x1G, you should get it for a good price - refurbished. Also it will never run eXR. I have no information, but I think it's reasonable to suspect the OS not being sold may receive decreasing amount of NRE. I wouldn't certainly spend my time writing code for product I'm not selling. -- ++ytti From tore at fud.no Fri Aug 9 09:04:58 2019 From: tore at fud.no (Tore Anderson) Date: Fri, 9 Aug 2019 11:04:58 +0200 Subject: BGP router question In-Reply-To: References: Message-ID: <46eed37d-9515-a5c1-fe63-1c0d0532d0da@fud.no> * Art Stephens > Hope this is not too off topic but can any one advise if a Dell S4048-ON can support full ebgp routes? As others have mentioned, you won't be able to program them all in the forwarding plane, but the control plane can receive them all just fine (it has more than enough RAM). If your use case allows for accepting a default route from your IP transit providers along with the full feed, you can easily implement control plane policies that ensure that what gets installed to the forwarding plane is only the routes to the destinations you care the most about + the default route to cover the long tail of traffic to the rest of the world. You can use the S4048-ON (or any equivalent layer-3 capable data centre switch) as a border router this way, at a fraction of what a big C or J router would cost you. We started doing this a few years back and we're not regretting it. https://labs.spotify.com/2016/01/27/sdn-internet-router-part-2/ https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html Tore From nanog at radu-adrian.feurdean.net Fri Aug 9 09:09:54 2019 From: nanog at radu-adrian.feurdean.net (Radu-Adrian Feurdean) Date: Fri, 09 Aug 2019 11:09:54 +0200 Subject: Mx204 alternative In-Reply-To: References: <36dc2678-3605-b9c0-8a1a-1f2bbf89308e@ninjabadger.net> Message-ID: On Fri, Aug 9, 2019, at 08:13, Saku Ytti wrote: > On Fri, 9 Aug 2019 at 09:09, Radu-Adrian Feurdean > wrote: > > > On Thu, Aug 8, 2019, at 16:51, Tom Hill wrote: > > > No-one has mentioned it yet, so for completeness big C have the ASR 9901 > > > > Weren't we talking about "decently priced" ? > > ASR9901 and MX204 being wildly differently priced is market > inefficiency. It's difficult for me to see, how CSCO could justify the > premium for any volume order. Either sell at market or lose sale. The 2 boxes not having exactly the same port count and features(9901 can do - or is suppose to be able to do - subscriber stuff - IPoE,PTA,LAC), this explains the difference. Add the fact that Cisco has customers that buy "Cisco and nothing else". And not everybody buys "enough" in order to get acceptable volume discounts. > Also it will never run eXR. I have no information, but I think it's > reasonable to suspect the OS not being sold may receive decreasing > amount of NRE. I wouldn't certainly spend my time writing code for > product I'm not selling. Agreed. From lists.nanog at monmotha.net Fri Aug 9 12:47:57 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 9 Aug 2019 08:47:57 -0400 Subject: MAP-E In-Reply-To: References: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> Message-ID: <6384a089-fafe-a1c2-87be-26b87f475dfb@monmotha.net> On 8/8/19 9:00 PM, Masataka Ohta wrote: > As for protocol, assuming port mapping on UPnP gateway is statically > configured by ISPs not changable from CPE side, GetListOfPortMappings() > of UPnP should be useful for CPEs to know range of ports to be used > by them. There's actually a DHCPv6 option for specifying the port information in addition to the transition tech in use. I had previously inquired to NANOG about it, though I don't recall the specifics at this time. In theory, with that in place, a user could go buy any ol' RG style router with support for the proper transition tech and just plug and play like they currently do with native dual-stack networks. -- Brandon Martin From lee.howard at retevia.net Fri Aug 9 17:10:43 2019 From: lee.howard at retevia.net (Lee Howard) Date: Fri, 9 Aug 2019 13:10:43 -0400 Subject: MAP-E In-Reply-To: References: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> Message-ID: On 8/8/19 9:00 PM, Masataka Ohta wrote: > Lee Howard wrote: > >> MAP-T, MAP-E. IPv6-only between CE and Border Relay (BR). CPE is >> provisioned with an IPv4 address and a range of ports. It does basic >> NAT44, but only uses the reserved ports. Then it translates to IPv6 >> (MAP-T) or encapsulates in IPv6 (MAP-E) and forwards to the >> configured Border Relay (BR), which changes it to IPv4. Pro: >> Stateless, very efficient. Con: Very little CPE support in home routers. > > So, all we need is NAT44 CPE, which only uses a reserved block of ports, > which is (semi) statically configured by ISP operated gateway. > How would you route from the provider edge? If CPE A has 192.0.2.15 port 1000-2999 and CPE B has 192.0.2.15 port 3000-4999, how does your BRAS or CMTS or edge router know whether to forward a packet to A or B? You could do policy routing or similarly do deep packet inspection, but you'd need a mechanism to provision that information into the provider edge router; you wouldn't manually configure match/set policy for each customer. > Pro: Stateless, very efficient, no IPv6 necessary Con: No current > CPE support. > > As for protocol, assuming port mapping on UPnP gateway is statically > configured by ISPs not changable from CPE side, GetListOfPortMappings() > of UPnP should be useful for CPEs to know range of ports to be used > by them. Do CPEs do this now, or is this another feature to ask vendors for? Lee > >                             Masataka Ohta > > From davey at latte.net.nz Thu Aug 8 18:56:48 2019 From: davey at latte.net.nz (davey at latte.net.nz) Date: Fri, 9 Aug 2019 06:56:48 +1200 Subject: Mx204 alternative In-Reply-To: <36dc2678-3605-b9c0-8a1a-1f2bbf89308e@ninjabadger.net> References: <36dc2678-3605-b9c0-8a1a-1f2bbf89308e@ninjabadger.net> Message-ID: One thought could be any of the virtual ones, vmx, nokia vsr, etc on lannerinc hardware. Cheep scalable and has all the interface options Sent from my iPhone > On 9 Aug 2019, at 2:50 am, Tom Hill wrote: > >> On 08/08/2019 04:02, Mehmet Akcin wrote: >> >> I am looking for some suggestions on alternatives to mx204. >> >> Any recommendations on something more affordable which can handle full >> routing tables from two providers? >> >> Prefer Juniper but happy to look alternatives. >> Min 6-8 10G ports are required >> 1G support required > > > No-one has mentioned it yet, so for completeness big C have the ASR 9901 > (not 9001) with traditional router bits in it. > > A portion of the 10G ports on it are capable of 1/10G. > > Regards, > > -- > Tom From dennis at umnum.ca Thu Aug 8 21:52:30 2019 From: dennis at umnum.ca (=?UTF-8?Q?Dennis_Lundstr=C3=B6m?=) Date: Thu, 8 Aug 2019 17:52:30 -0400 Subject: BGP router question In-Reply-To: References: Message-ID: Data-sheet appear to say the following: - Routing entries: 128000 So No. You will not be able to fit a full table. —Dennis On Thu, Aug 8, 2019 at 17:39 Art Stephens wrote: > Hope this is not too off topic but can any one advise if a Dell S4048-ON > can support full ebgp routes? > > -- > Arthur Stephens > Senior Network Administrator > Ptera Inc. > PO Box 135 > 24001 E Mission Suite 50 > > Liberty Lake, WA 99019 > > > 509-927-7837 > ptera.com | > facebook.com/PteraInc | twitter.com/Ptera > > ----------------------------------------------------------------------------- > "This message may contain confidential and/or propriety information, and > is intended for the person/entity to whom it was originally addressed. > Any use by others is strictly prohibited. Please note that any views or > opinions presented in this email are solely those of the author and are not > intended to represent those of the company." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kawashimam at vx.jp.nec.com Fri Aug 9 06:40:17 2019 From: kawashimam at vx.jp.nec.com (Masanobu Kawashima) Date: Fri, 9 Aug 2019 06:40:17 +0000 Subject: MAP-E In-Reply-To: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> References: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> Message-ID: <81A3232BEF82944C8F23DB1CFE276F0F497E8CEC@BPXM24GP.gisp.nec.co.jp> Hi all, > CPE support is the next big frontier in IPv6 deployment. That’s why we discussed about the issue with Jordi and other vendors on APNIC 44 almost 2 years ago. https://conference.apnic.net/44/program/schedule/#/day/6/bof-discussion-with-ipv6-ce-vendors Following is my presentation at that time. https://conference.apnic.net/44/assets/files/APCS549/IPv6-support-at-NEC-CEs.pdf After that, we standardized RFC8585. So, next step is implemeting transition technologies and deployment. Please let me know if there’s opportunity to use transition technologies we have minimum order quantity though, we may discuss about it. Let’s cross the chasm together. :-) Regards, Masanobu ======================== NEC Platforms, Ltd. KAWASHIMA Masanobu kawashimam at vx.jp.nec.com https://www.necplatforms.co.jp/en/ ======================== > -----Original Message----- > From: NANOG On Behalf Of Lee Howard > Sent: Friday, August 9, 2019 5:18 AM > To: nanog at nanog.org > Subject: Re: MAP-E > > > On 8/2/19 11:39 AM, Jay Hanke wrote: > > Is there a summary presentation someplace laying out the options that > > are active in the wild with some deployment stats? > > I can't think of a public presentation off the top of my head that explains how each major transition technology works, > and the pros and cons of each. There must be one, but it's hard to cover the major options in an hour. > > If you want to know who is using any given transition technology, there's this crowd-sourced list: > > https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0 > > Very brief summary of options: > > NAT444. Your basic NAT, plus NAT again. You really need to deploy IPv6, too, or all your traffic will go through a > translator (everything else below assumes native IPv6 is deployed). State information can get expensive. Well understood. > > Dual-stack Lite. CPE sends IPv4 traffic through an IPv6 tunnel > (softwire) to a pre-configured DS-Lite box, which does NAT44. Works fine, deployed at scale (see sheet above), but > keeping state on lots of > NAT44 can get expensive at scale. > > NAT64. IPv6-only to users. DNS resolver given in provisioning information is a DNS64 server. When it does a lookup > but there's no AAAA, it invents one based on the A record (e.g., 2001:db8:64:: address>). The IPv6 prefix in the invented AAAA is actually a NAT64 > translator. Pro: no CPE support required, well understood. Con: No support for IPv4-only stuff in the prem, breaks > DNSSEC. > > 464xlat. IPv6-only between CE and NAT64. Any IPv4 traffic the CPE receives, it translates to IPv6 and forwards to > a destination that's the > NAT64 server, which translates again. Pro: widely deployed at scale on mobile networks. Con: Very little CPE support > in home routers. > > MAP-T, MAP-E. IPv6-only between CE and Border Relay (BR). CPE is provisioned with an IPv4 address and a range of ports. > It does basic NAT44, but only uses the reserved ports. Then it translates to IPv6 > (MAP-T) or encapsulates in IPv6 (MAP-E) and forwards to the configured Border Relay (BR), which changes it to IPv4. > Pro: Stateless, very efficient. Con: Very little CPE support in home routers. > > Jordi is going to tell me there's plenty of support for 464xlat. > However, you can't go into any old electronics store in North America and buy a home gateway with support for 464xlat > or MAP. You can't buy them directly from a vendor, unless you're large enough to request a specific firmware build. > Yes, you can get support from OpenWRT, but that's probably not how you want your support team spending their time. > > CPE support is the next big frontier in IPv6 deployment. > > Lee > > > > > On Fri, Aug 2, 2019 at 10:34 AM JORDI PALET MARTINEZ via NANOG > > > wrote: > >> I understand that, but the inconvenient is the fix allocation of ports per client, and not all the clients use > the same number of ports. Every option has good and bad things. > >> > >> > >> > >> MAP is less efficient in terms of maximizing the “use” of the existing IPv4 addresses. > >> > >> > >> > >> https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparis > >> on/ > >> > >> > >> > >> > >> > >> Regards, > >> > >> Jordi > >> > >> @jordipalet > >> > >> > >> > >> > >> > >> > >> > >> El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" > baldur.norddahl at gmail.com> escribió: > >> > >> > >> > >> Hi Jordi > >> > >> > >> > >> My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to avoid the expense and operative nightmare > of having to run a redundant NAT server setup with thousands of users. MAP is the only alternative that avoids a provider > run NAT server. > >> > >> > >> > >> Regards, > >> > >> > >> > >> Baldur > >> > >> > >> > >> > >> > >> On Fri, Aug 2, 2019 at 3:38 PM JORDI PALET MARTINEZ via NANOG > wrote: > >> > >> Ask the vendor to support RFC8585. > >> > >> > >> > >> Also, you can do it with OpenWRT. > >> > >> > >> > >> I think 464XLAT is a better option and both of them are supported by OpenWRT. > >> > >> > >> > >> You can also use OpenSource (Jool) for the NAT64. > >> > >> > >> > >> Regards, > >> > >> Jordi > >> > >> @jordipalet > >> > >> > >> > >> > >> > >> > >> > >> El 2/8/19 14:20, "NANOG en nombre de Baldur Norddahl" > baldur.norddahl at gmail.com> escribió: > >> > >> > >> > >> Hello > >> > >> > >> > >> Are there any known public deployments of MAP-E? What about CPE routers with support? > >> > >> > >> > >> The pricing on IPv4 is now at USD 20/address so I am thinking we are forced to go the CGN route going forward. > Of all the options, MAP-E appears to be the most elegant. Just add/remove some more headers on a packet and route > it as normal. No need to invest in anything as our core routers can already do that. No worries about scale. > >> > >> > >> > >> BUT - our current CPE has zero support. We are too small that they will make this feature just for us, so I need > to convince them there is going to be a demand. Alternatively I need to find a different CPE vendor that has MAP-E > support, but are there any? > >> > >> > >> > >> What is holding MAP-E back? In my view MAP-E could be the end game for IPv4. Customers get full IPv6 and enough > of IPv4 to be somewhat compatible. The ISP networks are not forced to do a lot of processing such as CGN otherwise > requires. > >> > >> > >> > >> I read some posts from Japan where users are reporting a deployment of MAP-E. Anyone know about that? > >> > >> > >> > >> Regards, > >> > >> > >> > >> Baldur > >> > >> > >> > >> > >> ********************************************** > >> IPv4 is over > >> Are you ready for the new Internet ? > >> http://www.theipv6company.com > >> The IPv6 Company > >> > >> This electronic message contains information which may be privileged or confidential. The information is intended > to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, > distribution or use of the contents of this information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, > copying, distribution or use of the contents of this information, even if partially, including attached files, is > strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about > this communication and delete it. > >> > >> > >> ********************************************** > >> IPv4 is over > >> Are you ready for the new Internet ? > >> http://www.theipv6company.com > >> The IPv6 Company > >> > >> This electronic message contains information which may be privileged or confidential. The information is intended > to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, > distribution or use of the contents of this information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, > copying, distribution or use of the contents of this information, even if partially, including attached files, is > strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about > this communication and delete it. > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmccormick at mdtc.net Fri Aug 9 13:59:18 2019 From: kmccormick at mdtc.net (Kevin McCormick) Date: Fri, 9 Aug 2019 13:59:18 +0000 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: <18117.1565294025@segfault.tristatelogic.com> References: <18117.1565294025@segfault.tristatelogic.com> Message-ID: <037d46620a1a44b68ecf38935e4938bf@mdtc.net> Thought you may find these connections with the 3500 South DuPont Hwy, Dover, DE, 19901 address interesting. https://offshoreleaks.icij.org/nodes/14014038 Thank you, Kevin McCormick -----Original Message----- From: NANOG On Behalf Of Ronald F. Guilmette Sent: Thursday, August 8, 2019 2:54 PM To: nanog at nanog.org Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 Corporate identity theft is a simple ploy which may be used to illicitly obtain valuable IPv4 address space. Actual use of this fradulent ploy was first described publicly in April, 2008 (https://wapo.st/2YLEhlZ). Quite simply, a party bent on undertaking this ploy may just search the publicly available IP block WHOIS records, looking for abandoned and unrouted IPv4 address blocks belonging to companies or organizations which no longer exist. Upon finding any such, the thief may simply undertake to formally register, with relevant government authorities, a new corporate entity with the same or a very similar name as the now defunct entity that is still listed in the WHOIS records as the registrant of the coveted IPv4 address block(s). Note that so-called "legacy" address blocks, i.e. those which were assigned prior to the formation of ARIN in early 1997, are especially prized by IPv4 address thieves because such blocks may be less subject to effective control or regulation by Regional Internet Registries. Publicly available evidence strongly suggests that a corporate identity theft has occurred with respect to a former Delaware corporate entity known as Azuki, LLC and also with respect to its valuable legacy IPv4 address block, 216.179.128.0/17. The corporate search function of the Delaware Secretary of State's web site may be used to obtain records relevant to corporate entities registered in Delaware: https://icis.corp.delaware.gov/Ecorp/EntitySearch/NameSearch.aspx At present, the Delaware SoS's web site indicates that there are or have been two different corporate entities, both named Azuki, LLC, that have been registered in the State of Delaware. The file numbers for these entities are 2810116 and 4751384. The former entity was first registered in Delaware on or about 10/20/1997. It's current operating status cannot be known without paying a fee. My own personal speculation is that it most likely ceased operation well more than a decade ago. The latter entity was registered in Delaware on or about 11/9/2009. According to the current live ARIN WHOIS record for the 216.179.128.0/17 address block (NET-216-179-128-0-1), this block was first allocated by ARIN to Azuki, LLC on or about 1999-01-07. Quite obviously, this assignment must have been made by ARIN to the original 1997 Azuki, LLC because the one that was registered in Delaware in 2009 did not yet exist at that time. Nontheless the mailing address currently present in the ARIN WHOIS record for the 216.179.128.0/17 IPv4 address block, and the one which is also present in the ARIN WHOIS record for the 2009 vintage ASN, AS13389 (Azuki, LLC), i.e. 3500 South DuPont Hwy, Dover, DE, 19901, matches exactly with the address given in Delaware corporate records for the particular Azuki, LLC that was registered in Delaware in 2009. (The corporate address that is still on file in Delaware for the original 1997 Azuki, LLC is located in a different Delaware city altogether.) These evident inconsistancies, by themselves, are strongly indicative of a probable case of corporate identity theft. Additional indicators are however also present in this case. In particular, the contact email address for both the Azuki, LLC ASN (AS13389) and the Azuki, LLC IPv4 address block (216.179.128.0/17), i.e. tech_dep (at) azukinet.com, make reference to the azukinet.com domain which was, according to the relevant GoDaddy WHOIS record, registered anew on or about 2011-05-12, some twelve years -after- the original assignment, by ARIN, of the 216.179.128.0/17 block to Azuki, LLC. The absence of evidence of the contnuous registration of this one and only contact domain name since the original 1999 assignment, by ARIN, of the 216.179.128.0/17 address block also tends to support the theory that this valuable address block has been illicitly and perhaps illegally appropriated by some party or parties unknown, and specifically via the fradulent ruse of a corporate identity theft. Quite simply, my theory is that following the demise of the original Azuki, LLC, sometime in the 2000s, some enterprising crook registered the domain name azukinet.com in order to successfully impersonate the actual and original Azuki, LLC, specifically when interacting with ARIN staff members. This simple ruse appears to have worked successfully for its intended purpose. Additionally, attempts to call the contact phone number for Azuki, LLC, (+1-213-304-6809) as currently listed in both the relevant ASN and the relevant IP block WHOIS records, during normal business hours, Eastern Daylight Time, yield only an anonymous answering machine recording. (The recorded message does not even state the company name.) This is yet another indicator of possible deliberate deception. Last but not least, the widely-respected Spamhaus anti-spam organization has had the entirety of the 216.179.128.0/17 block listed on its anti-spam SBL list since 2019-06-08, i.e. two full months, dating backwards from today: https://www.spamhaus.org/sbl/query/SBL103083 This listing, together with additional data from passive DNS and reverse DNS scans suggest that the 216.179.128.0/17 block has been and is being used for less than entirely admirable purposes. This is yet another persuasive indicator of the possible/probable theft of the block. I will shortly be informing both hostmaster (at) arin.net and also the folks at Spamhaus of all of the above factual findings. I did however want to share this information also with the NANOG community. Some or all of you may wish to drop all packets from addresses currently announced by AS13389, and/or may wish to encourage the direct peers of AS13389 to review those peering arrangements. Of course, my exposition of all of the above facts and indicators may perhaps also serve to further educate members of the community regarding what to look for when and if suspicions are cast upon a particular IP block or ASN. In the 2008 case referenced above, which involved self-evident corporate identity theft as a ruse to steal IPv4 address assets, ARIN apparently elected not to actively seek the involvement of law enforcement, even though the multiple clearly fraudulent actions undertaken in that case were altogether apparent and were clearly perpetrated quite deliberately and directly against ARIN. In multiple more recent instances in which ARIN has, allegedly, been targeted and defrauded, ARIN appears to have become more proactive in seeking the involvement of criminal law enforcement. Specifically, in addition to the well-publicized, notorious, and ongoing "Micfo" case, a less well reported federal criminal case (3:18-cr-04683-GPC), filed the Southern District of California last year, is currently ongoing. This case also and likewise attempts to hold to account, criminally, a different set of actors who also are alleged to have perpetrated a rather elaborate fraud against ARIN for the purpose of illicitly obtaining control over a number of IPv4 address blocks. Personally, I am gratified that ARIN is nowadays taking this more forward leaning posture towards those criminal actors who would attempt to use fraud and deception to surreptitiously obtain IPv4 address blocks. I do also hope that if the tenative conclusions of this public report are borne out by subsequent investigation, that ARIN will again and likewise seek an appropriate response from elements of the criminal law enforcement community. We cannot have and should not have these kinds of events happening again and again. Some appropriate deterrence against ALL of these kinds of crooks is therefore no longer optional. Regards, rfg From lee.howard at retevia.net Fri Aug 9 17:19:54 2019 From: lee.howard at retevia.net (Lee Howard) Date: Fri, 9 Aug 2019 13:19:54 -0400 Subject: MAP-E In-Reply-To: <87h86qj44v.fsf@luffy.cx> References: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> <87h86qj44v.fsf@luffy.cx> Message-ID: <0ed49f42-d807-7086-94e2-3e4823fc8537@retevia.net> On 8/9/19 1:32 AM, Vincent Bernat wrote: > ❦ 8 août 2019 16:18 -04, Lee Howard : > >> NAT64. IPv6-only to users. DNS resolver given in provisioning >> information is a DNS64 server. When it does a lookup but there's no >> AAAA, it invents one based on the A record (e.g., 2001:db8:64::> address>). The IPv6 prefix in the invented AAAA is actually a NAT64 >> translator. Pro: no CPE support required, well understood. Con: No >> support for IPv4-only stuff in the prem, breaks DNSSEC. > Is there a known deployment for a medium/large ISP? Not a fixed/wireline ISP. The "con" that consumers' game consoles, smart TVs, and IoT things won't work is a pretty big "con." I was working with a small ISP that was running out of IPv4 addresses, and they kept saying "NAT64." I warned them that while NAT64 would solve their runout problem, it would drive a lot of unhappy customer calls. It would be interesting if someone offered a NAT64 service (maybe for a reduced price). Buyers could tell consumer electronics companies, "I can't use your device without IPv6." But qualifying the customer who would do that would be more expensive, I think, than just buying IPv4 addresses. Also but, would that be a Net Neutrality problem, charging less for a service that has arguably worse access to Amazon, Reddit, Twitter, etc.? Lee > > Thanks. From aaron at wholesaleinternet.net Fri Aug 9 17:23:53 2019 From: aaron at wholesaleinternet.net (Aaron) Date: Fri, 9 Aug 2019 12:23:53 -0500 Subject: Mx204 alternative In-Reply-To: References: Message-ID: <0bbaa682-3ac8-00f1-055b-b7c828171276@wholesaleinternet.net> I would recommend the SLX9640.  12x 100G and 24x 1G/10G ports. 4 million routes in hardware without compression.  We've gotten 5.7M in there with compression.  Price point is super good.  Push them and they will get very aggressive on price.  VERY aggressive. Aaron On 8/7/2019 10:33 PM, Brandon Martin wrote: > On 8/7/19 11:02 PM, Mehmet Akcin wrote: >> I am looking for some suggestions on alternatives to mx204. >> >> Any recommendations on something more affordable which can handle >> full routing tables from two providers? >> >> Prefer Juniper but happy to look alternatives. >> Min 6-8 10G ports are required >> 1G support required > > Extreme (ex Brocade) SLX9540 will do full tables from a couple > providers in a local edge scenario with their "OptiScale" FIB > optimization/route caching, but the whole FIB won't fit in hardware.  > Bandwidth is very generous (up to 48x10G + 6x100G), and prices are > reasonable.  You wouldn't need any of the stupid port licenses, just > the advanced feature license, so it should be about 25-40% more than > an MX204 based on public pricing I've seen.  That would get you 24x10G > + 24x1G (the rest of the hardware is all there just locked out). > > The SLX9650 will supposedly (if marketing and my SEs are to believed) > do 4M IPv4 in hardware FIB, less if you want IPv6, too but still full > tables of both with ample room for L2 MACs, next-hops, and MPLS. > Bandwidth is, well, "Extreme" at I think 24x25G + 12x100G (25G > breakout capable, all 25G also capable of 1G/10G).  Pricing is > supposedly "about double" a 9540. > > Be advised that the control plane SOFTWARE is NOT as mature as JunOS. > It's being built up rapidly, but there's still a lot of stuff missing. > I have not, so far, run into any of the weird glitches that I've seen > on older Foundry/Brocade products, though, so that's good.  There's > also no oddball restrictions about port provisioning like the MX204 > has. Control plane HARDWARE is well more than capable with something > like 16GB (or maybe 32?) of RAM and a Xeon CPU.  There's actually a > fully supported option for a guest VM for local analytics, SDN, etc. > in remote scenarios. > > If you just want to push packets, they're nice boxes.  If you want > "high touch" service provider features, I think you may find them > lacking. They're worth looking at, though, if only because of the > price/performance ratio. > > Arista has some similar boxes with similar caveats in terms of > infantile software. > > MX204 is a very nice pizza box router for service providers.  I'm not > aware of anything quite like it in terms of having a mature control > plane.  I like the JunOS config language better than Cisco-style that > most other folks use. -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================ From cscora at apnic.net Fri Aug 9 18:03:53 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Aug 2019 04:03:53 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190809180353.B9FCBC44A1@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 10 Aug, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 767230 Prefixes after maximum aggregation (per Origin AS): 295222 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 369331 Total ASes present in the Internet Routing Table: 65109 Prefixes per ASN: 11.78 Origin-only ASes present in the Internet Routing Table: 55990 Origin ASes announcing only one prefix: 23960 Transit ASes present in the Internet Routing Table: 9119 Transit-only ASes present in the Internet Routing Table: 277 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: 28 Number of instances of unregistered ASNs: 28 Number of 32-bit ASNs allocated by the RIRs: 28163 Number of 32-bit ASNs visible in the Routing Table: 22999 Prefixes from 32-bit ASNs in the Routing Table: 104209 Number of bogon 32-bit ASNs visible in the Routing Table: 15 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 319 Number of addresses announced to Internet: 2842564736 Equivalent to 169 /8s, 110 /16s and 24 /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: 256682 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 206978 Total APNIC prefixes after maximum aggregation: 61718 APNIC Deaggregation factor: 3.35 Prefixes being announced from the APNIC address blocks: 202028 Unique aggregates announced from the APNIC address blocks: 84218 APNIC Region origin ASes present in the Internet Routing Table: 9953 APNIC Prefixes per ASN: 20.30 APNIC Region origin ASes announcing only one prefix: 2753 APNIC Region transit ASes present in the Internet Routing Table: 1486 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4951 Number of APNIC addresses announced to Internet: 771164416 Equivalent to 45 /8s, 247 /16s and 9 /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: 226878 Total ARIN prefixes after maximum aggregation: 106045 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 225722 Unique aggregates announced from the ARIN address blocks: 107208 ARIN Region origin ASes present in the Internet Routing Table: 18543 ARIN Prefixes per ASN: 12.17 ARIN Region origin ASes announcing only one prefix: 6851 ARIN Region transit ASes present in the Internet Routing Table: 1911 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: 2846 Number of ARIN addresses announced to Internet: 1070644096 Equivalent to 63 /8s, 208 /16s and 187 /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: 213917 Total RIPE prefixes after maximum aggregation: 100258 RIPE Deaggregation factor: 2.13 Prefixes being announced from the RIPE address blocks: 210214 Unique aggregates announced from the RIPE address blocks: 123893 RIPE Region origin ASes present in the Internet Routing Table: 26313 RIPE Prefixes per ASN: 7.99 RIPE Region origin ASes announcing only one prefix: 11623 RIPE Region transit ASes present in the Internet Routing Table: 3738 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: 8355 Number of RIPE addresses announced to Internet: 721023744 Equivalent to 42 /8s, 249 /16s and 243 /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: 98588 Total LACNIC prefixes after maximum aggregation: 22831 LACNIC Deaggregation factor: 4.32 Prefixes being announced from the LACNIC address blocks: 99842 Unique aggregates announced from the LACNIC address blocks: 44130 LACNIC Region origin ASes present in the Internet Routing Table: 8700 LACNIC Prefixes per ASN: 11.48 LACNIC Region origin ASes announcing only one prefix: 2277 LACNIC Region transit ASes present in the Internet Routing Table: 1608 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: 6259 Number of LACNIC addresses announced to Internet: 173506048 Equivalent to 10 /8s, 87 /16s and 126 /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: 20840 Total AfriNIC prefixes after maximum aggregation: 4347 AfriNIC Deaggregation factor: 4.79 Prefixes being announced from the AfriNIC address blocks: 29105 Unique aggregates announced from the AfriNIC address blocks: 9593 AfriNIC Region origin ASes present in the Internet Routing Table: 1306 AfriNIC Prefixes per ASN: 22.29 AfriNIC Region origin ASes announcing only one prefix: 456 AfriNIC Region transit ASes present in the Internet Routing Table: 251 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: 588 Number of AfriNIC addresses announced to Internet: 105970944 Equivalent to 6 /8s, 80 /16s and 253 /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 4876 595 572 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3230 1459 31 VIETEL-AS-AP Viettel Group, VN 45899 3057 1766 113 VNPT-AS-VN VNPT Corp, VN 9829 2732 1494 547 BSNL-NIB National Internet Backbone, IN 9808 2730 9043 63 CMNET-GD Guangdong Mobile Communication 4766 2523 11118 756 KIXS-AS-KR Korea Telecom, KR 7713 2226 670 591 TELKOMNET-AS-AP PT Telekomunikasi Indon 4755 2156 442 192 TATACOMM-AS TATA Communications formerl 9498 2153 431 210 BBIL-AP BHARTI Airtel Ltd., IN 9394 2066 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 3676 240 621 CABLEONE - CABLE ONE, INC., US 6327 3533 1324 90 SHAW - Shaw Communications Inc., CA 22773 3451 2974 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 3069 6392 1455 AMAZON-02 - Amazon.com, Inc., US 16625 2678 1406 1939 AKAMAI-AS - Akamai Technologies, Inc., 30036 2171 348 213 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2150 2756 532 CHARTER-20115 - Charter Communications, 18566 2093 405 107 MEGAPATH5-US - MegaPath Corporation, US 5650 2073 3073 1451 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 5489 1629 141 UNI2-AS, ES 39891 3780 219 19 ALJAWWALSTC-AS, SA 8551 3326 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2726 505 1929 AKAMAI-ASN1, US 31334 2612 484 13 KABELDEUTSCHLAND-AS, DE 12389 2363 2230 662 ROSTELECOM-AS, RU 34984 2116 346 545 TELLCOM-AS, TR 9009 1665 180 910 M247, GB 9121 1605 1692 18 TTNET, TR 13188 1604 100 47 TRIOLAN, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6228 3370 597 Uninet S.A. de C.V., MX 10620 3384 533 455 Telmex Colombia S.A., CO 11830 2691 370 54 Instituto Costarricense de Electricidad 6503 1612 379 417 Axtel, S.A.B. de C.V., MX 7303 1477 1026 276 Telecom Argentina S.A., AR 28573 1178 2238 208 CLARO S.A., BR 6147 1092 377 31 Telefonica del Peru S.A.A., PE 3816 1046 526 119 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 988 478 246 Mega Cable, S.A. de C.V., MX 11172 936 111 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 1114 393 21 LINKdotNET-AS, EG 36992 923 1535 76 ETISALAT-MISR, EG 24835 888 634 22 RAYA-AS, EG 36903 843 424 112 MT-MPLS, MA 8452 669 1859 20 TE-AS TE-AS, EG 29571 523 68 11 ORANGE-COTE-IVOIRE, CI 37492 482 470 57 ORANGE-, TN 15399 414 45 11 WANANCHI-, KE 37342 414 32 1 MOVITEL, MZ 15706 361 32 6 Sudatel, SD 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 6228 3370 597 Uninet S.A. de C.V., MX 12479 5489 1629 141 UNI2-AS, ES 7545 4876 595 572 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 3676 240 621 CABLEONE - CABLE ONE, INC., US 6327 3533 1324 90 SHAW - Shaw Communications Inc., CA 22773 3451 2974 158 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3384 533 455 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 5489 5348 UNI2-AS, ES 7545 4876 4304 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4064 4039 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3780 3761 ALJAWWALSTC-AS, SA 6327 3533 3443 SHAW - Shaw Communications Inc., CA 22773 3451 3293 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3326 3280 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3230 3199 VIETEL-AS-AP Viettel Group, VN 11492 3676 3055 CABLEONE - CABLE ONE, INC., US 45899 3057 2944 VNPT-AS-VN VNPT Corp, VN 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 66088 UNALLOCATED 103.136.230.0/24 138903 KHILGAON-AS-AP KHILGAON DOT NE 65549 DOCUMENT 117.239.163.0/24 65544 UNKNOWN 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:102 /12:293 /13:571 /14:1131 /15:1896 /16:13262 /17:8045 /18:13922 /19:25818 /20:40411 /21:47312 /22:95599 /23:77522 /24:440215 /25:1072 /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 4445 5489 UNI2-AS, ES 6327 3322 3533 SHAW - Shaw Communications Inc., CA 7155 3156 4064 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 3780 ALJAWWALSTC-AS, SA 11492 2881 3676 CABLEONE - CABLE ONE, INC., US 8551 2779 3326 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2680 3451 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 31334 2501 2612 KABELDEUTSCHLAND-AS, DE 11830 2039 2691 Instituto Costarricense de Electricidad y Telec 18566 1988 2093 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1729 2:1068 3:6 4:20 5:3066 6:49 7:1 8:1343 9:1 12:1793 13:391 14:2081 15:41 16:7 17:265 18:80 20:57 23:2866 24:2586 25:4 27:2449 31:2703 32:106 35:38 36:920 37:3140 38:1798 39:294 40:107 41:3313 42:836 43:2072 44:169 45:9499 46:3401 47:264 49:1435 50:1096 51:340 52:1014 54:273 55:641 56:6 57:47 58:1889 59:1107 60:564 61:2186 62:1970 63:1848 64:5008 65:2236 66:4786 67:2731 68:1182 69:3575 70:1382 71:661 72:2677 74:2695 75:1294 76:572 77:2541 78:1855 79:2373 80:1822 81:1490 82:1148 83:943 84:1155 85:2315 86:550 87:1533 88:1055 89:2563 90:223 91:6604 92:1443 93:2482 94:2504 95:3633 96:946 97:341 98:944 99:815 100:88 101:1188 102:606 103:21861 104:3630 105:282 106:793 107:1783 108:700 109:3784 110:1726 111:2007 112:1541 113:1404 114:1278 115:1751 116:1759 117:1967 118:2217 119:1640 120:1060 121:1064 122:2293 123:1805 124:1513 125:2033 128:1383 129:855 130:554 131:1828 132:771 133:223 134:1089 135:258 136:584 137:799 138:2080 139:919 140:616 141:894 142:784 143:1088 144:887 145:276 146:1370 147:838 148:1762 149:1013 150:822 151:1019 152:1110 153:345 154:4368 155:886 156:1995 157:1051 158:678 159:1951 160:1605 161:955 162:2983 163:834 164:1239 165:1177 166:516 167:1407 168:3457 169:482 170:4207 171:614 172:1702 173:2218 174:1039 175:993 176:2458 177:4009 178:2740 179:1391 180:2151 181:2368 182:2757 183:1113 184:2285 185:15445 186:3695 187:2485 188:3501 189:2016 190:8228 191:1463 192:10101 193:6752 194:5501 195:4181 196:3081 197:1745 198:5943 199:5975 200:7160 201:5121 202:10380 203:10247 204:4559 205:3074 206:3232 207:3247 208:3948 209:4283 210:3942 211:2032 212:3245 213:2952 214:1127 215:54 216:5906 217:2241 218:875 219:607 220:1923 221:969 222:980 223:1374 End of report From lists at packetflux.com Fri Aug 9 18:18:09 2019 From: lists at packetflux.com (Forrest Christian (List Account)) Date: Fri, 9 Aug 2019 11:18:09 -0700 Subject: Mx204 alternative In-Reply-To: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> References: <1547897409.140126.1565239564491.JavaMail.zimbra@network1.net> Message-ID: I'll inject two of my own questions here... Assuming one can find a used mx204, what is the official juniper licensing policy? It looks like I'm going to be replacing our core cisco in the not too distant future due to running out of fib entries, and am looking at options. Am I reading the specs correctly that the mx204 should handle typical internet routing table growth for the next few years? On Wed, Aug 7, 2019, 9:47 PM Randy Carpenter wrote: > If you don't require redundant routing engines, there is nothing from > Juniper that will cost less and have the capacity you require. In fact, > there really aren't any cheaper MX options at all, other than the > kneecapped MX80 and MX104 variants. MX204 is really a nice box. I only wish > they had a redundant version. > > Is price your only concern with the MX204? You might not need the full > blown -R or -IR version, so the list price would only be ~$45K. > > I'm not too familiar with other vendors, so I'll leave that to others. > > thanks, > -Randy > > ----- On Aug 7, 2019, at 11:02 PM, Mehmet Akcin wrote: > > Greetings, > > I am looking for some suggestions on alternatives to mx204. > > Any recommendations on something more affordable which can handle full > routing tables from two providers? > > Prefer Juniper but happy to look alternatives. > Min 6-8 10G ports are required > 1G support required > > Thanks in advance! > > Mehmet > -- > Mehmet > +1-424-298-1903 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Fri Aug 9 19:05:58 2019 From: sander at steffann.nl (Sander Steffann) Date: Fri, 9 Aug 2019 21:05:58 +0200 Subject: MAP-E In-Reply-To: <0ed49f42-d807-7086-94e2-3e4823fc8537@retevia.net> References: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> <87h86qj44v.fsf@luffy.cx> <0ed49f42-d807-7086-94e2-3e4823fc8537@retevia.net> Message-ID: <69070524-F1A9-4C8D-BF1B-85941FFB7CF2@steffann.nl> Hi Lee, > Also but, would that be a Net Neutrality problem, charging less for a service that has arguably worse access to Amazon, Reddit, Twitter, etc.? Net neutrality as it is here in Europe usually is satisfied when no preferential treatment is given to a limited set of services (Netflix has higher priority than Amazon Prime etc). The European regulators don't seem to specify things in technical terms but in "Apps" and "Services". As long as you don't treat those unfairly you should be fine. When you tell a regulator "yes, the new standard works better than the old standard, and we encourage everybody to support that new standard (which is a recognised best practice)" then there shouldn't be any problem. 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: From rfg at tristatelogic.com Fri Aug 9 20:09:39 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 09 Aug 2019 13:09:39 -0700 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: <18117.1565294025@segfault.tristatelogic.com> Message-ID: <23645.1565381379@segfault.tristatelogic.com> Further investigation of this case obliges me to post the following correction and retraction. Additional evidence now strongly suggests that the 216.179.128.0/17 IP address block has NOT been "stolen" as I had suggested yesterday. I simply mis-read the ARIN historical registration ("WhoWas") data with repect to this block. In fact, the ARIN historical "WhoWas" registration data for this block indicates that when the block was first assigned, by ARIN... which the historical WhoWas records show as occuring on 06-24-2002... the block was assigned to a Southern California company named HHSI, Inc. Records available on the California Secretary of State's web site indicate that this company was first registered with the State of California 02/11/2002. Oddly, some seven years would pass after the registration of this California corporation before any documents were filed with California which would designate any officers of the company. On 03/02/2009 however a filing was made indicating the President of the company was a gentleman named Koji Ban. Additional corporate filings in subsequent years indicate that both Mr. Ban and the company, HHSI, Inc. were located at 20 Arches, Irvine, CA 92603. On or about 02-17-2010 the public WHOIS record for the 216.179.128.0/17 block was changed so that instead of designating HHSI, Inc. (California) as the block's registrant, the WHOIS record for the block would henceforth say instead that the registrant of the block was the 2009 vintage Delaware LLC called Azuki, LLC. Unfortunately, we cannot read too much into this change that was made to the block's public-facing WHOIS record. Neither the new WHOIS info nor even the old WHOIS info can be used to reliably infer who or what is the legitimate registrant of the block at any point in time. This is because ARIN, like all of the other Regional Internet Registries, allows registrants to put essentially any bovine excrement they desire into their public-facing WHOIS records. (And, it should be noted, the man behind the recent large scale "Micfo" fraud apparently availed himself of this exact opportunity far subterfuge, in spades.) Regardless, the available records suggest that there are only two likely possibilities in this case: 1) On or about 02-17-2010 HHSI, Inc. (California) transfered the registration of the 216.179.128.0/17 block from itself to the 2009 vintage Delaware entity Azuki, LLC. If this is what happened, then it is likely that the transfer was performed in violation of the applicable ARIN trasfer policy that was in force at the time. (Azuki, LLC did not simply buy-out HHSI, Inc., lock, stock, and barrel in 2010. California records show that HHSI, Inc. continued to be an active California corporation until at least 02/12/2014, and probably well beyond that date.) 2) Alternatively, on or about 02-17-2010 HHSI, Inc. (California) simply altered what would henceforth appear in the public-facing WHOIS record for the the 216.179.128.0/17 block to make it appear... to everyone except ARIN staff, who knew better... that the block was now registered to Azuki, LLC in Delaware. Only ARIN staff can tell us which of these possibilities actually applies. But due to ARIN's strict adherence to contractual confidentiality with respect to all of their resource holders, I do not anticipate that ARIN will actually provide any clarity on this case anytime soon. To summarize, either the block was transferred in 2010 in violation of ARIN's own transfer policy or else the information that we have all been looking at in this block's WHOIS record since 02-17-2010 is and has been nothing other than a very deliberate and bald-faced lie. There is no third option. Regardless of which of the two possible scenarios applies, it is a dead certainty that the registration of the 216.179.128.0/17 block was indeed transferred away from HHSI, Inc. at some point in time, and in a manner that most probably did not comport with applicable ARIN transfer restrictions in place at the time. I say this without fear of contradiction because the State of California currently lists HHSI, Inc. as "suspended". Legally speaking, it no longer exists. It cannot therefore still be a valid contractual counterparty, with ARIN, or with respect to the registration of *any* ARIN-administered resources. All of this ambiguity, and all of these crooked deception games are enabled and materially aided and abetted by the disastrous interplay of two longstanding policies that are and have been in force, for many many years, both at ARIN an also at all of the other RIRs, namely: *) Excessive anal retentiveness with respect to corporate confidentiality which deprives the public at large from even knowing even so much as the accurate and correct legal names of resource holders. *) Policies which permit resource holders to place any arbitrary garbage they desire into their associated public-facing WHOIS records, without there being any vetting at all of that information by the RIRs. I am not now and never have been a big fan of ICANN, but to ICANN"s credit, it at least had the good sense to recognize, years ago, that crooks are in fact present on the Internet, and that many of them have no qualms at all about putting deliberately misleading garbage into the WHOIS records for their registered domain names. As a result, ICANN developed both policies and procedures, feeble though they may be, to try to respond to this perennial and ongoing problem. I do wonder what sort of catastrophy it is going to take before the Regional Internet Registries likewise take at least some affirmative steps to address the fact that -their- WHOIS records are now also (and provably) contaminated with unreliable garbage, put there deliberately by various flavors of Internet miscreants intent on harming the rest of us honest netizens. Regards, rfg From ximaera at gmail.com Fri Aug 9 20:44:29 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Fri, 9 Aug 2019 23:44:29 +0300 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: <18117.1565294025@segfault.tristatelogic.com> References: <18117.1565294025@segfault.tristatelogic.com> Message-ID: Peace, On Thu, Aug 8, 2019 at 10:54 PM Ronald F. Guilmette wrote: > Corporate identity theft is a simple ploy which may be used to illicitly > obtain valuable IPv4 address space. Actual use of this fradulent ploy > was first described publicly in April, 2008 (https://wapo.st/2YLEhlZ). nostromo:tmp ximaera$ wc guilmette_combined.mbox 249 2122 13695 guilmette_combined.mbox nostromo:tmp ximaera$ I wish I had enough spare time to read this. May we have a tl;dr version of this? -- Töma From lists.nanog at monmotha.net Fri Aug 9 21:19:05 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 9 Aug 2019 17:19:05 -0400 Subject: Mx204 alternative In-Reply-To: <0bbaa682-3ac8-00f1-055b-b7c828171276@wholesaleinternet.net> References: <0bbaa682-3ac8-00f1-055b-b7c828171276@wholesaleinternet.net> Message-ID: <205addaf-a395-07ef-0644-f6d748b8f734@monmotha.net> On 8/9/19 1:23 PM, Aaron wrote: > We've gotten 5.7M in there with compression. Out of curiosity, what are you doing that has 5.7M routes in a single routing area? That's a lot of edge routes, tons of VRFs, or something. > Push them and they will get very aggressive on price. VERY aggressive. Yes, yes they will. I've seen some distributor pricing and, while not officially under NDA, I will not mention it directly. Suffice to say you should demand at least 40-50% off list from your vendor to start with. -- Brandon Martin From aaron at wholesaleinternet.net Fri Aug 9 22:15:15 2019 From: aaron at wholesaleinternet.net (Aaron) Date: Fri, 9 Aug 2019 17:15:15 -0500 Subject: Mx204 alternative In-Reply-To: <205addaf-a395-07ef-0644-f6d748b8f734@monmotha.net> References: <0bbaa682-3ac8-00f1-055b-b7c828171276@wholesaleinternet.net> <205addaf-a395-07ef-0644-f6d748b8f734@monmotha.net> Message-ID: <990d0607-e10c-a79e-c3b8-ce0d01a6ae24@wholesaleinternet.net> On 8/9/2019 4:19 PM, Brandon Martin wrote: > On 8/9/19 1:23 PM, Aaron wrote: >> We've gotten 5.7M in there with compression. > > Out of curiosity, what are you doing that has 5.7M routes in a single > routing area?  That's a lot of edge routes, tons of VRFs, or something. They were generated just for testing. > >> Push them and they will get very aggressive on price.  VERY aggressive. > > Yes, yes they will.  I've seen some distributor pricing and, while not > officially under NDA, I will not mention it directly.  Suffice to say > you should demand at least 40-50% off list from your vendor to start > with. > I don't believe I'm under NDA either but all I'll say is that if you push, 40-50% isn't even close to what they'll do. From mpetach at netflight.com Fri Aug 9 23:03:39 2019 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 9 Aug 2019 16:03:39 -0700 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <517fec42-1f8b-4797-a4d5-551d5437f404@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> <58BBE0F0-DD60-4767-AECE-71A57C0CBA5E@tislabs.com> <2d008a95-b5c9-4d9c-aed0-c040f5bca164@www.fastmail.com> <517fec42-1f8b-4797-a4d5-551d5437f404@www.fastmail.com> Message-ID: On Mon, Aug 5, 2019 at 2:16 AM Scott Christopher wrote: > > [...] > It's not about $BIGCORP having lots of corporate lawyers imposing its will > on the small guys - it's about Amazon's role as a public utility, upon > which many many many important things depend. > > S.C. > > I must have missed the news amidst all the interest rate changes and tariff tweets... ...apparently Amazon has become a public utility now? I look forward with bemusement to the PUC tariff filings for AWS pricing. ^_^;; Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Sat Aug 10 00:26:25 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 09 Aug 2019 17:26:25 -0700 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: Message-ID: <24744.1565396785@segfault.tristatelogic.com> In message , Brandon Price wrote: > > > 1) On or about 02-17-2010 HHSI, Inc. (California) transfered the > registration of the 216.179.128.0/17 block from itself to the > 2009 vintage Delaware entity Azuki, LLC. If this is what happened, > then it is likely that the transfer was performed in violation > of the applicable ARIN trasfer policy that was in force at the time. > (Azuki, LLC did not simply buy-out HHSI, Inc., lock, stock, and > barrel in 2010. California records show that HHSI, Inc. continued > to be an active California corporation until at least 02/12/2014, > and probably well beyond that date.) > > >The Arin policy in affect at the time of the transfer would absolutely allow >this as an 8.2 mergers and acquisitions sale. There is no policy requirement >for a "lock, stock, and barrel" buy-out as you say. > >>From the 2010.1 version published 13 JAN 2010, ref: https://www.arin.net/va= >ult/policy/archive/nrpm_20100113.pdf > > >"ARIN will consider requests for the transfer of number resources >in the case of mergers and acquisitions upon receipt of >evidence that the new entity has acquired the assets which >had, as of the date of the acquisition or proposed >reorganization, justified the current entity's use of the number >resource. Examples of assets that justify use of the number >resource include, but are not limited to: >* Existing customer base >* Qualified hardware inventory" > >So they bought the customers and routers that were using that /17. What's >the big deal? Firstly, there is no clear evidence that I am aware of that there are any "customers" per se in this case. Spamhaus has, in effect, judged the entire 216.179.128.0/17 block as being just one big spamming operation, and I personally have no reason at this instant to take issue with that judgement. (Please note also that a generally reliable source informs me that Spamhaus has had this SBL listing for the entire 216.179.128.0/17 block active and in place since circa 2010-03-02, i.e. a full 9 years now.) So anyway, in this case we are really only talking about equipment and not "customers" per se. If I am wrong about that, please post the evidence. Second and more to the point, I think that you and I have dramatically different understandings of the plain meanings of the terms "merger" and "aquisition". The evidence indicates that HHSI, Inc. neither merged with nor was aquired by Azuki, LLC. Rather, HHSI continued to have, and to actively maintain its own separate legal existance through at least 2014... several years *after* the moment in time, on or about 02-17-2010, when the -apparent- ownership of the 216.179.128.0/17 block (going by the WHOIS records) somehow magically passed from HHSI, Inc. to Azuki, LLC. It is not my understanding of mergers and/or aquisitions that the merged (or acquired) entity continues to have and maintain a separate legal existance from the other merged (or acquiring) entity following the merger or acquisition. You, it seems, may have a different conception. Theoretically, HHSI, Inc may have been acquired by Azuki, LLC and may have then become a wholly owned subsidiary of Azuki, LLC. This would explain it's continued, simultaneous, and parallel legal existance in the years 2010 through 2014, along with Azuki, LLC. But even if this rather remote possibility applied, it would still not serve to explain the apparent 2010 transfer of the 216.179.128.0/17 block from the wholly owned subsidary to the parent entity. Why would such a transfer be either necessary or even desirable? And how would such a transfer comport with the ARIN transfer regulations in place at the time? Those regulations, as you have quoted them, DO NOT obviously sanction transfers from subsidiaries to parent entities in cases where both survive as separate legal entities. And it is not even in the least bit clear that there even was any such parent/subsididiary relationship between these two corporate entities at the time of the transfer. But in answer to your larger question, "What's the big deal?", the answer is that -all- WHOIS records for -all- IP address blocks adminstered by -all- RIRs are fundementally unvetted and thus untrustworthy. This one case is a clear and blatant example of that fundemental problem with the way all RIRs are behaving. As far as I am aware, no RIR makes any effort whatsoever to vet changes to WHOIS records, either for IP blocks or ASNs or ORG records. (And this fact was abundantly evident in the Micfo fraud case, where the man behind that fiddled the majority of the street address and other contact information appearing in the public-facing WHOIS records for the blocks assigned to his various phony baloney shell companies in a now-obvious attempt to mislead both the public and also anti-abuse investigators.) Someday soon, because of policies in place at all of the RIRs, you're going to get some spam, or a hack attempt from a specific IP address, and when you go to look up the registrant of the containing IP address block you're going to find out that it is registered to Bozo the Clown, whose mailing address is 1600 Pennsylvania Ave., Washington D.C. and whose contact office phone number is 1-734-930-3030. (Google it.) Worse, that utterly bogus information may appear in the WHOIS record for the ASN that is currently announcing more specifics for parts of YOUR address space. If you don't see any of this as an actual problem. then please just forget I mentioned it. Regards, rfg From ross at tajvar.io Sat Aug 10 00:33:13 2019 From: ross at tajvar.io (Ross Tajvar) Date: Fri, 9 Aug 2019 20:33:13 -0400 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: References: <18117.1565294025@segfault.tristatelogic.com> Message-ID: First he thought that a /17 got stolen (by creating a company with the same name as the original, now-defunct owner), but he then said he was wrong and actually it either 1) got transferred against ARIN policy or 2) was made to look like it was transferred by altering the whois data. On Fri, Aug 9, 2019, 4:47 PM Töma Gavrichenkov wrote: > Peace, > > On Thu, Aug 8, 2019 at 10:54 PM Ronald F. Guilmette > wrote: > > Corporate identity theft is a simple ploy which may be used to illicitly > > obtain valuable IPv4 address space. Actual use of this fradulent ploy > > was first described publicly in April, 2008 (https://wapo.st/2YLEhlZ). > > nostromo:tmp ximaera$ wc guilmette_combined.mbox > 249 2122 13695 guilmette_combined.mbox > nostromo:tmp ximaera$ > > I wish I had enough spare time to read this. > > May we have a tl;dr version of this? > > -- > Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels=nanog at bakker.net Sat Aug 10 00:38:20 2019 From: niels=nanog at bakker.net (Niels Bakker) Date: Sat, 10 Aug 2019 02:38:20 +0200 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: <24744.1565396785@segfault.tristatelogic.com> References: <24744.1565396785@segfault.tristatelogic.com> Message-ID: <20190810003820.GD2592@jima.tpb.net> * rfg at tristatelogic.com (Ronald F. Guilmette) [Sat 10 Aug 2019, 02:26 CEST]: >As far as I am aware, no RIR makes any effort whatsoever to vet >changes to WHOIS records, either for IP blocks or ASNs or ORG >records. This is hilarious. You should hear the whining from any EU-based operator who has to implement the transfer of RIPE NCC resources in a corporate acquisition. I recently was involved with one of those and the amount of due diligence required by the RIPE NCC was pretty intense. If I were at an RIR I'd be insulted by your claim of "no... effort whatsoever". -- Niels. From rfg at tristatelogic.com Sat Aug 10 00:54:42 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 09 Aug 2019 17:54:42 -0700 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: Message-ID: <24882.1565398482@segfault.tristatelogic.com> In message Ross Tajvar wrote: >First he thought that a /17 got stolen (by creating a company with the same >name as the original, now-defunct owner), but he then said he was wrong and >actually it either 1) got transferred against ARIN policy or 2) was made to >look like it was transferred by altering the whois data. Yes. What he said. Although he left out the imporant detail that the whole thing appears to be just a smokescreen cover for a large spamming operation, which apparently targets primarily the Japanese market and which appears to have been ongoing since at least 2004: https://yomi.tokyo/agate/toki/bouhan/1103682730/1-/a Regards, rfg From list at satchell.net Sat Aug 10 01:29:53 2019 From: list at satchell.net (Stephen Satchell) Date: Fri, 9 Aug 2019 18:29:53 -0700 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> <2d008a95-b5c9-4d9c-aed0-c040f5bca164@www.fastmail.com> <517fec42-1f8b-4797-a4d5-551d5437f404@www.fastmail.com> Message-ID: On 8/9/19 4:03 PM, Matthew Petach wrote: > ...apparently Amazon has become a public utility > now? > > I look forward with bemusement to the PUC > tariff filings for AWS pricing. ^_^;; Don't scoff too hard. How do you think that telephone service became a utility? Utilities didn't grow on trees, they became utilities when some bureaucrats convinced legislators to "promote" successful service providers to utility status. Especially when such providers are providing a service as a monopoly. Particularly a "natural" monopoly. AWS has competitors, but if the number of providers remains small (like fingers of one hand) the politicians wil step in. And it wouldn't be the PUC, as Amazon is a company national in scope. It would be something like the FCC. Public Utility Commissions are at the local (usually county) or state level. From saku at ytti.fi Sat Aug 10 06:29:33 2019 From: saku at ytti.fi (Saku Ytti) Date: Sat, 10 Aug 2019 09:29:33 +0300 Subject: Mx204 alternative In-Reply-To: <205addaf-a395-07ef-0644-f6d748b8f734@monmotha.net> References: <0bbaa682-3ac8-00f1-055b-b7c828171276@wholesaleinternet.net> <205addaf-a395-07ef-0644-f6d748b8f734@monmotha.net> Message-ID: On Sat, 10 Aug 2019 at 00:22, Brandon Martin wrote: > Yes, yes they will. I've seen some distributor pricing and, while not > officially under NDA, I will not mention it directly. Suffice to say > you should demand at least 40-50% off list from your vendor to start with. You get better price from newegg for CSCO gear. -- ++ytti From mohta at necom830.hpcl.titech.ac.jp Sat Aug 10 07:13:44 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 10 Aug 2019 16:13:44 +0900 Subject: MAP-E In-Reply-To: References: <54c10ab2-cd1e-ba66-5446-c3263d5b1a78@retevia.net> Message-ID: Lee Howard wrote: >> So, all we need is NAT44 CPE, which only uses a reserved block of ports, >> which is (semi) statically configured by ISP operated gateway. >> > How would you route from the provider edge? > > If CPE A has 192.0.2.15 port 1000-2999 > > and CPE B has 192.0.2.15 port 3000-4999, Oops,I concentrated on minimizing logging and forgot about that. Sorry. I assume COE gateway also act as NAT44, though no port translation necessary there. > how does your BRAS or CMTS or edge router know whether to forward a > packet to A or B? Incoming packets are forwarded to A or B by private IP address of A or B based on source port. Depending on configuration, some port may always accept incoming packets and other port accept incoming packets only when the port is used by an outgoing connection. >> Pro: Stateless, very efficient, no IPv6 necessary Con: No current >> CPE support. >> >> As for protocol, assuming port mapping on UPnP gateway is statically >> configured by ISPs not changable from CPE side, GetListOfPortMappings() >> of UPnP should be useful for CPEs to know range of ports to be used >> by them. > > Do CPEs do this now, or is this another feature to ask vendors for? I think there is no current CPE support. COE supporting GetListOfPortMappings() may not exist, either. Masataka Ohta From jared at puck.nether.net Sat Aug 10 11:48:13 2019 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 10 Aug 2019 07:48:13 -0400 Subject: Mx204 alternative In-Reply-To: References: Message-ID: <7CF2C285-7439-45BC-9A08-DC223B5F7471@puck.nether.net> I have to agree with Eric here. 1G should be relegated elsewhere. If you ask for something that does all these speeds you will soon ask for 10m and that’s a wide range. I would go with a 72q and if something needs 1G then add a switch or similar. Something like that Arista 7050 while EOL will cover this well and can be had for cheap. Sent from my iCar > On Aug 8, 2019, at 8:20 AM, Eric Kuhnke wrote: > > I am not certain on the value of having 1GbE interfaces natively on a $25k plus router in the year 2019. Pair the router with a nice 1RU 1/10GbE switch installed directly next to it with full metro Ethernet layer 2 feature set. > > Anything that needs a 1GbE inteface, attach it to that switch, give the switch a single 10GbE port to the router, and create the 1Gbps on the router as a subinterface. > > We have reached the point in 10GbE being so low cost that it should really be the minimum port size for a lot of things. I recently bought an Intel chipset two port SFP+ daughtercard for a Dell server (part c63dv for an old r720) on eBay for $40. > > > >> On Wed, Aug 7, 2019, 8:04 PM Mehmet Akcin wrote: >> Greetings, >> >> I am looking for some suggestions on alternatives to mx204. >> >> Any recommendations on something more affordable which can handle full routing tables from two providers? >> >> Prefer Juniper but happy to look alternatives. >> Min 6-8 10G ports are required >> 1G support required >> >> Thanks in advance! >> >> Mehmet >> -- >> Mehmet >> +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sf at lists.esoteric.ca Sat Aug 10 12:01:24 2019 From: sf at lists.esoteric.ca (Stephen Fulton) Date: Sat, 10 Aug 2019 08:01:24 -0400 Subject: Mx204 alternative In-Reply-To: References: <0bbaa682-3ac8-00f1-055b-b7c828171276@wholesaleinternet.net> <205addaf-a395-07ef-0644-f6d748b8f734@monmotha.net> Message-ID: <5fd9b930-45b9-286c-26f4-490e0b5035c6@lists.esoteric.ca> On 2019-08-10 02:29, Saku Ytti wrote: > On Sat, 10 Aug 2019 at 00:22, Brandon Martin wrote: > >> Yes, yes they will. I've seen some distributor pricing and, while not >> officially under NDA, I will not mention it directly. Suffice to say >> you should demand at least 40-50% off list from your vendor to start with. > > You get better price from newegg for CSCO gear. > I've found that if Cisco is presented with competing quotes for comparable equipment (eg. MX204 versus ASR9901) then they have inventive to price their products competitively. That said, a lot of SP's in the Canadian market are moving to the MX204 because of the pricing and Cisco was late to ingest that fact internally. -- S From lists.nanog at monmotha.net Sat Aug 10 12:06:15 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Sat, 10 Aug 2019 08:06:15 -0400 Subject: Mx204 alternative In-Reply-To: References: <0bbaa682-3ac8-00f1-055b-b7c828171276@wholesaleinternet.net> <205addaf-a395-07ef-0644-f6d748b8f734@monmotha.net> Message-ID: On 8/10/19 2:29 AM, Saku Ytti wrote: > You get better price from newegg for CSCO gear. You'll note I said "start". As in, laugh at any vendor who doesn't immediately give you at least that much off. As Aaron mentioned, they'll go quite a ways beyond that if you let them know that you are familiar with actual, competitive market pricing factors. -- Brandon Martin From jcurran at arin.net Mon Aug 12 19:13:42 2019 From: jcurran at arin.net (John Curran) Date: Mon, 12 Aug 2019 19:13:42 +0000 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: <23645.1565381379@segfault.tristatelogic.com> References: <23645.1565381379@segfault.tristatelogic.com> Message-ID: On 9 Aug 2019, at 4:09 PM, Ronald F. Guilmette wrote: > ... > Unfortunately, we cannot read too much into this change that was made > to the block's public-facing WHOIS record. Neither the new WHOIS info > nor even the old WHOIS info can be used to reliably infer who or what > is the legitimate registrant of the block at any point in time. This > is because ARIN, like all of the other Regional Internet Registries, > allows registrants to put essentially any bovine excrement they desire > into their public-facing WHOIS records. Ronald - That is not the case – ARIN confirms the legal status of organizations receiving number resources. > (And, it should be noted, the > man behind the recent large scale "Micfo" fraud apparently availed > himself of this exact opportunity far subterfuge, in spades.) As previously noted on this list, such was only possible because of the use of falsely notarized documents. > Regardless, the available records suggest that there are only two likely > possibilities in this case: > > 1) On or about 02-17-2010 HHSI, Inc. (California) transfered the > registration of the 216.179.128.0/17 block from itself to the > 2009 vintage Delaware entity Azuki, LLC. If this is what happened, > then it is likely that the transfer was performed in violation > of the applicable ARIN trasfer policy that was in force at the time. > (Azuki, LLC did not simply buy-out HHSI, Inc., lock, stock, and > barrel in 2010. California records show that HHSI, Inc. continued > to be an active California corporation until at least 02/12/2014, > and probably well beyond that date.) > > 2) Alternatively, on or about 02-17-2010 HHSI, Inc. (California) simply > altered what would henceforth appear in the public-facing WHOIS > record for the the 216.179.128.0/17 block to make it appear... to > everyone except ARIN staff, who knew better... that the block was > now registered to Azuki, LLC in Delaware. > > Only ARIN staff can tell us which of these possibilities actually applies. > But due to ARIN's strict adherence to contractual confidentiality with > respect to all of their resource holders, I do not anticipate that ARIN > will actually provide any clarity on this case anytime soon. That is easy to address: submit a fraud request, and it will be reviewed and corrected if it was done fraudulently. Thanks! /John John Curran President and CEO American Registry for Internet Numbers From rsk at gsp.org Mon Aug 12 19:26:22 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 12 Aug 2019 15:26:22 -0400 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <89f3dc71-36a0-7e92-5e20-b96ff04bccec@satchell.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> <051f3329-e3c8-4965-93a0-c89a41731aa6@www.fastmail.com> <58BBE0F0-DD60-4767-AECE-71A57C0CBA5E@tislabs.com> <89f3dc71-36a0-7e92-5e20-b96ff04bccec@satchell.net> Message-ID: <20190812192622.GA7757@gsp.org> On Sun, Aug 04, 2019 at 12:12:48AM -0700, Stephen Satchell wrote: > "The rules" have been around for years, and are codified in the RFCs > that are widely published and available to all at zero cost. (That > wasn't always true, as it wasn't until the DDN Protocol Handbook volumes > were published in 1985 that the RFCs were available to everyone. I seem > to recall there was an FTP site that provided the RFC documents before > that, but my memory is hazy on that.) IIRC, the CSnet CIC provided an RFC-by-mail service in the mid to late 1980's. It allowed anyone to request any RFC by number, e.g., sending it "rfc123" would result in a response containing that RFC. I also share your recollection of an earlier FTP site but a few minutes of checking old documents hasn't turned up its name and it's fallen out of long-term memory, at least for the moment. > During my career as a web server admin, mail admin, and network admin, I > followed "the rules" strictly. As the main abuse contact during my > time at a web hosting company, my postmaster@ and abuse@ contact > addresses were according to Hoyle, and published with the company ASN, > netblock, and domain registration records. I've done the same -- imperfectly, to be sure, I've certainly tried. Half my grump with Amazon here is that they have, for all practical purposes, unlimited money and unlimited personnel. They should be the go-to example for How To Do It Right. They should be the model (or one of the models) that we're all trying to emulate, the gold standard that we can all point to. But they're not. The other half of my grump is that they're enormous, and therefore capable of inflicting enormous damage. The larger an operation, the more critical it is that abuse/security/et.al. be fully supported, highly responsive, empowered to act decisively, etc. But they're not. And I have yet to see anyone from Amazon (a) admit this and (b) ask for help fixing it. ---rsk From henry at AegisInfoSys.com Mon Aug 12 19:52:08 2019 From: henry at AegisInfoSys.com (Henry Yen) Date: Mon, 12 Aug 2019 15:52:08 -0400 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <20190812192622.GA7757@gsp.org> References: <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> <89f3dc71-36a0-7e92-5e20-b96ff04bccec@satchell.net> <20190812192622.GA7757@gsp.org> Message-ID: <20190812195208.GE15082@nntp.AegisInfoSys.com> On Mon, Aug 12, 2019 at 15:26:22PM -0400, Rich Kulawiec wrote: > I also share your recollection of > an earlier FTP site but a few minutes of checking old documents hasn't turned > up its name and it's fallen out of long-term memory, at least for the moment. ftp://rfc-editor.org (also via conventional http/s) -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From james.cutler at consultant.com Mon Aug 12 19:59:15 2019 From: james.cutler at consultant.com (James R Cutler) Date: Mon, 12 Aug 2019 15:59:15 -0400 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <20190812195208.GE15082@nntp.AegisInfoSys.com> References: <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> <89f3dc71-36a0-7e92-5e20-b96ff04bccec@satchell.net> <20190812192622.GA7757@gsp.org> <20190812195208.GE15082@nntp.AegisInfoSys.com> Message-ID: > On Aug 12, 2019, at 3:52 PM, Henry Yen wrote: > > ftp://rfc-editor.org ftp://rfc-editor.org still mounts perfectly well using macOS Finder but shows to be now devoid of useful content via ftp. 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 bhm at ufl.edu Mon Aug 12 20:04:48 2019 From: bhm at ufl.edu (Bruce H McIntosh) Date: Mon, 12 Aug 2019 16:04:48 -0400 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <20190812192622.GA7757@gsp.org> 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> <89f3dc71-36a0-7e92-5e20-b96ff04bccec@satchell.net> <20190812192622.GA7757@gsp.org> Message-ID: On 8/12/19 3:26 PM, Rich Kulawiec wrote: > Half my grump with Amazon here is that they have, for all practical > purposes, unlimited money and unlimited personnel. They should be the > go-to example for How To Do It Right. They should be the model (or one > of the models) that we're all trying to emulate, the gold standard that > we can all point to. > > But they're not. > > The other half of my grump is that they're enormous, and therefore capable > of inflicting enormous damage. The larger an operation, the more critical > it is that abuse/security/et.al. be fully supported, highly responsive, > empowered to act decisively, etc. > > But they're not. > > And I have yet to see anyone from Amazon (a) admit this and (b) ask for help > fixing it. The larger they are, the more immune from having to follow the rules they think they are. -- -------------------------------------------- Bruce H. McIntosh Network Engineer II University of Florida Information Technology bhm at ufl.edu 352-273-1066 From ross at tajvar.io Mon Aug 12 20:11:00 2019 From: ross at tajvar.io (Ross Tajvar) Date: Mon, 12 Aug 2019 16:11:00 -0400 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: References: <23645.1565381379@segfault.tristatelogic.com> Message-ID: Seems like submitting a fraud request to ARIN is more effective than writing a novel and sending it to NANOG, and doesn't require the latter... On Mon, Aug 12, 2019, 3:16 PM John Curran wrote: > On 9 Aug 2019, at 4:09 PM, Ronald F. Guilmette > wrote: > > ... > > Unfortunately, we cannot read too much into this change that was made > > to the block's public-facing WHOIS record. Neither the new WHOIS info > > nor even the old WHOIS info can be used to reliably infer who or what > > is the legitimate registrant of the block at any point in time. This > > is because ARIN, like all of the other Regional Internet Registries, > > allows registrants to put essentially any bovine excrement they desire > > into their public-facing WHOIS records. > > Ronald - > > That is not the case – ARIN confirms the legal status of organizations > receiving number resources. > > > (And, it should be noted, the > > man behind the recent large scale "Micfo" fraud apparently availed > > himself of this exact opportunity far subterfuge, in spades.) > > As previously noted on this list, such was only possible because of the > use of falsely notarized documents. > > > Regardless, the available records suggest that there are only two likely > > possibilities in this case: > > > > 1) On or about 02-17-2010 HHSI, Inc. (California) transfered the > > registration of the 216.179.128.0/17 block from itself to the > > 2009 vintage Delaware entity Azuki, LLC. If this is what > happened, > > then it is likely that the transfer was performed in violation > > of the applicable ARIN trasfer policy that was in force at the > time. > > (Azuki, LLC did not simply buy-out HHSI, Inc., lock, stock, and > > barrel in 2010. California records show that HHSI, Inc. continued > > to be an active California corporation until at least 02/12/2014, > > and probably well beyond that date.) > > > > 2) Alternatively, on or about 02-17-2010 HHSI, Inc. (California) > simply > > altered what would henceforth appear in the public-facing WHOIS > > record for the the 216.179.128.0/17 block to make it appear... to > > everyone except ARIN staff, who knew better... that the block was > > now registered to Azuki, LLC in Delaware. > > > > Only ARIN staff can tell us which of these possibilities actually > applies. > > But due to ARIN's strict adherence to contractual confidentiality with > > respect to all of their resource holders, I do not anticipate that ARIN > > will actually provide any clarity on this case anytime soon. > > That is easy to address: submit a fraud request, and it will be reviewed > and corrected if it was done fraudulently. > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at istaff.org Mon Aug 12 20:13:45 2019 From: jcurran at istaff.org (John Curran) Date: Mon, 12 Aug 2019 16:13:45 -0400 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <20190812192622.GA7757@gsp.org> 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> <89f3dc71-36a0-7e92-5e20-b96ff04bccec@satchell.net> <20190812192622.GA7757@gsp.org> Message-ID: On 12 Aug 2019, at 3:26 PM, Rich Kulawiec wrote: > > On Sun, Aug 04, 2019 at 12:12:48AM -0700, Stephen Satchell wrote: >> "The rules" have been around for years, and are codified in the RFCs >> that are widely published and available to all at zero cost. (That >> wasn't always true, as it wasn't until the DDN Protocol Handbook volumes >> were published in 1985 that the RFCs were available to everyone. I seem >> to recall there was an FTP site that provided the RFC documents before >> that, but my memory is hazy on that.) > > IIRC, the CSnet CIC provided an RFC-by-mail service in the mid to late 1980's. > It allowed anyone to request any RFC by number, e.g., sending it "rfc123" would > result in a response containing that RFC. Indeed - it was the "CSNET Information Server" , and it not only served RFCs but also a variety of other DDN/NSF/Merit/IETF internet informational documents... With the shutdown of the CSNET Coordination and Information Center (CSNET CIC) in 1991, the email-based info-server function was transferred to the NSF Network Service Center (NNSC) where it operated until of all the various Internet informational/registry/directory services were transferred into the consolidated InterNIC contract. FYI, /John From javier at advancedmachines.us Tue Aug 13 18:22:12 2019 From: javier at advancedmachines.us (Javier J) Date: Tue, 13 Aug 2019 14:22:12 -0400 Subject: Protecting 1Gb Ethernet From Lightning Strikes Message-ID: I'm working with a client site that has been hit twice, very close by lightening. I did lots of electrical work/upgrades/grounding but now I want to focus on protecting Ethernet connections between core switching/other devices that can't be migrated to fiber optic. I was looking for surge protection devices for Ethernet but have never shopped for anything like this before. Was wondering if anyone has deployed a solution? They don't have a large presence on site (I have been moving all of their core stuff to AWS) but they still have core networking / connectivity and PoE cameras / APs around the property. Since migrating their onsite servers/infra to the cloud, now their connectivity is even more important. This is a small site, maybe about 200 switch ports, but I would only need to protect maybe 12 core ones. but would be something I could use in the future with larger deployments. it's just a 1Gbe network BTW. Hope someone with more experience can help make hardware recommendations? Thanks in advance. - Javier -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at kumari.net Tue Aug 13 18:32:01 2019 From: warren at kumari.net (Warren Kumari) Date: Tue, 13 Aug 2019 14:32:01 -0400 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: Message-ID: This probably won't fully solve your problem, but I run a bunch of Ubiquiti access points and similar -- I suffered a number of lightning related outages, and then started using their TOUGHcable - https://www.ui.com/accessories/toughcable/ (don't forget to also get the special jacks / ends). Since changing to this I've had no more issues. You should also look at https://www.ui.com/accessories/ethernet-surge-protector/- I haven't needed them, but... W On Tue, Aug 13, 2019 at 2:23 PM Javier J wrote: > > I'm working with a client site that has been hit twice, very close by lightening. > > I did lots of electrical work/upgrades/grounding but now I want to focus on protecting Ethernet connections between core switching/other devices that can't be migrated to fiber optic. > > I was looking for surge protection devices for Ethernet but have never shopped for anything like this before. Was wondering if anyone has deployed a solution? > They don't have a large presence on site (I have been moving all of their core stuff to AWS) but they still have core networking / connectivity and PoE cameras / APs around the property. > Since migrating their onsite servers/infra to the cloud, now their connectivity is even more important. > > This is a small site, maybe about 200 switch ports, but I would only need to protect maybe 12 core ones. but would be something I could use in the future with larger deployments. > it's just a 1Gbe network BTW. > > Hope someone with more experience can help make hardware recommendations? > > Thanks in advance. > > - Javier -- 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 rob at pickering.org Tue Aug 13 18:51:39 2019 From: rob at pickering.org (Rob Pickering) Date: Tue, 13 Aug 2019 19:51:39 +0100 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: Message-ID: On Tue, 13 Aug 2019 at 19:23, Javier J wrote: > I'm working with a client site that has been hit twice, very close by > lightening. > > I did lots of electrical work/upgrades/grounding but now I want to focus > on protecting Ethernet connections between core switching/other devices > that can't be migrated to fiber optic. > > I was looking for surge protection devices for Ethernet but have never > shopped for anything like this before. Was wondering if anyone has deployed > a solution? > They don't have a large presence on site (I have been moving all of their > core stuff to AWS) but they still have core networking / connectivity and > PoE cameras / APs around the property. > Since migrating their onsite servers/infra to the cloud, now their > connectivity is even more important. > The correct answer is use fiber. If you really, really can't then APC make a single port transient arrestor p/n PNET1GB. I've used these in the past for a PoE phone in a wooden gatehouse hut right on the 100M max length with no power for active kit and they seem to work fine. I'm using one at the moment for a PoE access point in my garden shed. Not sure I would bring an inter building link in copper onto an expensive core switch though. Don't know of anything in higher density than "one port". -- Rob Pickering, rob at pickering.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake at ispn.net Tue Aug 13 18:52:37 2019 From: blake at ispn.net (Blake Hudson) Date: Tue, 13 Aug 2019 13:52:37 -0500 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: Message-ID: <3fa9b7b6-ee59-cc5e-f48d-fe2f4dca54d7@ispn.net> +1 on the Ubiquiti surge protectors specifically designed for PoE gear in mind (other brands like Cambium that are outdoor AP or camera oriented may work equally as well). I would also recommend continuing to isolate and protect as much as possible. For example, connecting your outdoor PoE cameras or APs to dedicated PoE switches that connect back to the core or aggregation switches via fiber. The PoE switches powering the outdoor gear could be connected to power on dedicated PDUs that are connected to dedicated circuits. I would imagine that PDUs that provide surge protection or on-line/line-interactive UPS units would be preferred over standby UPS units or PDUs that do not provide surge protection. Would also be nice to keep spare parts on-site or conveniently accessible, but not connected to power (e.g. focus on cold spares before focusing on hot spares). --Blake Warren Kumari wrote on 8/13/2019 1:32 PM: > This probably won't fully solve your problem, but I run a bunch of > Ubiquiti access points and similar -- I suffered a number of lightning > related outages, and then started using their TOUGHcable - > https://www.ui.com/accessories/toughcable/ > (don't forget to also get the special jacks / ends). Since changing to > this I've had no more issues. You should also look at > https://www.ui.com/accessories/ethernet-surge-protector/- I haven't > needed them, but... > > W > > > > On Tue, Aug 13, 2019 at 2:23 PM Javier J wrote: >> I'm working with a client site that has been hit twice, very close by lightening. >> >> I did lots of electrical work/upgrades/grounding but now I want to focus on protecting Ethernet connections between core switching/other devices that can't be migrated to fiber optic. >> >> I was looking for surge protection devices for Ethernet but have never shopped for anything like this before. Was wondering if anyone has deployed a solution? >> They don't have a large presence on site (I have been moving all of their core stuff to AWS) but they still have core networking / connectivity and PoE cameras / APs around the property. >> Since migrating their onsite servers/infra to the cloud, now their connectivity is even more important. >> >> This is a small site, maybe about 200 switch ports, but I would only need to protect maybe 12 core ones. but would be something I could use in the future with larger deployments. >> it's just a 1Gbe network BTW. >> >> Hope someone with more experience can help make hardware recommendations? >> >> Thanks in advance. >> >> - Javier > > From lesmith at ecsis.net Tue Aug 13 18:40:38 2019 From: lesmith at ecsis.net (Larry Smith) Date: Tue, 13 Aug 2019 13:40:38 -0500 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: Message-ID: <201908131340.38079.lesmith@ecsis.net> You might look at mccowntech.com, they make surge suppressors geared toward the wireless provider market which are pretty good. (not associated, we just use their products). -- Larry Smith lesmith at ecsis.net On Tue August 13 2019 13:22, Javier J wrote: > I'm working with a client site that has been hit twice, very close by > lightening. > > I did lots of electrical work/upgrades/grounding but now I want to focus on > protecting Ethernet connections between core switching/other devices that > can't be migrated to fiber optic. > > I was looking for surge protection devices for Ethernet but have never > shopped for anything like this before. Was wondering if anyone has deployed > a solution? > They don't have a large presence on site (I have been moving all of their > core stuff to AWS) but they still have core networking / connectivity and > PoE cameras / APs around the property. > Since migrating their onsite servers/infra to the cloud, now their > connectivity is even more important. > > This is a small site, maybe about 200 switch ports, but I would only need > to protect maybe 12 core ones. but would be something I could use in the > future with larger deployments. > it's just a 1Gbe network BTW. > > Hope someone with more experience can help make hardware recommendations? > > Thanks in advance. > > - Javier From woody at pch.net Tue Aug 13 18:56:44 2019 From: woody at pch.net (Bill Woodcock) Date: Tue, 13 Aug 2019 11:56:44 -0700 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: Message-ID: > The correct answer is use fiber. > Not sure I would bring an inter building link in copper onto an expensive core switch though. Yeah. > Don't know of anything in higher density than "one port”. This on Amazon: https://smile.amazon.com/Protector-Lightning-Suppressor-Protection-TP323/dp/B07P3XDXN3/ref=sr_1_6?keywords=apc+PNET1GB&qid=1565722471&s=gateway&sr=8-6 …but I haven’t used it, so can’t specifically recommend. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From nate at blastcomm.com Tue Aug 13 18:59:31 2019 From: nate at blastcomm.com (Nate Burke) Date: Tue, 13 Aug 2019 13:59:31 -0500 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: Message-ID: <5D530893.4040002@blastcomm.com> You will want to check out these. https://mccowntech.wptstaging.space/product-category/surge-protectors/rack-mount-surge-protectors/ They are made to fit into the 1U APC Chassis PRM24. We rely on them heavily in the WISP Market. I've had equipment on a tower that was physically destroyed by lightening, and the Router Port on the other side of these arrestors was just fine. On 8/13/2019 1:51 PM, Rob Pickering wrote: > On Tue, 13 Aug 2019 at 19:23, Javier J > wrote: > > I'm working with a client site that has been hit twice, very close > by lightening. > > I did lots of electrical work/upgrades/grounding but now I want to > focus on protecting Ethernet connections between core > switching/other devices that can't be migrated to fiber optic. > > I was looking for surge protection devices for Ethernet but have > never shopped for anything like this before. Was wondering if > anyone has deployed a solution? > They don't have a large presence on site (I have been moving all > of their core stuff to AWS) but they still have core networking / > connectivity and PoE cameras / APs around the property. > Since migrating their onsite servers/infra to the cloud, now their > connectivity is even more important. > > > The correct answer is use fiber. > > If you really, really can't then APC make a single port transient > arrestor p/n PNET1GB. > > I've used these in the past for a PoE phone in a wooden gatehouse hut > right on the 100M max length with no power for active kit and they > seem to work fine. I'm using one at the moment for a PoE access point > in my garden shed. Not sure I would bring an inter building link in > copper onto an expensive core switch though. > > Don't know of anything in higher density than "one port". > > -- > Rob Pickering, rob at pickering.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Tue Aug 13 19:17:24 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 13 Aug 2019 12:17:24 -0700 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: Message-ID: <48108.1565723844@segfault.tristatelogic.com> In message , John Curran wrote: >On 9 Aug 2019, at 4:09 PM, Ronald F. Guilmette wrote: >> ... >> Unfortunately, we cannot read too much into this change that was made >> to the block's public-facing WHOIS record. Neither the new WHOIS info >> nor even the old WHOIS info can be used to reliably infer who or what >> is the legitimate registrant of the block at any point in time. This >> is because ARIN, like all of the other Regional Internet Registries, >> allows registrants to put essentially any bovine excrement they desire >> into their public-facing WHOIS records. > >That is not the case – ARIN confirms the legal status of organizations >receiving number resources. This is NOT the message that I got from our recent discussion of the giant Micfo fraud on the ARIN Public Policy Mailing List. When I raised questions about why various of the Micfo phoney baloney shell companies has block with WHOIS records saying they were located in states that they were obviously not located in, I believe that you said that once a black has been allocated, by ARIN, to some (properly vetted) entity, that after that point in time, the entity could -change- the relevant WHOIS record to say any bloody thing it wanted, and that such -changes- to ARIN WHOIS records are not vetted in any way. If I got the Wrong Impression from your prior statements, then by all means, please do correct me. And then please do explain why several of the Micfo phony shell companies did in fact have WHOIS records for ARIN- issued IPv4 space that gave street addreses in states where none of these phony shell companies were actually registered to do business. >> (And, it should be noted, the >> man behind the recent large scale "Micfo" fraud apparently availed >> himself of this exact opportunity far subterfuge, in spades.) > >As previously noted on this list, such was only possible because of the >use of falsely notarized documents. I -do- understand that the fradulent documents that were originally presented to you/ARIN provided information indicating that the phoney Micfo shell companies -did- actually exist in -some- state (Delaware?), and that ARIN -did- verify, to the best of its ability, that those companies -did- exist, legally spekaing, in their originally declared home state(s). But that fact is just skirting the real issue here, which is the question of whether or not ARIN even looks at -changes_ that a registrant may make to the WHOIS records (e.g. for IPv4 blocks) -after- those blocks have been assigned. It appears from where I am sitting that ARIN dos not do so. And thus, I stand by my comment that a registrant -can- in fact put any bloody nonsense they want into their WHOIS records, at least as long as they do it via -changes- and not in the original/initial WHOIS records. >> Regardless, the available records suggest that there are only two likely >> possibilities in this case: >> >> {trimmed} >> 1) 216.179.128.0/17 was transferred in violation of ARIN policy. >> >> 2) The current WHOIS for 216.179.128.0/17 is simply fradulent. >That is easy to address: submit a fraud request, and it will be reviewed >and corrected if it was done fraudulently. I would do that, but for the following four things: 1) ARIN is not the Internet Police and has no power to affect routing decisions of anybody. 2) Getting the info out here, on the NANOG list, allows people to make up their own minds and to ignore the relevant route announcements and/or cease peering if they are persuaded that 216.179.128.0/17 is likely a source of "undesirable" packets. 3) An investigation by ARIN of 216.179.128.0/17 could take weeks or perhaps even months. In contrast, packets, including bad ones, travel from one end of the planet to another in milliseconds. ARIN and its careful review processes are a sure and steady and reliable check on fradulent behavior over the longer term. But they will not do much to addres the bad packets that may be flowing out of 216.179.128.0/17 this week, or even next. 4) Filing a "fraud request" with ARIN is a serious step and one that could quite conceivably end up with the party filing such a formal report being on the business end of lawsuit, just for having filed such a report. Does ARIN indemnify the parties who file such reports against such claims, as ARIN is currently asking ARIN-region networks to do for ARIN if they want to avail themselves of the added security of RPKI? Regards, rfg From rfg at tristatelogic.com Tue Aug 13 19:35:22 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 13 Aug 2019 12:35:22 -0700 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: Message-ID: <48187.1565724922@segfault.tristatelogic.com> In message Ross Tajvar wrote: >Seems like submitting a fraud request to ARIN is more effective than >writing a novel and sending it to NANOG, and doesn't require the latter... As noted in my immediately prior posting, ARIN's careful adjudication of this or any other possible case of fraud could take weeks or even months. And even if, after careful and thoughtful deliberation, ARIN concludes that there is indeed something wrong here, ARIN has neither the power nor the authority to tell anyone how to configure their routers, and thus, any decision or conclusion made by ARIN, regarding this or any other case of possible fraud, will have no immediate effect on the flow of bad packets. Regards, rfg P.S. I do apologize for my verbosity. As the late Carl Sagan often said, extraordinary claims require extraordinary evidence. I made the extraordinary claim, on this public mailing list, that -something- fradulent had gone on with respect to the 216.179.128.0/17 block which has resulted in the WHOIS record for that bearing little or no relationship to actual reality. Having made the claim, I felt a duty to explain and to provide the evidence, not in 140 characters, but in detail. From rsk at gsp.org Tue Aug 13 19:42:25 2019 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 13 Aug 2019 15:42:25 -0400 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: References: <23645.1565381379@segfault.tristatelogic.com> Message-ID: <20190813194225.GA2368@gsp.org> On Mon, Aug 12, 2019 at 04:11:00PM -0400, Ross Tajvar wrote: > Seems like submitting a fraud request to ARIN is more effective than > writing a novel and sending it to NANOG, and doesn't require the latter... But if he didn't fully document his assertion(s), then he would be faced with a plethora of replies decrying the lack of substantiating evidence. Better to lay the case out in detail so that everyone can see the work and so that anyone who cares to can check it for themselves. And -- given Ron's long history of thorough documentation -- there are some of us who are willing to take his word for it and make operational decisions based on what he reports, independent of what ARIN decides to do or not do, or when it decides to do it. ---rsk From kmccormick at mdtc.net Tue Aug 13 21:55:06 2019 From: kmccormick at mdtc.net (Kevin McCormick) Date: Tue, 13 Aug 2019 21:55:06 +0000 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: Message-ID: The university I worked at used ITW Linx surge arrestors for years, never had any issues. https://www.itwlinx.com/products/surgegate-modular-communications-surge-protectors/cat6-75z The model above will work with POE+, careful of their cheaper CAT5-POE and CAT6-POE models as they are not designed for POE+ and did not work well with Cisco POE. Never had issues with the CAT6-75 model, worked perfect with Cisco equipment. We also used the CAT6-LAN models where POE was not needed, as they clamp to 16v vs the 75v of the CAT6-75 model. Thank you, Kevin McCormick From: NANOG On Behalf Of Javier J Sent: Tuesday, August 13, 2019 1:22 PM To: nanog at nanog.org Subject: Protecting 1Gb Ethernet From Lightning Strikes I'm working with a client site that has been hit twice, very close by lightening. I did lots of electrical work/upgrades/grounding but now I want to focus on protecting Ethernet connections between core switching/other devices that can't be migrated to fiber optic. I was looking for surge protection devices for Ethernet but have never shopped for anything like this before. Was wondering if anyone has deployed a solution? They don't have a large presence on site (I have been moving all of their core stuff to AWS) but they still have core networking / connectivity and PoE cameras / APs around the property. Since migrating their onsite servers/infra to the cloud, now their connectivity is even more important. This is a small site, maybe about 200 switch ports, but I would only need to protect maybe 12 core ones. but would be something I could use in the future with larger deployments. it's just a 1Gbe network BTW. Hope someone with more experience can help make hardware recommendations? Thanks in advance. - Javier -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpetach at netflight.com Tue Aug 13 22:10:05 2019 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 13 Aug 2019 13:10:05 -0900 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> <2d008a95-b5c9-4d9c-aed0-c040f5bca164@www.fastmail.com> <517fec42-1f8b-4797-a4d5-551d5437f404@www.fastmail.com> Message-ID: On Fri, Aug 9, 2019 at 4:31 PM Stephen Satchell wrote: > On 8/9/19 4:03 PM, Matthew Petach wrote: > > ...apparently Amazon has become a public utility > > now? > > > > I look forward with bemusement to the PUC > > tariff filings for AWS pricing. ^_^;; > > [...] > > And it wouldn't be the PUC, as Amazon is a company national in scope. > It would be something like the FCC. Public Utility Commissions are at > the local (usually county) or state level. > That was somewhat the point. Public utilities make some amount of sense when there's a local natural monopoly. With a global company, there's no such thing as a local natural monopoly in play; how would you assign oversight to a global entity? Which "public" would be the ones being protected? The city of Seattle, WA, where Amazon is headquartered? The State of Washington? The United States, at a federal level? What about the "public" that uses Amazon in all the other countries of the world? There's no way to make a global entity a regulated public utility; we don't have an organization that has that level of oversight across country boundaries, unless you start thinking about entities that can enforce *treaties* between countries. And I'm not sure I'd want our Ambassadors being the ones at the table deciding how best to regulate Amazon. :/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco at heavenlysanctuary.com Tue Aug 13 21:50:17 2019 From: marco at heavenlysanctuary.com (Marco Belmonte) Date: Tue, 13 Aug 2019 14:50:17 -0700 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: <48187.1565724922@segfault.tristatelogic.com> References: <48187.1565724922@segfault.tristatelogic.com> Message-ID: An HTML attachment was scrubbed... URL: From eric.kuhnke at gmail.com Tue Aug 13 22:54:53 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Tue, 13 Aug 2019 15:54:53 -0700 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: <48108.1565723844@segfault.tristatelogic.com> References: <48108.1565723844@segfault.tristatelogic.com> Message-ID: > 4) Filing a "fraud request" with ARIN is a serious step and one that could quite conceivably end up with the party filing such a formal report being on the business end of lawsuit, just for having filed such a report. What makes you think that the sort of persons who would hijack a /17 sized piece of space, for spam generation purposes, would sue you over some formal submission you might make to ARIN, but would not already have sued you over your already exhaustively detailed posts to the public NANOG list? On Tue, Aug 13, 2019 at 12:18 PM Ronald F. Guilmette wrote: > In message , > John Curran wrote: > > >On 9 Aug 2019, at 4:09 PM, Ronald F. Guilmette > wrote: > >> ... > >> Unfortunately, we cannot read too much into this change that was made > >> to the block's public-facing WHOIS record. Neither the new WHOIS info > >> nor even the old WHOIS info can be used to reliably infer who or what > >> is the legitimate registrant of the block at any point in time. This > >> is because ARIN, like all of the other Regional Internet Registries, > >> allows registrants to put essentially any bovine excrement they desire > >> into their public-facing WHOIS records. > > > >That is not the case – ARIN confirms the legal status of organizations > >receiving number resources. > > This is NOT the message that I got from our recent discussion of the giant > Micfo fraud on the ARIN Public Policy Mailing List. When I raised > questions about why various of the Micfo phoney baloney shell companies > has block with WHOIS records saying they were located in states that > they were obviously not located in, I believe that you said that once > a black has been allocated, by ARIN, to some (properly vetted) entity, > that after that point in time, the entity could -change- the relevant > WHOIS record to say any bloody thing it wanted, and that such -changes- > to ARIN WHOIS records are not vetted in any way. > > If I got the Wrong Impression from your prior statements, then by all > means, please do correct me. And then please do explain why several of > the Micfo phony shell companies did in fact have WHOIS records for ARIN- > issued IPv4 space that gave street addreses in states where none of these > phony shell companies were actually registered to do business. > > >> (And, it should be noted, the > >> man behind the recent large scale "Micfo" fraud apparently availed > >> himself of this exact opportunity far subterfuge, in spades.) > > > >As previously noted on this list, such was only possible because of the > >use of falsely notarized documents. > > I -do- understand that the fradulent documents that were originally > presented to you/ARIN provided information indicating that the phoney > Micfo shell companies -did- actually exist in -some- state (Delaware?), > and that ARIN -did- verify, to the best of its ability, that those > companies -did- exist, legally spekaing, in their originally declared > home state(s). But that fact is just skirting the real issue here, > which is the question of whether or not ARIN even looks at -changes_ > that a registrant may make to the WHOIS records (e.g. for IPv4 blocks) > -after- those blocks have been assigned. > > It appears from where I am sitting that ARIN dos not do so. And thus, > I stand by my comment that a registrant -can- in fact put any bloody > nonsense they want into their WHOIS records, at least as long as they > do it via -changes- and not in the original/initial WHOIS records. > > >> Regardless, the available records suggest that there are only two likely > >> possibilities in this case: > >> > >> {trimmed} > >> 1) 216.179.128.0/17 was transferred in violation of ARIN policy. > >> > >> 2) The current WHOIS for 216.179.128.0/17 is simply fradulent. > > >That is easy to address: submit a fraud request, and it will be reviewed > >and corrected if it was done fraudulently. > > I would do that, but for the following four things: > > 1) ARIN is not the Internet Police and has no power to affect routing > decisions of anybody. > > 2) Getting the info out here, on the NANOG list, allows people to make > up their own minds and to ignore the relevant route announcements > and/or cease peering if they are persuaded that 216.179.128.0/17 > is likely a source of "undesirable" packets. > > 3) An investigation by ARIN of 216.179.128.0/17 could take weeks or > perhaps even months. In contrast, packets, including bad ones, > travel from one end of the planet to another in milliseconds. > ARIN and its careful review processes are a sure and steady and > reliable check on fradulent behavior over the longer term. But > they will not do much to addres the bad packets that may be > flowing out of 216.179.128.0/17 this week, or even next. > > 4) Filing a "fraud request" with ARIN is a serious step and one that > could quite conceivably end up with the party filing such a formal > report being on the business end of lawsuit, just for having filed > such a report. > > Does ARIN indemnify the parties who file such reports against such > claims, as ARIN is currently asking ARIN-region networks to do for > ARIN if they want to avail themselves of the added security of > RPKI? > > > Regards, > rfg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at satchell.net Tue Aug 13 22:56:20 2019 From: list at satchell.net (Stephen Satchell) Date: Tue, 13 Aug 2019 15:56:20 -0700 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> <2d008a95-b5c9-4d9c-aed0-c040f5bca164@www.fastmail.com> <517fec42-1f8b-4797-a4d5-551d5437f404@www.fastmail.com> Message-ID: <7935f1f7-b2e2-8214-4cc7-0e53fe790f51@satchell.net> On 8/13/19 3:10 PM, Matthew Petach wrote: > With a global company, there's no such thing > as a local natural monopoly in play; how would > you assign oversight to a global entity? Which > "public" would be the ones being protected? > The city of Seattle, WA, where Amazon is > headquartered? The State of Washington? > The United States, at a federal level? What > about the "public" that uses Amazon in all > the other countries of the world? Consider how radio, television, and telephony grew and became regulated. (For a moment there, it felt like a discussion that I would have on the CyberTelecomm mailing list.) Each country would regulate the monopoly in the manner best suited for that country. Amazon would need to set up divisions in each country, or union of countries such as the EU. > There's no way to make a global entity a > regulated public utility; we don't have an > organization that has that level of oversight > across country boundaries, unless you start > thinking about entities that can enforce *treaties* > between countries. Actually, you'd be surprised to learn we already have infrastructure in place to do exactly that. The International Telecommunication Union is a fine example of how this could be done. Study up on it. From my experience in the telco and modem world, the individual countries have working parties for each element. The working parties develop Standards (the initial cap is intentional) within each country. The output from the working parties in each country send their recommendations to a government bureau -- in the United States, that would be a working party associated with the State Department. (For example, my work on in-band modem control went through TIA/EIA TR-29, which then was passed on to Study Group D, which went to the ITU.) > And I'm not sure I'd want our Ambassadors > being the ones at the table deciding how best > to regulate Amazon. :/ That's just the point. The regulation would *not* be done by ambassadors. The treaties, rule, regulations, and procedures are *already* in place to smooth the process through people that are not political appointees. Regulation of Amazon would probably be broken into parts: technical, policy, managment, auditing, perhaps more. Policy would originate in the USA with Congress, with help from the industry. Other parts would be parceled out to the people better (not necessarily the best) equipped to do the job. And that's my pair-o-pennies on the subject. Other people may have differing opinions. From matthew at corp.crocker.com Tue Aug 13 23:56:32 2019 From: matthew at corp.crocker.com (Matthew Crocker) Date: Tue, 13 Aug 2019 23:56:32 +0000 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: Message-ID: <88A2D380-4868-443E-8069-6EDA59F8226B@corp.crocker.com> Could you use a transceiver for the 1000Base-T? copper <-> fiber <-> copper that will create an ‘air gap’ on the data circuit. You still run the risk of a lightning strike entering through the transceiver power. You could filter that through a -48VDC power supply, rectifier/inverter pair. From: NANOG on behalf of Javier J Date: Tuesday, August 13, 2019 at 2:23 PM To: "nanog at nanog.org" Subject: Protecting 1Gb Ethernet From Lightning Strikes I'm working with a client site that has been hit twice, very close by lightening. I did lots of electrical work/upgrades/grounding but now I want to focus on protecting Ethernet connections between core switching/other devices that can't be migrated to fiber optic. I was looking for surge protection devices for Ethernet but have never shopped for anything like this before. Was wondering if anyone has deployed a solution? They don't have a large presence on site (I have been moving all of their core stuff to AWS) but they still have core networking / connectivity and PoE cameras / APs around the property. Since migrating their onsite servers/infra to the cloud, now their connectivity is even more important. This is a small site, maybe about 200 switch ports, but I would only need to protect maybe 12 core ones. but would be something I could use in the future with larger deployments. it's just a 1Gbe network BTW. Hope someone with more experience can help make hardware recommendations? Thanks in advance. - Javier -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Wed Aug 14 00:45:34 2019 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 13 Aug 2019 20:45:34 -0400 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: <88A2D380-4868-443E-8069-6EDA59F8226B@corp.crocker.com> References: <88A2D380-4868-443E-8069-6EDA59F8226B@corp.crocker.com> Message-ID: <11582335-D76D-478A-B076-FCFF7C5BD0A8@puck.nether.net> I would try to isolate it with something like the RBFTC11 or similar if you can. They’re great boxes, but as with all things lightning you usually can’t protect from everything. I’ve had a lightning hit cause some major issues before at a tower site. You do what you can and keep suitable spares at the ready. You never know why there will be a failure. - Jared > On Aug 13, 2019, at 7:56 PM, Matthew Crocker wrote: > > > Could you use a transceiver for the 1000Base-T? copper <-> fiber <-> copper that will create an ‘air gap’ on the data circuit. You still run the risk of a lightning strike entering through the transceiver power. You could filter that through a -48VDC power supply, rectifier/inverter pair. > > > From: NANOG on behalf of Javier J > Date: Tuesday, August 13, 2019 at 2:23 PM > To: "nanog at nanog.org" > Subject: Protecting 1Gb Ethernet From Lightning Strikes > > I'm working with a client site that has been hit twice, very close by lightening. > > I did lots of electrical work/upgrades/grounding but now I want to focus on protecting Ethernet connections between core switching/other devices that can't be migrated to fiber optic. > > I was looking for surge protection devices for Ethernet but have never shopped for anything like this before. Was wondering if anyone has deployed a solution? > They don't have a large presence on site (I have been moving all of their core stuff to AWS) but they still have core networking / connectivity and PoE cameras / APs around the property. > Since migrating their onsite servers/infra to the cloud, now their connectivity is even more important. > > This is a small site, maybe about 200 switch ports, but I would only need to protect maybe 12 core ones. but would be something I could use in the future with larger deployments. > it's just a 1Gbe network BTW. > > Hope someone with more experience can help make hardware recommendations? > > Thanks in advance. > > - Javier From rfg at tristatelogic.com Wed Aug 14 01:28:44 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 13 Aug 2019 18:28:44 -0700 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: Message-ID: <49474.1565746124@segfault.tristatelogic.com> In message , Eric Kuhnke wrote: rfg>> 4) Filing a "fraud request" with ARIN is a serious step and one that rfg> could quite conceivably end up with the party filing such a formal rfg> report being on the business end of lawsuit, just for having filed rfg> such a report. rfg> >What makes you think that the sort of persons who would hijack a /17 sized >piece of space, for spam generation purposes, would sue you over some >formal submission you might make to ARIN, but would not already have sued >you over your already exhaustively detailed posts to the public NANOG list? Let me see if I understand this. You don't have any argument with the other three reasons I gave for sending my alert to the NANOG list, but you -would- like to quible with reason #4. Have I understood you clearly? Assuming so, let me answer your question with a question (or two). Is my fear of the potential for lawsuits actually LESS reasonable than ARIN's use of the same vague and non-specific bogeyman to thwart and impede, on a global scale, the more widespread adoption of RPKI... adoption which would, if it ever became universal, put an end to most or all of these nefarious and malevolent IP block hanky panky games? The last time I looked, RPKI adoption was sitting at around a grand total of 15% worldwide. Ah yes, here it is... https://rpki-monitor.antd.nist.gov/ I've asked many people and many companies why adoption remains so low, and why their own companies aren't doing RPKI. I've gotten the usual assortment of utterly lame excuses, but the one that I have had the hardest time trying to counter is the one where a network engineer says to me "Well, ya know, we were GOING to do that, but then ARIN... unlike the other four regional authorities... demanded that we sign some silly thing indemnifying them in case of.... something. We're not even sure what ``something'' actually is in this case, other than some demented lawsuit from some deranged ``lone wolf'' individual, but since ARIN demanded that we sign it, the thing had to go to -our- lawyers, and they took one look at it and said, in effect, ``F that! We are NOT going to accept any new potential liability if we don't have to'', so that was the end of that." As I have often said, if we all only did things that had been pre-cleared as being ``utterly safe'' by our respective lawyers, then none of us would ever even get out of bed in the morning. Regadless of whether ARIN was in any way indemnified against such an event, the Micfo guy elected to name ARIN in a lawsuit. This is a matter of public record. It's ludicrous and laughable, obviously, but he apparently sued ARIN when they woudn't just roll over and allow him to continue to play his ridiculous little fraud games. Like I say, in this country, at least (USA), you run the risk of getting sued if you even so much as get out a bed in the morning. BUT SO BLOODY WHAT? Neither we as individuals nor ARIN as an organization should cower in fear in our caves because of a bogeyman that may never come to pass, or that may be totally inconsequential even if it does, as in the case of Mr. Micfo's joke of a lawsuit. So I put it to everyone here... Are ARIN policies and its over-hyped fear of the vague bogeyman of lawsuits materially impeding the adoption of RPKI, and if so, what should be done about this? In the meantime, I decline to accept criticism of -my- perhaps misplaced fears of lawsuits. Mine have essentially no real world consequences. ARIN's, on the other hand, appear to be keeping some finite non-zero fraction of 85% of the world's route announcements unchecked, at least for any meaningful sense of the word "checked". Regards, rfg From jcurran at arin.net Wed Aug 14 02:42:09 2019 From: jcurran at arin.net (John Curran) Date: Wed, 14 Aug 2019 02:42:09 +0000 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: <49474.1565746124@segfault.tristatelogic.com> References: <49474.1565746124@segfault.tristatelogic.com> Message-ID: <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette > wrote: ... The last time I looked, RPKI adoption was sitting at around a grand total of 15% worldwide. Ah yes, here it is... https://rpki-monitor.antd.nist.gov/ I've asked many people and many companies why adoption remains so low, and why their own companies aren't doing RPKI. I've gotten the usual assortment of utterly lame excuses, but the one that I have had the hardest time trying to counter is the one where a network engineer says to me "Well, ya know, we were GOING to do that, but then ARIN... unlike the other four regional authorities... demanded that we sign some silly thing indemnifying them in case of.... something. Interestingly enough, those same indemnification clauses are in the registration services agreement that they already signed but apparently they were not an issue at all when requesting IP address space or receiving a transfer. You might want want to ask them why they are now a problem when they weren’t before (Also worth noting that many of these ISP's own contracts with their customers have rather similar indemnification clauses.) Even so, we at ARIN are in the midst of a Board-directed review of the RPKI legal framework to see if any improvements can be made – I will provide further updates once it is completed. Thanks! /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Aug 14 03:03:40 2019 From: bill at herrin.us (William Herrin) Date: Tue, 13 Aug 2019 20:03:40 -0700 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> Message-ID: On Tue, Aug 13, 2019 at 7:42 PM John Curran wrote: > On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette > wrote: > > The last time I looked, RPKI adoption was sitting at around a grand total > of 15% worldwide. Ah yes, here it is... > > https://rpki-monitor.antd.nist.gov/ > > I've asked many people and many companies why adoption remains so low, and > why their own companies aren't doing RPKI. I've gotten the usual > assortment > of utterly lame excuses, but the one that I have had the hardest time > trying to counter is the one where a network engineer says to me "Well, > ya know, we were GOING to do that, but then ARIN... unlike the other four > regional authorities... demanded that we sign some silly thing indemnifying > them in case of.... something. > > > Interestingly enough, those same indemnification clauses are in the > registration services agreement that they already signed but apparently > they were not an issue at all when requesting IP address space or receiving > a transfer. > I signed no legal agreement either to register my legacy addresses or to do a whois lookup to check someone else's addresses. Just sayin'. -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Aug 14 03:24:56 2019 From: jcurran at arin.net (John Curran) Date: Wed, 14 Aug 2019 03:24:56 +0000 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> Message-ID: <5B763138-3541-4B0D-BFD1-449852421C6E@arin.net> On 13 Aug 2019, at 11:03 PM, William Herrin > wrote: On Tue, Aug 13, 2019 at 7:42 PM John Curran > wrote: On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette > wrote: The last time I looked, RPKI adoption was sitting at around a grand total of 15% worldwide. Ah yes, here it is... https://rpki-monitor.antd.nist.gov/ I've asked many people and many companies why adoption remains so low, and why their own companies aren't doing RPKI. I've gotten the usual assortment of utterly lame excuses, but the one that I have had the hardest time trying to counter is the one where a network engineer says to me "Well, ya know, we were GOING to do that, but then ARIN... unlike the other four regional authorities... demanded that we sign some silly thing indemnifying them in case of.... something. Interestingly enough, those same indemnification clauses are in the registration services agreement that they already signed but apparently they were not an issue at all when requesting IP address space or receiving a transfer. I signed no legal agreement either to register my legacy addresses or to do a whois lookup to check someone else's addresses. Just sayin’. Bill - When you did that Whois look up at the ARIN website, you did agree to terms of use for the Whois service which contains indemnification provisions and are legally enforceable. If you instead used a command line interface (e.g. "whois -h whois.arin.net …”), then you received output from ARIN’s Whois server along with notice of the applicable terms of service… I would observe that continued use at that point has been held to indicate agreement on your part [ref: Register.com, Inc. v. Verio, Inc., 356 F.3d 393 (2d Cir. 2004)] Thanks, /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at efes.iucc.ac.il Wed Aug 14 04:47:30 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 14 Aug 2019 07:47:30 +0300 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: <48108.1565723844@segfault.tristatelogic.com> References: <48108.1565723844@segfault.tristatelogic.com> Message-ID: <4fcb73bf-224f-e011-f310-522193c86667@efes.iucc.ac.il> On 13/08/2019 22:17, Ronald F. Guilmette wrote: Just as an observer to your long resource theft postings: - Do you attempt to contact directly the organization or person who have had their resource taken over? - Do they care or are they apathetic? - If the resource owner is no where to be found, why should we as a community care?  Report it on some webpage and call it "Internet Resources stolen", document every incident as you do via email, send a copy to the appropriate RIR and upstream ISP allowing the hijack in question to show that you did the appropriate effort and we can then move on. Regards, Hank From hank at efes.iucc.ac.il Wed Aug 14 04:51:15 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 14 Aug 2019 07:51:15 +0300 Subject: RPKI adoption In-Reply-To: <5B763138-3541-4B0D-BFD1-449852421C6E@arin.net> References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> <5B763138-3541-4B0D-BFD1-449852421C6E@arin.net> Message-ID: <65e7d2ef-8fb3-62db-b2ce-da3167659ee5@efes.iucc.ac.il> On 14/08/2019 06:24, John Curran wrote: > > When you did that Whois look up at the ARIN website, you did agree to > terms of use for the Whois service which contains indemnification > provisions and are legally enforceable. > > > If you instead used a command line interface (e.g. "whois -h > whois.arin.net …”), then you received output > from ARIN’s Whois server along with notice of the applicable terms of > service…  I would observe that continued use at that point has been > held to indicate agreement on your part [ref: Register.com > , Inc. v. Verio, Inc., 356 F.3d 393 (2d Cir. 2004)] > > Thanks, > /John > > John Curran > President and CEO > American Registry for Internet Numbers > Just like to add kudos to John for being open and responsive on this list and other lists to numerous issues and questions in regards to ARIN.  Not many CEOs are willing or able to respond as you do. Thanks for your time and effort, -Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Aug 14 05:01:51 2019 From: bill at herrin.us (William Herrin) Date: Tue, 13 Aug 2019 22:01:51 -0700 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: <5B763138-3541-4B0D-BFD1-449852421C6E@arin.net> References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> <5B763138-3541-4B0D-BFD1-449852421C6E@arin.net> Message-ID: On Tue, Aug 13, 2019 at 8:25 PM John Curran wrote: > On 13 Aug 2019, at 11:03 PM, William Herrin wrote: > I signed no legal agreement either to register my legacy addresses or to do a whois lookup to check someone else's addresses. Just sayin’. > > If you instead used a command line interface (e.g. "whois -h whois.arin.net …”), > then you received output from ARIN’s Whois server along with notice of the applicable terms of service… Hi John, As I no longer live within or act from within one of the 2 states to have passed UCITA, you'll find that notice difficult to enforce. > I would observe that continued use at that point has been held > to indicate agreement on your part [ref: Register.com, Inc. v. Verio, Inc., 356 F.3d 393 (2d Cir. 2004)] In which Verio admitted to the court that they knew they were abusing Register's computers but figured Register's contract with ICANN gave them the right. The court would have reached the same decision regardless of Register's notice: You're abusing computers that aren't yours. Stop it. Specht v. Netscape Communications Corp, on the other hand, found that, "plaintiffs neither received reasonable notice of the existence of the license terms nor manifested unambiguous assent" to the contract Netscape offered for the use of their software at download-time, including assent to settle disputes through arbitration. I'll take any bet you care to offer that the latter precedent applies to casual consumer use of ARIN's whois. I won't take any such bet when it comes to the legal safety of redistributing ARIN's RPKI Trust Anchor Locator in my software. And neither, apparently, do many of the folks who would have to redistribute that TAL for ARIN's RPKI to be useful, as was discussed here last September: https://mailman.nanog.org/pipermail/nanog/2018-September/097161.html 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 Wed Aug 14 05:02:55 2019 From: bill at herrin.us (William Herrin) Date: Tue, 13 Aug 2019 22:02:55 -0700 Subject: RPKI adoption In-Reply-To: <65e7d2ef-8fb3-62db-b2ce-da3167659ee5@efes.iucc.ac.il> References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> <5B763138-3541-4B0D-BFD1-449852421C6E@arin.net> <65e7d2ef-8fb3-62db-b2ce-da3167659ee5@efes.iucc.ac.il> Message-ID: On Tue, Aug 13, 2019 at 9:51 PM Hank Nussbacher wrote: > Just like to add kudos to John for being open and responsive on this list > and other lists to numerous issues and questions in regards to ARIN. Not > many CEOs are willing or able to respond as you do. > > Thanks for your time and effort, > I'll second that despite my criticism. Regards, Bill Herrin -- William Herrin bill at herrin.us https://bill.herrin.us/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Wed Aug 14 05:21:04 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 13 Aug 2019 22:21:04 -0700 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> Message-ID: <50284.1565760064@segfault.tristatelogic.com> In message <06570278-E1AD-4BB0-A9FC-11A77BED76E1 at arin.net>, John Curran wrote: >Even so, we at ARIN are in the midst of a Board-directed review of the RPKI >legal framework to see if any improvements can be made vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf> – I will >provide further updates once it is completed. This is an excellent presentation John, and I'm real glad to see that you have done such a nice job on it and touched on all of the important points. In particular, I'm glad that you clarified that if everyone is just doing what they ought to be doing, i.e. following best practices, then even if RPKI central and all of its sister satellites should all be simultaneously hit by metorites, then in theory at least, nobody should be any worse off than they already are today. And yes, I can't argue and won't argue that some folks aren't going to be bozos and screw up their RPKI deployment, and then some of them -may- possibly want to blame ARIN for -their- screw ups, but I continue to have trouble envisioning how this would ever traslate into a lawsuit that wouldn't simply be laughed out of court in about five seconds if handled properly. Some arguably proximate historical analogs might be relevant here. In the past, there have occasionally been problems when one or more of the root name servers have been DDoSd or have otherwise had issues. I don't recall anybody lining up to sue ICANN in those instances. Spamhaus and other public anti-spam services publish their stuff to all comers, without demanding indemnification. Yes, they have been sued from time to time, but none of that has ever resulted in any meaningful damages, and if the company itself had just been more consistant in obtaining sound legal advice, none of those events would even have been all that bothersome. So, what makes ARIN so special that it can't do what these others are doing and just simply publish some information? ARIN is in the State of Virginia the last time I checked, and I do believe that the First Amendment still applies in the State of Virginia, and indeed in all 50 states. I mean it isn't as if ARIN is going to go around yelling "Fire!" in a crowded theater for God's sake! So, you just slap a label on the whole bloody RPKI thing that says "Use at your own risk" and that ought to do it, I think. I understand that Steve Ryan may not see it that way, but it's his job not to see it that way. In practice, there is no need for -both- belt -and- suspenders. Regards, rfg P.S. Proactive failure testing (slide #15) is an excellent idea. You could and probably should fail the whole thing deliberately for 24 hours once a year, just as a way of shaking the trees to see what idiots fall out. It would be like DNS Flag Day, on steroids. From mpetach at netflight.com Wed Aug 14 06:26:15 2019 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 13 Aug 2019 21:26:15 -0900 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> Message-ID: On Tue, Aug 13, 2019 at 5:44 PM John Curran wrote: > On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette > wrote: > > ... > The last time I looked, RPKI adoption was sitting at around a grand total > of 15% worldwide. Ah yes, here it is... > > https://rpki-monitor.antd.nist.gov/ > > I've asked many people and many companies why adoption remains so low, and > why their own companies aren't doing RPKI. I've gotten the usual > assortment > of utterly lame excuses, but the one that I have had the hardest time > trying to counter is the one where a network engineer says to me "Well, > ya know, we were GOING to do that, but then ARIN... unlike the other four > regional authorities... demanded that we sign some silly thing indemnifying > them in case of.... something. > > > Interestingly enough, those same indemnification clauses are in the > registration services agreement that they already signed but apparently > they were not an issue at all when requesting IP address space or receiving > a transfer. > You might want want to ask them why they are now a problem when they > weren’t before (Also worth noting that many of these ISP's own contracts > with their customers have rather similar indemnification clauses.) > Hi John, There are things companies will sign when their backs are up against the wall that they will balk at signing when it is for an optional geek-ish extra. IP addresses are the lifeblood of the tech industry. If you don't have an IP address, you don't exist on the Internet. (Apologies to those of us who still have modems configured to call and retrieve mail addressed with UUCP bang paths). So, companies will grudgingly and with much hand-wringing sign the RSA necessary to get IP space. Without, they die. Rather like oxygen; if we had to sign a license agreement in order to receive air to breathe, you'd find most people would sign pretty horrific terms of service agreements. Slip those same terms in front of someone as a requirement for them to buy beer, and you'll likely discover a whole lot of people are just fine drinking something else instead. So too with the RSA terms versus the RPKI terms. As companies, we can't survive without IP addresses. We'll sign just about anything to stay alive. RPKI is a geek toy. It's not at all required for a business to stay alive on the Internet, so companies feel much safer in saying "no way will we sign that!". Now, at the risk of bringing down the ire of the community on my head...ARIN could consider tying the elements together, at least for ARIN members. Add the RPKI terms into the RSA document. You need IP number resources, congratulations, once you sign the RSA, you're covered for RPKI purposes as well. That doesn't solve the issue for out-of-region folks who don't have an RSA with ARIN; but that's no worse than you are today; and by bundling the RPKI terms in with the rest of the RSA, you at least get everyone in the ARIN region that wants^Wneeds to maintain their IP number resources in order to stay in business on the Internet covered in terms of being able to use the RPKI data. If you've got them by the short and curlies already, might as well bundle everything in while they've got the pen in their hand. ^_^; Even so, we at ARIN are in the midst of a Board-directed review of the RPKI > legal framework to see if any improvements can be made < > https://www.arin.net/vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf> > – I will provide further updates once it is completed. > Best of luck! I know we'll all be watching carefully to see how it goes. :) Matt > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adampf at gmail.com Wed Aug 14 10:25:22 2019 From: adampf at gmail.com (Andrew Dampf) Date: Wed, 14 Aug 2019 06:25:22 -0400 Subject: provider email maintenance standard In-Reply-To: References: <75806ded-41aa-182b-d487-59b74b24059e@rodecker.nl> Message-ID: I ended up writing a flask app that parses provider maintenance emails and posts slack notifications at the start and end of the window. You can also extend it to take actions like drain/undrain traffic during windows. Right now the five supported providers are NTT, PacketFabric, EUNetworks, GTT, and Zayo. The first three follow the MAINTNOTE standard. The last two were done via bs4 and good old regex. Upcoming parsers are in the works for Reliance, CenturyLink, and Tata. I hope others find this useful and deploy it for their networks. Let me know what you think and if you'd like to contribute: https://github.com/wasabi222/janitor Here are some screencaps: https://imgur.com/a/tMTlMwH If you know of more providers that follow the MAINTNOTE standard, please let me know so I can add them to the parser. Thanks! On Tue, Jun 18, 2019 at 12:38 PM Erik Sundberg wrote: > Back at NANOG in Chicago 2016 someone was working on a standards for > Maintenance notifications with calendar invites attached. Not sure what > happened with it. > > I think this was it. > https://archive.nanog.org/meetings/abstract?id=2853 > > > > Erik Sundberg > Sr. Network Engineer > > office 773.661.5532 > mobile 708.710.7419 > noc 866.892.0915 > > esundberg at nitelusa.com > > 888.450.2100 > 350 N Orleans St. #1300N > Chicago, IL 60654 > nitelusa.com > > > Smarter technology made simple > > > -----Original Message----- > From: NANOG On Behalf Of Jay Hanke > Sent: Tuesday, June 18, 2019 8:41 AM > To: Job Snijders > Cc: North American Network Operators' Group > Subject: Re: provider email maintenance standard > > > https://github.com/jda/maintnote-std/blob/master/standard.md > > > > NTT / AS 2914’s NOC follows this process to keep customers and partners > informed about maintenances. > > Is there commercial or open source software that already has this > implemented? > > ________________________________ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files > or previous e-mail messages attached to it may contain confidential > information that is legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached to > this transmission is STRICTLY PROHIBITED. If you have received this > transmission in error please notify the sender immediately by replying to > this e-mail. You must destroy the original transmission and its attachments > without reading or saving in any manner. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Aug 14 10:33:48 2019 From: jcurran at arin.net (John Curran) Date: Wed, 14 Aug 2019 10:33:48 +0000 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> <5B763138-3541-4B0D-BFD1-449852421C6E@arin.net> Message-ID: <153113C3-2B3A-4ADE-BD0A-272B3C9739ED@arin.net> On 14 Aug 2019, at 1:01 AM, William Herrin wrote: > ... > > I would observe that continued use at that point has been held > > to indicate agreement on your part [ref: Register.com, Inc. v. Verio, Inc., 356 F.3d 393 (2d Cir. 2004)] > > In which Verio admitted to the court that they knew they were abusing Register's computers but figured Register's contract with ICANN gave them the right. The court would have reached the same decision regardless of Register's notice: You're abusing computers that aren't yours. Stop it. BIll - The particular finding from Register v. Verio that is relevant was that a user made aware of applicable terms with each query (even at the end) is sufficient for contractual binding after continued use. > Specht v. Netscape Communications Corp, on the other hand, found that, "plaintiffs neither received reasonable notice of the existence of the license terms nor manifested unambiguous assent" to the contract Netscape offered for the use of their software at download-time, including assent to settle disputes through arbitration. Register v. Verio was after Specht v Netscape, and distinguished the situation where the user received terms at the end of each response from those cases where a user couldn’t reasonably determine that there were any applicable terms and conditions. > I'll take any bet you care to offer that the latter precedent applies to casual consumer use of ARIN's whois. That bet is available to you at any time by violating the terms the ARIN’s Whois service, so the question to ask yourself is: "do you feel lucky?” Thanks, /John John Curran President and CEO American Registry for Internet Numbers From jcurran at arin.net Wed Aug 14 10:36:44 2019 From: jcurran at arin.net (John Curran) Date: Wed, 14 Aug 2019 10:36:44 +0000 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> Message-ID: <7242DF31-1287-4A79-ABC8-80703BF03559@arin.net> On 14 Aug 2019, at 2:26 AM, Matthew Petach wrote: > ... > Now, at the risk of bringing down the ire > of the community on my head...ARIN could > consider tying the elements together, at > least for ARIN members. Add the RPKI terms > into the RSA document. You need IP number > resources, congratulations, once you sign the > RSA, you're covered for RPKI purposes as well. Matthew - Yes indeed - this is one of several potential improvements that we’re also investigating. Thanks! /John John Curran President and CEO American Registry for Internet Numbers From jcurran at arin.net Wed Aug 14 10:44:35 2019 From: jcurran at arin.net (John Curran) Date: Wed, 14 Aug 2019 10:44:35 +0000 Subject: RPKI adoption In-Reply-To: <65e7d2ef-8fb3-62db-b2ce-da3167659ee5@efes.iucc.ac.il> References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> <5B763138-3541-4B0D-BFD1-449852421C6E@arin.net> <65e7d2ef-8fb3-62db-b2ce-da3167659ee5@efes.iucc.ac.il> Message-ID: <42AC8829-72D5-452A-8E3D-573BF5C04BC3@arin.net> On 14 Aug 2019, at 12:51 AM, Hank Nussbacher wrote: > … > Just like to add kudos to John for being open and responsive on this list and other lists to numerous issues and questions in regards to ARIN. Not many CEOs are willing or able to respond as you do. Hank - Thanks! – as I work for you (i.e. this collective community), I see it as a reasonable obligation to be reachable/answerable regarding how your registry is being run. /John John Curran President and CEO American Registry for Internet Numbers p.s. As a reminder, those interested in more prominent/direct role in oversight of ARIN should consider running for the Board of Trustees… From jcurran at arin.net Wed Aug 14 11:01:11 2019 From: jcurran at arin.net (John Curran) Date: Wed, 14 Aug 2019 11:01:11 +0000 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: <50284.1565760064@segfault.tristatelogic.com> References: <50284.1565760064@segfault.tristatelogic.com> Message-ID: On 14 Aug 2019, at 1:21 AM, Ronald F. Guilmette > wrote: In message <06570278-E1AD-4BB0-A9FC-11A77BED76E1 at arin.net>, John Curran > wrote: Even so, we at ARIN are in the midst of a Board-directed review of the RPKI legal framework to see if any improvements can be made – I will provide further updates once it is completed. This is an excellent presentation John, and I'm real glad to see that you have done such a nice job on it and touched on all of the important points. In particular, I'm glad that you clarified that if everyone is just doing what they ought to be doing, i.e. following best practices, then even if RPKI central and all of its sister satellites should all be simultaneously hit by metorites, then in theory at least, nobody should be any worse off than they already are today. And yes, I can't argue and won't argue that some folks aren't going to be bozos and screw up their RPKI deployment, and then some of them -may- possibly want to blame ARIN for -their- screw ups, but I continue to have trouble envisioning how this would ever traslate into a lawsuit that wouldn't simply be laughed out of court in about five seconds if handled properly. Alas, it’s not those who fail to properly configure RPKI that are likely to be litigating, but rather their impacted customers and those customers' business partners who all were unable to communicate due to no fault of their own. Such a matter will not be thrown out of court, but will be the start of a long and very expensive process involving claims, discovery, experts, etc. (a recent legal matter that was promptly resolved in ARIN’s favor pre-litigation still resulted in more than 1/3 million USD in costs...) Absent a specific reason for dismissal, it is only in actual trial that the preponderance of evidence gets considered – and note that in such a dispute, we’d end up with a jury of regular folks hearing fairly technical arguments about certificate validation, covering ROA’s, caching, etc. In other words, even if handled perfectly, your five second estimate is likely off by a year or more (and hence the reason for indemnification - it provides a clear basis for ARIN’s exit from the matter, as it makes plain that the liability resulting from use of the RPKI repository lies with the ISP.) Thanks, /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From mansaxel at besserwisser.org Wed Aug 14 11:02:25 2019 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 14 Aug 2019 13:02:25 +0200 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: Message-ID: <20190814110225.GD23469@besserwisser.org> Subject: Protecting 1Gb Ethernet From Lightning Strikes Date: Tue, Aug 13, 2019 at 02:22:12PM -0400 Quoting Javier J (javier at advancedmachines.us): > I'm working with a client site that has been hit twice, very close by > lightening. > > I did lots of electrical work/upgrades/grounding but now I want to focus on > protecting Ethernet connections between core switching/other devices that > can't be migrated to fiber optic. If lightning comes so close that it will break things inside the same facility because they are connected by structured cabling, two things typically have failed; * The building as such is not adequately protected. * There exist too large potential differences within the electrical system inside the building. For #1, telecoms regulations on site grounding and protection give good, albeit expensive advice. The most important part is that all cabling enter the facility with its screens at common potential. The reason is that most blown equipment comes from in-ground potential difference between different cables. (I've poured shattered IC's out of a poor ADSL router after such a strike. ) If that potential difference is cancelled upon entry in the facility by bonding all grounds the risk is minimised. For #2, it is mostly solved by fixing #1, but it is proper to fix it by mesh-connecting grounds on all equipment together. If there is a 10mm^2 (around AWG7) bonding conductor parallel to the 0,14mm^2 (AWG25) drain wire in the foil screen, which way will the current take? Do note that star grounds are popular, but they're impossible to maintain and typically don't work at high frequiencies, which will lessen their efficiency against fast-rising transients. Mesh grounds are better at conducting high frequencies and are easier to maintain. Having several power utility feeds into same facility will of course exacerbate the problem, which is one of the reasons it is illegal in Sweden. If you need to cross between two buildings, copper should be rejected. Fiber is so much better. And pays for itself immediately upon first strike survived. /Måns, has 6 pairs 9/125 between garage and house at home. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 I feel partially hydrogenated! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From job at ntt.net Wed Aug 14 11:24:18 2019 From: job at ntt.net (Job Snijders) Date: Wed, 14 Aug 2019 13:24:18 +0200 Subject: RPKI adoption In-Reply-To: <7242DF31-1287-4A79-ABC8-80703BF03559@arin.net> References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> <7242DF31-1287-4A79-ABC8-80703BF03559@arin.net> Message-ID: <20190814112418.GU4901@hanna.meerval.net> Dear all, On Wed, Aug 14, 2019 at 10:36:44AM +0000, John Curran wrote: > On 14 Aug 2019, at 2:26 AM, Matthew Petach wrote: > > ... > > Now, at the risk of bringing down the ire of the community on my > > head...ARIN could consider tying the elements together, at least for > > ARIN members. Add the RPKI terms into the RSA document. You need > > IP number resources, congratulations, once you sign the RSA, you're > > covered for RPKI purposes as well. > > Matthew - > > Yes indeed - this is one of several potential improvements that we’re also investigating. I've attempted to produce a humorous world map chart to help clarify there is a degree of asymmetry our community may need to consider: http://instituut.net/~job/screenshots/e079d90a-3047-4034-8e7c-9caf6e387f1a.png The ARIN members (mostly located in the red area) would like all not-ARIN-members (located in the blue area, the rest of the world) to use and honor their ROAs published through ARIN's RPKI service. If not for the purpose of facilitating BGP Origin Validation on as many as possible of Internet's routers to protect one's IP resources, why else would anyone publish RPKI ROAs through their RIR? In other words: ARIN members want something (something very reasonable!) from "the rest of the world", but in order to accomplish that 'something', unfortunately "the rest" needs to agree to the ARIN RPA. This has proven to be somewhat of an adoption barrier. It would be fantastic when "the rest" are not required to do any such thing and the ARIN RPKI TAL can be distributed without restrictions or limitations. I would love to see any solution that removes all potential friction for "the rest of the world", even if that shifts some additional burden to ARIN members themselves; because it's ARIN members that want something from the world, less so the other way around. On Wed, Aug 14, 2019 at 4:42 AM John Curran wrote: > Interestingly enough, those same indemnification clauses are in the > registration services agreement that they already signed but > apparently they were not an issue at all when requesting IP address > space or receiving a transfer. Your observation (if correct) indeed is very interesting, and perhaps demonstrates that RPKI business is something between ARIN and ARIN's members, and less so between ARIN and all other potential relaying parties on this planet. Or phrased differently: perhaps only ARIN members should be the ones incurring the cost and burden of reviewing and accepting ARIN's agreements. I'd like to express my appreciation to ARIN's staff & ARIN's Board of Trustees for dedicating their time and resources to research how to improve in this context. Kind regards, Job ps. Ofcourse this map is an oversimplification of the situation, apologies for any inaccuracies. From bjorn at mork.no Wed Aug 14 12:01:01 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Wed, 14 Aug 2019 14:01:01 +0200 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: <20190814110225.GD23469@besserwisser.org> (=?utf-8?Q?=22M?= =?utf-8?Q?=C3=A5ns?= Nilsson"'s message of "Wed, 14 Aug 2019 13:02:25 +0200") References: <20190814110225.GD23469@besserwisser.org> Message-ID: <87ef1oez2a.fsf@miraculix.mork.no> Måns Nilsson writes: > /Måns, has 6 pairs 9/125 between garage and house at home. Now you made me worry that my single OM4 pair to the garden shed might be insufficient ;-) Bjørn From mansaxel at besserwisser.org Wed Aug 14 12:10:13 2019 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 14 Aug 2019 14:10:13 +0200 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: <87ef1oez2a.fsf@miraculix.mork.no> References: <20190814110225.GD23469@besserwisser.org> <87ef1oez2a.fsf@miraculix.mork.no> Message-ID: <20190814121013.GF23469@besserwisser.org> Subject: Re: Protecting 1Gb Ethernet From Lightning Strikes Date: Wed, Aug 14, 2019 at 02:01:01PM +0200 Quoting Bjørn Mork (bjorn at mork.no): > Måns Nilsson writes: > > > /Måns, has 6 pairs 9/125 between garage and house at home. > > Now you made me worry that my single OM4 pair to the garden shed might > be insufficient ;-) I have but one comment: "Friends don't let friends run multimode." -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Yow! I'm having a quadrophonic sensation of two winos alone in a steel mill! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From job at ntt.net Wed Aug 14 14:54:45 2019 From: job at ntt.net (Job Snijders) Date: Wed, 14 Aug 2019 16:54:45 +0200 Subject: =?UTF-8?Q?new_BGP_hijack_=26_visibility_tool_=E2=80=9CBGPalerter=E2=80=9D?= Message-ID: Dear NANOG, Recently NTT investigated how to best monitor the visibility of our own and our subsidiaries’ IP resources in the BGP Default-Free Zone. We were specifically looking how to get near real-time alerts funneled into an actionable pipeline for our NOC & Operations department when BGP hijacks happen. Previously we relied on a commercial “BGP Monitoring as a Service” offering, but with the advent of RIPE NCC’s “RIS Live” streaming API [1] we saw greater potential for a self-hosted approach designed specifically for custom integrations with various business processes. We decided to write our own tool “BGPalerter” and share the source code with the Internet community. BGPalerter allows operators to specify in great detail how to distribute meaningful information from the firehose from various BGP data sources (we call them “connectors”), through data processors (called “monitors”), finally outputted through “reports” into whatever mechanism is appropriate (Slack, IRC, email, or a call to your ticketing system’s API). The source code is available on Github, under a liberal open source license to foster community collaboration: https://github.com/nttgin/BGPalerter If you wish to contribute to the project, please use Github’s “issues” or “pull request” features. Any help is welcome! We’d love suggestions for new features, updates to the documentation, help with setting up a CI regression testing pipeline, or packaging for common platforms. Kind regards, Job & Massimo NTT Ltd [1]: https://ris-live.ripe.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Wed Aug 14 15:15:40 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 14 Aug 2019 11:15:40 -0400 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> Message-ID: <248778.1565795740@turing-police> On Wed, 14 Aug 2019 02:42:09 -0000, John Curran said: > You might want want to ask them why they are now a problem when they weren���t > before (Also worth noting that many of these ISP's own contracts with their > customers have rather similar indemnification clauses.) Actually, it's probably ARIN that should be doing the asking, and seeing if they can change the wording and/or rephrase the issue to allay concerns. It sounds to me like ARIN's *intent* was "if you get sued by your customers because you screw the pooch on deployment, it's your screw-up to clean up and not our problem". Or at least I *hope* that was the intent (see next paragraph) But I suspect a lot of companies are reading it as: "If a spammer sues you for using a block list that prevents them from spamming your customers, you can't end up owing money to the block list maintainers. But if you rely on the ARIN TAL, and get sued by an address hijacker, you could end up owing money to ARIN". (Having said that, John, it takes a special sort of CEO to stand out and be seen in situations like this, and the world could probably use more CEO's like that...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From jcurran at arin.net Wed Aug 14 16:07:49 2019 From: jcurran at arin.net (John Curran) Date: Wed, 14 Aug 2019 16:07:49 +0000 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: <248778.1565795740@turing-police> References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> <248778.1565795740@turing-police> Message-ID: <21C5B8F5-61E5-4309-BF4B-D8AC0C14397E@arin.net> On 14 Aug 2019, at 11:15 AM, Valdis Klētnieks wrote: > > On Wed, 14 Aug 2019 02:42:09 -0000, John Curran said: > >> You might want want to ask them why they are now a problem when they weren’t >> before (Also worth noting that many of these ISP's own contracts with their >> customers have rather similar indemnification clauses.) > > Actually, it's probably ARIN that should be doing the asking, and seeing if > they can change the wording and/or rephrase the issue to allay concerns. > > It sounds to me like ARIN's *intent* was "if you get sued by your customers because > you screw the pooch on deployment, it's your screw-up to clean up and not our > problem". Or at least I *hope* that was the intent (see next paragraph) That is indeed the intent - please deploy routing validation using best practices, so that you & your customers don’t suffer any adverse impact when ARIN's repository is not available. > But I suspect a lot of companies are reading it as: "If a spammer sues you for using > a block list that prevents them from spamming your customers, you can't end up > owing money to the block list maintainers. But if you rely on the ARIN TAL, and get > sued by an address hijacker, you could end up owing money to ARIN”. It’s is not “you owe money to ARIN’, but it could be “you need to defend both yourself and ARIN from your customers’ litigation should you get it wrong." > (Having said that, John, it takes a special sort of CEO to stand out and be seen > in situations like this, and the world could probably use more CEO's like that…) fairly easy to do if one has a thick skin… ;-) Thanks! /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 rubensk at gmail.com Wed Aug 14 16:41:21 2019 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 14 Aug 2019 13:41:21 -0300 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: <21C5B8F5-61E5-4309-BF4B-D8AC0C14397E@arin.net> References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> <248778.1565795740@turing-police> <21C5B8F5-61E5-4309-BF4B-D8AC0C14397E@arin.net> Message-ID: On Wed, Aug 14, 2019 at 1:09 PM John Curran wrote: > On 14 Aug 2019, at 11:15 AM, Valdis Klētnieks > wrote: > > > > On Wed, 14 Aug 2019 02:42:09 -0000, John Curran said: > > > >> You might want want to ask them why they are now a problem when they > weren’t > >> before (Also worth noting that many of these ISP's own contracts with > their > >> customers have rather similar indemnification clauses.) > > > > Actually, it's probably ARIN that should be doing the asking, and seeing > if > > they can change the wording and/or rephrase the issue to allay concerns. > > > > It sounds to me like ARIN's *intent* was "if you get sued by your > customers because > > you screw the pooch on deployment, it's your screw-up to clean up and > not our > > problem". Or at least I *hope* that was the intent (see next paragraph) > > That is indeed the intent - please deploy routing validation using best > practices, so that you & your customers don’t suffer any adverse impact > when ARIN's repository is not available. > > Or, move all your number resources to a subsidiary in the AP region, pay membership fees to APNIC instead of ARIN, and use their trust anchor instead of ARIN's. BTW, since all 5 RIRs have certificates signing the whole IP address space, it really makes no difference. Rubens -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at emj.se Wed Aug 14 16:45:37 2019 From: eric at emj.se (=?UTF-8?Q?Eric_Lindsj=c3=b6?=) Date: Wed, 14 Aug 2019 18:45:37 +0200 Subject: =?UTF-8?Q?Re=3a_new_BGP_hijack_=26_visibility_tool_=e2=80=9cBGPaler?= =?UTF-8?B?dGVy4oCd?= In-Reply-To: References: Message-ID: <5e437483-9f11-1b1b-be70-51e68202216e@emj.se> On 8/14/19 4:54 PM, Job Snijders wrote: > Dear NANOG, > > Recently NTT investigated how to best monitor the visibility of our > own and our subsidiaries’ IP resources in the BGP Default-Free Zone. > We were specifically looking how to get near real-time alerts funneled > into an actionable pipeline for our NOC & Operations department when > BGP hijacks happen. > > Previously we relied on a commercial “BGP Monitoring as a Service” > offering, but with the advent of RIPE NCC’s “RIS Live” streaming API > [1] we saw greater potential for a self-hosted approach designed > specifically for custom integrations with various business processes. > We decided to write our own tool “BGPalerter” and share the source > code with the Internet community. > > BGPalerter allows operators to specify in great detail how to > distribute meaningful information from the firehose from various BGP > data sources (we call them “connectors”), through data processors > (called “monitors”), finally outputted through “reports” into whatever > mechanism is appropriate (Slack, IRC, email, or a call to your > ticketing system’s API). > > The source code is available on Github, under a liberal open source > license to foster community collaboration: > > https://github.com/nttgin/BGPalerter > > If you wish to contribute to the project, please use Github’s “issues” > or “pull request” features. Any help is welcome! We’d love suggestions > for new features, updates to the documentation, help with setting up a > CI regression testing pipeline, or packaging for common platforms. > > Kind regards, > > Job & Massimo > NTT Ltd > > [1]: https://ris-live.ripe.net/ Excellent, now I don't have to write it myself. Looking forward to testing. Thanks for sharing the fruits of your labor with the community. Kind regards, Eric From kushal.r at h4g.co Wed Aug 14 16:51:53 2019 From: kushal.r at h4g.co (Kushal R.) Date: Wed, 14 Aug 2019 22:21:53 +0530 Subject: new BGP hijack & visibility tool =?UTF-8?Q?=E2=80=9CBGPalerter=E2=80=9D?= In-Reply-To: <5e437483-9f11-1b1b-be70-51e68202216e@emj.se> References: <5e437483-9f11-1b1b-be70-51e68202216e@emj.se> Message-ID: This is great. Will be testing this later in the day. We like a lot of others were using BGPMon. — Kushal R. Executive Management | Host4Geeks Email: kushal.r at h4g.co Skype: kush.raha Phone (Text/WhatsApp): +1-310-405-0010 [tel:+1-310-405-0010] (Global) / +91-8830547876 [tel:+91-8830547876] (India) On Wed, Aug 14, 2019 at 10:19pm, Eric Lindsjö < eric at emj.se [eric at emj.se] > wrote: On 8/14/19 4:54 PM, Job Snijders wrote: > Dear NANOG, > > Recently NTT investigated how to best monitor the visibility of our > own and our subsidiaries’ IP resources in the BGP Default-Free Zone. > We were specifically looking how to get near real-time alerts funneled > into an actionable pipeline for our NOC & Operations department when > BGP hijacks happen. > > Previously we relied on a commercial “BGP Monitoring as a Service” > offering, but with the advent of RIPE NCC’s “RIS Live” streaming API > [1] we saw greater potential for a self-hosted approach designed > specifically for custom integrations with various business processes. > We decided to write our own tool “BGPalerter” and share the source > code with the Internet community. > > BGPalerter allows operators to specify in great detail how to > distribute meaningful information from the firehose from various BGP > data sources (we call them “connectors”), through data processors > (called “monitors”), finally outputted through “reports” into whatever > mechanism is appropriate (Slack, IRC, email, or a call to your > ticketing system’s API). > > The source code is available on Github, under a liberal open source > license to foster community collaboration: > > https://github.com/nttgin/BGPalerter > > If you wish to contribute to the project, please use Github’s “issues” > or “pull request” features. Any help is welcome! We’d love suggestions > for new features, updates to the documentation, help with setting up a > CI regression testing pipeline, or packaging for common platforms. > > Kind regards, > > Job & Massimo > NTT Ltd > > [1]: https://ris-live.ripe.net/ Excellent, now I don't have to write it myself. Looking forward to testing. Thanks for sharing the fruits of your labor with the community. Kind regards, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at rkhtech.org Wed Aug 14 17:06:21 2019 From: ryan at rkhtech.org (Ryan Hamel) Date: Wed, 14 Aug 2019 13:06:21 -0400 Subject: =?UTF-8?Q?Re=3A_new_BGP_hijack_=26_visibility_tool_=E2=80=9CBGPalerter?= =?UTF-8?Q?=E2=80=9D?= In-Reply-To: References: Message-ID: Job, I appreciate the effort and the intent behind this project, but why should the community contribute to an open source project on GitHub that is mainly powered by a closed source binary? Ryan On Wed, Aug 14, 2019, 10:55 AM Job Snijders wrote: > Dear NANOG, > > Recently NTT investigated how to best monitor the visibility of our own > and our subsidiaries’ IP resources in the BGP Default-Free Zone. We were > specifically looking how to get near real-time alerts funneled into an > actionable pipeline for our NOC & Operations department when BGP hijacks > happen. > > Previously we relied on a commercial “BGP Monitoring as a Service” > offering, but with the advent of RIPE NCC’s “RIS Live” streaming API [1] we > saw greater potential for a self-hosted approach designed specifically for > custom integrations with various business processes. We decided to write > our own tool “BGPalerter” and share the source code with the Internet > community. > > BGPalerter allows operators to specify in great detail how to distribute > meaningful information from the firehose from various BGP data sources (we > call them “connectors”), through data processors (called “monitors”), > finally outputted through “reports” into whatever mechanism is appropriate > (Slack, IRC, email, or a call to your ticketing system’s API). > > The source code is available on Github, under a liberal open source > license to foster community collaboration: > > https://github.com/nttgin/BGPalerter > > If you wish to contribute to the project, please use Github’s “issues” or > “pull request” features. Any help is welcome! We’d love suggestions for new > features, updates to the documentation, help with setting up a CI > regression testing pipeline, or packaging for common platforms. > > Kind regards, > > Job & Massimo > NTT Ltd > > [1]: https://ris-live.ripe.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alarig at swordarmor.fr Wed Aug 14 17:13:47 2019 From: alarig at swordarmor.fr (Alarig Le Lay) Date: Wed, 14 Aug 2019 19:13:47 +0200 Subject: =?UTF-8?Q?Re=3a_new_BGP_hijack_=26_visibility_tool_=e2=80=9cBGPaler?= =?UTF-8?B?dGVy4oCd?= In-Reply-To: References: Message-ID: <9088ffb4-eb3b-ebf2-00aa-a12b6d0e1686@swordarmor.fr> Hi, You can build it yourself, see https://github.com/nttgin/BGPalerter#more-information-for-developers I think that the binaries are here for thoses that don’t want to install all the build-chain. -- Alarig On 14/08/2019 19:06, Ryan Hamel wrote: > Job, > > I appreciate the effort and the intent behind this project, but why > should the community contribute to an open source project on GitHub > that is mainly powered by a closed source binary? > > Ryan > > On Wed, Aug 14, 2019, 10:55 AM Job Snijders > wrote: > > Dear NANOG, > > Recently NTT investigated how to best monitor the visibility of > our own and our subsidiaries’ IP resources in the BGP Default-Free > Zone. We were specifically looking how to get near real-time > alerts funneled into an actionable pipeline for our NOC & > Operations department when BGP hijacks happen. > > Previously we relied on a commercial “BGP Monitoring as a Service” > offering, but with the advent of RIPE NCC’s “RIS Live” streaming > API [1] we saw greater potential for a self-hosted approach > designed specifically for custom integrations with various > business processes. We decided to write our own tool “BGPalerter” > and share the source code with the Internet community. > > BGPalerter allows operators to specify in great detail how to > distribute meaningful information from the firehose from various > BGP data sources (we call them “connectors”), through data > processors (called “monitors”), finally outputted through > “reports” into whatever mechanism is appropriate (Slack, IRC, > email, or a call to your ticketing system’s API).  > > The source code is available on Github, under a liberal open > source license to foster community collaboration: > >     https://github.com/nttgin/BGPalerter  > > If you wish to contribute to the project, please use Github’s > “issues” or “pull request” features. Any help is welcome! We’d > love suggestions for new features, updates to the documentation, > help with setting up a CI regression testing pipeline, or > packaging for common platforms. > > Kind regards, > > Job & Massimo > NTT Ltd > > [1]: https://ris-live.ripe.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzs at theworld.com Wed Aug 14 17:27:44 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Wed, 14 Aug 2019 13:27:44 -0400 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: <5D530893.4040002@blastcomm.com> References: <5D530893.4040002@blastcomm.com> Message-ID: <23892.17552.779451.166121@gargle.gargle.HOWL> Are "surge protectors" really of much use against lightning? I suspect not, other than minor inductions tho perhaps some are specially designed for lightning. I wouldn't assume, I'd want to see the word "lightning" in the specs. I once had a lightning strike (at Harvard Chemistry), probably just an induction on a wire some idiot had strung between building roofs (I didn't even know it existed) and the board it was attached to's solder was melted and burned, impressive! More impressive was the board mostly worked, it was just doing some weird things which led me to inspect it...oops. My understanding was that the only real protection is an "air gap", which a piece of fiber will provide in essence, and even that better be designed for lightning as it can leap small gaps. Check your insurance, including the deductibles, keep spares on hand. P.S. My grandmother would tell a story about how what sounded like the ever-controversial "ball lightning" came into her home when she was young. Good luck with that! https://en.wikipedia.org/wiki/Ball_lightning -- -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 savage at savage.za.org Wed Aug 14 17:33:27 2019 From: savage at savage.za.org (Chris Knipe) Date: Wed, 14 Aug 2019 19:33:27 +0200 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: <23892.17552.779451.166121@gargle.gargle.HOWL> References: <5D530893.4040002@blastcomm.com> <23892.17552.779451.166121@gargle.gargle.HOWL> Message-ID: Think surge protectors will protect against strikes that is far away, and the residual surge it creates. A direct strike? Don't think there's anything that will really protect against that. On Wed, Aug 14, 2019 at 7:29 PM wrote: > > Are "surge protectors" really of much use against lightning? I suspect > not, other than minor inductions tho perhaps some are specially > designed for lightning. I wouldn't assume, I'd want to see the word > "lightning" in the specs. > > I once had a lightning strike (at Harvard Chemistry), probably just an > induction on a wire some idiot had strung between building roofs (I > didn't even know it existed) and the board it was attached to's solder > was melted and burned, impressive! More impressive was the board > mostly worked, it was just doing some weird things which led me to > inspect it...oops. > > My understanding was that the only real protection is an "air gap", > which a piece of fiber will provide in essence, and even that better > be designed for lightning as it can leap small gaps. > > Check your insurance, including the deductibles, keep spares on hand. > > P.S. My grandmother would tell a story about how what sounded like the > ever-controversial "ball lightning" came into her home when she was > young. Good luck with that! > > https://en.wikipedia.org/wiki/Ball_lightning > > -- > -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* > -- Regards, Chris Knipe -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Wed Aug 14 17:35:00 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Wed, 14 Aug 2019 13:35:00 -0400 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: <21C5B8F5-61E5-4309-BF4B-D8AC0C14397E@arin.net> References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> <248778.1565795740@turing-police> <21C5B8F5-61E5-4309-BF4B-D8AC0C14397E@arin.net> Message-ID: <259938.1565804100@turing-police> On Wed, 14 Aug 2019 16:07:49 -0000, John Curran said: > > But I suspect a lot of companies are reading it as: "If a spammer sues you for using > > a block list that prevents them from spamming your customers, you can't end up > > owing money to the block list maintainers. But if you rely on the ARIN TAL, and get > > sued by an address hijacker, you could end up owing money to ARIN". > It's is not "you owe money to ARIN", but it could be "you need to defend both > yourself and ARIN from your customers litigation should you get it wrong." Is there any workable way to remove or diminish the perception of liability in the case of using it *correctly*? I admit that (a) I'm not a lawyer and (b) when I actually tried to read it I couldn't actually tell if it was "you promise to defend us if you screw it up and customer traffic gets accidentally dropped on the floor" or "you promise to defend us if you use it correctly and miscreant traffic is intentionally dropped on the floor"... There's obviously a disconnect where people aren't worried about indemnifying Spamhaus for using their block list, but are worried about indemnifying ARIN for using the TAL. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From swmike at swm.pp.se Wed Aug 14 17:40:36 2019 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 14 Aug 2019 19:40:36 +0200 (CEST) Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: <5D530893.4040002@blastcomm.com> <23892.17552.779451.166121@gargle.gargle.HOWL> Message-ID: On Wed, 14 Aug 2019, Chris Knipe wrote: > Think surge protectors will protect against strikes that is far away, and > the residual surge it creates. > > A direct strike? Don't think there's anything that will really protect > against that. https://imgur.com/a/dzTVw5a has been posted lately here in a swedish fiber-related facebook group. So even though you might have fiber coming in, remember that both the power grid and copper network cables are conductors and can make the lightning strike jump between devices. So the OP of this thread is right in wanting to protect both the network cables and power cables. PS. I don't have more details about this specific case. -- Mikael Abrahamsson email: swmike at swm.pp.se From alan.buxey at gmail.com Wed Aug 14 17:46:21 2019 From: alan.buxey at gmail.com (Alan Buxey) Date: Wed, 14 Aug 2019 18:46:21 +0100 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: Message-ID: hi, have seen and suffered from same. nearby strikes can cause enough surge to fry things. best solution - air-gaps where possible between devices (eg fibre to link switches), surge protectors on ethernet cables where needed (eg feeds from Access points) - and if the APs have external antennae then use lightning arrestors on the coax cables. why main wireless vendors still don't do SFP/SFP+-based APs I don't know... (would mean only the AP cooks and the edge switch isnt the victim.... alan From amitchell at isipp.com Wed Aug 14 17:58:04 2019 From: amitchell at isipp.com (Anne P. Mitchell, Esq.) Date: Wed, 14 Aug 2019 11:58:04 -0600 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: <259938.1565804100@turing-police> References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> <248778.1565795740@turing-police> <21C5B8F5-61E5-4309-BF4B-D8AC0C14397E@arin.net> <259938.1565804100@turing-police> Message-ID: > There's obviously a disconnect where people aren't worried about indemnifying > Spamhaus for using their block list, but are worried about indemnifying ARIN for > using the TAL. That would be because there is a rather substantial difference between publishing an IP address for which you have spam in hand, and are saying (and only saying) "I received spam from this IP address" (not to mention something which people use to only affect inbound email), and hosting something on which others rely for making their acceptance decision of all legitimate Internet traffic, as well as for the ability to not move malicious (or even accidentally misconfigured) Internet traffic. Anne Anne P. Mitchell, Attorney at Law Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose CEO/President, Institute for Social Internet Public Policy SuretyMail Email Reputation Certification Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant Board of Directors, Denver Internet Exchange Board of Directors, Asilomar Microcomputer Workshop Legal Counsel: The CyberGreen Institute Former Counsel: Mail Abuse Prevention System (MAPS) Member: California Bar Association From nwarren at barryelectric.com Wed Aug 14 19:51:23 2019 From: nwarren at barryelectric.com (Nicholas Warren) Date: Wed, 14 Aug 2019 19:51:23 +0000 Subject: Access to Level3 PoP? Message-ID: We are needing access into Level3/Centurylink's PoP at Monett Missouri to test our fiber. Does anyone have an email, phone number, or smoke signal we could use to get access to test fiber? Support is, sadly, not being very helpful. Nich Warren From rfg at tristatelogic.com Wed Aug 14 20:27:29 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 14 Aug 2019 13:27:29 -0700 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: Message-ID: <53883.1565814449@segfault.tristatelogic.com> In message , John Curran wrote: >Alas, it’s not those who fail to properly configure RPKI that are likely to be >litigating, but rather their impacted customers and those customers' business >partners who all were unable to communicate due to no fault of their own. > >Such a matter will not be thrown out of court, but will be the start of a long >and very expensive process involving claims, discovery, experts, etc... Perhaps. There are certainly some big players (AWS) that if routing were interrupted for even, say, 12 hours, a lot of folks would get really mad about. Correct me if I'm wrong, but one of your presentation slides seemed to suggest that a separate arms-length legal entity could be established to do the RPKI stuff, thus offloading most or all of the potential liability onto and into this separate entity, which could conveniently have minimal assets of the kind that might inspire members of the plaintiff's bar who are looking for deep pockets. Is that an actual possibility, or did you just throw that in there for the sake of completness? Personally, I don't much care how the problem gets solved, as long as it gets solved. The fundamental BGP problem has been known and discussed now for 20+ years and it is only getting more dire and ominous, day by day. Regards, rfg From eric.kuhnke at gmail.com Thu Aug 15 01:03:56 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 14 Aug 2019 18:03:56 -0700 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: Message-ID: I would begin by referencing the grounding section here: https://www.blm.gov/sites/blm.gov/files/Lands_ROW_Motorola_R56_2005_manual.pdf Of utmost importance is that everything is bonded to the same potential. This means that if they have stuff on a roof, outdoor antennas or APs, whatever, it ground needs to be bonded to the building's AC electrical service entrance ground, ufer ground if one exists, and so forth. This is probably the lowest cost ohm meter that is suitable for real world use: https://www.amazon.com/Extech-382252-Ground-Resistance-Tester/dp/B00390G3YA The WISP community has over the past twenty years of painful experience learned to use a combination of high quality ethernet surge protectors (previously mentioned McCown Tech suppressors or their competitors) and comprehensive grounding. On Tue, Aug 13, 2019 at 11:23 AM Javier J wrote: > I'm working with a client site that has been hit twice, very close by > lightening. > > I did lots of electrical work/upgrades/grounding but now I want to focus > on protecting Ethernet connections between core switching/other devices > that can't be migrated to fiber optic. > > I was looking for surge protection devices for Ethernet but have never > shopped for anything like this before. Was wondering if anyone has deployed > a solution? > They don't have a large presence on site (I have been moving all of their > core stuff to AWS) but they still have core networking / connectivity and > PoE cameras / APs around the property. > Since migrating their onsite servers/infra to the cloud, now their > connectivity is even more important. > > This is a small site, maybe about 200 switch ports, but I would only need > to protect maybe 12 core ones. but would be something I could use in the > future with larger deployments. > it's just a 1Gbe network BTW. > > Hope someone with more experience can help make hardware recommendations? > > Thanks in advance. > > - Javier > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists.nanog at monmotha.net Thu Aug 15 01:29:13 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Wed, 14 Aug 2019 21:29:13 -0400 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: Message-ID: <19dcf323-8bb4-fec7-2160-b75c7a557c89@monmotha.net> On 8/13/19 2:32 PM, Warren Kumari wrote: > This probably won't fully solve your problem, but I run a bunch of > Ubiquiti access points and similar -- I suffered a number of lightning > related outages, and then started using their TOUGHcable - > https://www.ui.com/accessories/toughcable/ While ToughCable isn't bad (especially for the price), if you want something REALLY durable both physically and against electrical transients, I've been very happy with Primus C6CMXFS-1864BK. It costs quite a bit more than the ToughCable but has real water blocking (which means you had better be prepared to deal with "Icky Pic"), heavy shielding with drain, meets or exceeds CAT6 (which means you can push gigE a bit beyond 100m pretty reliably if you've got a tall tower or a hut far away from a tower base), and has 23AWG wire so PoE, especially Ubnt's crummy 24V passive POE, can go farther, too. Be warned it's a bear to terminate. In addition to the waterblock, the cable diameter is too large for typical crimp-on RJ45 ends. You have to either use special ends (which Primus sells, among others) or terminate it to a punch block which, while not usually a problem in a hut, is often problematic up on a tower. Ubnt also makes an outdoor fiber media converter I've found useful for "small cell" style wISP deployments where I can drag my own fiber to the tower/pole and don't want/need a hut or enclosure at the base. Part number is F-POE-G2. That'll let you get your power and signal separated. I do wish they'd just put SFP slots in their radios, but at the price they sell them for, I guess I can't complain too much. I'd put real 802.3af/at PoE higher on the list of wants, honestly. As to actual surge protectors, I see there have been some other suggestions in the list, and I'll defer to them. I've personally had decent luck with just making sure the Ubnt passive POE injectors (which I need since I don't usually use their switches) are well grounded to be mostly sufficient (along with the tower and hut having proper grounding infrastructure). I've not lost any radios, though I've had some lockups requiring power cycle after nearby lightning strikes on some of the lower end WA based platforms. The XC based platforms seem hardier. My sample size isn't huge, though. I'm usually of the impression that, unless you've got carrier (cellular or committed-rate microwave) class wireless gear on the tower or aggressive SLAs you have to meet from a wireless PoP, it's probably cheaper overall to just take reasonable precautions against lightning than it is to try to make things handle a "direct" strike. Figure in the wISP world, tech moves so fast that you're having to put new things on the tower at least every 3-5 years anyway, so as long as an unscheduled trip up to the tower doesn't cost you $ARM+$LEG, it's probably easier to just take a lightning strike that fries everything due to extreme proximity as an unscheduled upgrade than the try to handle it electrically. "Nearby" strikes, static, electrical transients on your utility line, etc. are a different matter. Those you can economically protect against i.e. the protection will not cost as much or more than the gear and service you're protecting. -- Brandon Martin From eric.kuhnke at gmail.com Thu Aug 15 01:54:03 2019 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 14 Aug 2019 18:54:03 -0700 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: <19dcf323-8bb4-fec7-2160-b75c7a557c89@monmotha.net> References: <19dcf323-8bb4-fec7-2160-b75c7a557c89@monmotha.net> Message-ID: Another copper cable considered a "gold standard" for outdoor shielded + 9th ESD drain and ground wire, intended for long term rooftop and tower installation is Shireen. There's a variety of types. https://www.shireeninc.com/osc/cables/cat6 On Wed, Aug 14, 2019 at 6:30 PM Brandon Martin wrote: > On 8/13/19 2:32 PM, Warren Kumari wrote: > > This probably won't fully solve your problem, but I run a bunch of > > Ubiquiti access points and similar -- I suffered a number of lightning > > related outages, and then started using their TOUGHcable - > > https://www.ui.com/accessories/toughcable/ > > While ToughCable isn't bad (especially for the price), if you want > something REALLY durable both physically and against electrical > transients, I've been very happy with Primus C6CMXFS-1864BK. It costs > quite a bit more than the ToughCable but has real water blocking (which > means you had better be prepared to deal with "Icky Pic"), heavy > shielding with drain, meets or exceeds CAT6 (which means you can push > gigE a bit beyond 100m pretty reliably if you've got a tall tower or a > hut far away from a tower base), and has 23AWG wire so PoE, especially > Ubnt's crummy 24V passive POE, can go farther, too. > > Be warned it's a bear to terminate. In addition to the waterblock, the > cable diameter is too large for typical crimp-on RJ45 ends. You have to > either use special ends (which Primus sells, among others) or terminate > it to a punch block which, while not usually a problem in a hut, is > often problematic up on a tower. > > Ubnt also makes an outdoor fiber media converter I've found useful for > "small cell" style wISP deployments where I can drag my own fiber to the > tower/pole and don't want/need a hut or enclosure at the base. Part > number is F-POE-G2. That'll let you get your power and signal > separated. I do wish they'd just put SFP slots in their radios, but at > the price they sell them for, I guess I can't complain too much. I'd > put real 802.3af/at PoE higher on the list of wants, honestly. > > As to actual surge protectors, I see there have been some other > suggestions in the list, and I'll defer to them. I've personally had > decent luck with just making sure the Ubnt passive POE injectors (which > I need since I don't usually use their switches) are well grounded to be > mostly sufficient (along with the tower and hut having proper grounding > infrastructure). I've not lost any radios, though I've had some lockups > requiring power cycle after nearby lightning strikes on some of the > lower end WA based platforms. The XC based platforms seem hardier. My > sample size isn't huge, though. > > I'm usually of the impression that, unless you've got carrier (cellular > or committed-rate microwave) class wireless gear on the tower or > aggressive SLAs you have to meet from a wireless PoP, it's probably > cheaper overall to just take reasonable precautions against lightning > than it is to try to make things handle a "direct" strike. Figure in > the wISP world, tech moves so fast that you're having to put new things > on the tower at least every 3-5 years anyway, so as long as an > unscheduled trip up to the tower doesn't cost you $ARM+$LEG, it's > probably easier to just take a lightning strike that fries everything > due to extreme proximity as an unscheduled upgrade than the try to > handle it electrically. > > "Nearby" strikes, static, electrical transients on your utility line, > etc. are a different matter. Those you can economically protect against > i.e. the protection will not cost as much or more than the gear and > service you're protecting. > -- > Brandon Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Thu Aug 15 03:16:24 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 14 Aug 2019 20:16:24 -0700 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: <4fcb73bf-224f-e011-f310-522193c86667@efes.iucc.ac.il> Message-ID: <55364.1565838984@segfault.tristatelogic.com> In message <4fcb73bf-224f-e011-f310-522193c86667 at efes.iucc.ac.il>, Hank Nussbacher wrote: >Just as an observer to your long resource theft postings: >- Do you attempt to contact directly the organization or person who have >had their resource taken over? To the extent that I can spare the time, and to the extent that I am able to do so, (which is often limited by time zone differences) yes, I do. >- Do they care or are they apathetic? Before answering let me clarify first the two different classes of problems that I've most often been looking at. Everybody including myself has in the past used the term "hijack" but I'm going to try to stop doing that, in future, and instead use the more precise terms "squatting" and "theft", where "theft" involves a case where the relevant WHOIS records have been materially "fiddled" by the usurper. In both cases, the usurpers generally aim, first and foremost, for the low hanging fruit, which is to say legacy blocks that were abandoned years and years ago, sometimes even decades ago, back when IP addresses had zero monitizable value. When contacted, victims in these cases are typically at first utterly perplexed, and when I explain to them that I am trying to give them back stuff that they already own, and which in some cases is worth considerable money on the open market, they *do* look a gift horse in the mouth, and they assume, quite reasonably I think, given the current way of the world, that *I* am trying to run some kind of elaboarate scam on them. It takes a lot of talking on my part to convince them that no. I'm actually just a good samaritan, and that no, I am -not- going to be asking them to first send any sort of "release fee" via WesterUnion or Bitcoin or WebMoney before they can have their own blocks back. Even after they have been convinced that this ain't a scam and that they do own the stuff I say they own, most are often entirely lackadaisical about getting off their butts and then working with the relevant RIRs to get their own stuff back. Even when I try to get them fired up by telling them that "cybercriminals" have stolen their blocks, and the fact that evil that is being done under their names may negatively affect THEIR public reputations, it's still like watching paint dry, for me anyway. Clearly, nobody but me has any sense of urgency about these things at all. >- If the resource owner is no where to be found, why should we as a >community care? I'm so glad you asked. Before answering I should first note that it is actually quite rare when a sufficient amount of research on my part fails to turn up a relevant "successor or assign" which would, by rights, be the modern day entity with a legitimate claim on the asset. So the "nowhere to be found" case is by far the exception, rather than the rule. Regardless, in -either- the case where no heir can be found -or- in the case where the rightful heir is either just too dumb or just too lazy to take the minimal steps necessary to reclaim the property (and/or before this has ocurred) the community should care because the kind of people who either steal or squat on IPv4 blocks are, almost without exception, not the kind of people who anybody sane wants to be accepting packets from, let alone peering with. There is, in my opinion and experience, a high degree of correlation between skulduggery with respect to -obtaining- (illicitly) IPv4 address blocks and using those addresses in a manner which is not at all conducive to the general welfare of the Internet or its users. >Report it on some webpage and call it "Internet >Resources stolen", document every incident as you do via email, send a >copy to the appropriate RIR and upstream ISP allowing the hijack in >question to show that you did the appropriate effort and we can then >move on. I can and will stop posting here, and go off an blog about this stuff instead, if the consensus is that I'm utterly off-topic or utterly uninteresting and useless. But a few folks have told me they find this stuff interesting, and it has operational significance, I think. So for now, at least, I'd like to continue to share here. As regards to reporting to RIRs or upstreams, what makes you think that either of those would care one wit? The RIRs are not the Internet Police, or so I am told. They don't configure routers. Upstreams are, in my experience utterly intransigent and unresponsive, especially in the absence of public exposure of the self-evident problem(s).... like the time I tried to get Telecom Italia to get off their asses and do something... anything... about their criminal mass squatting customer. It wasn't until much later on, after WhiteOps and Google had exposed the massive click fraud operation that was behind all that that Telecom Italia saw fit to lift even a single finger to actaully DO anything at all. And the last time I looked, Telecom Italia was *still* peering with the exact same crooked ASN, even though most or all of the people who were identified, by LE, and being behind it are nowaadays facing numerous federal criminal charges here in the U.S. Please remember also that there are two separate classes of problems involved here, i.e. mere "sqyuatting" and separately, "theft", where some clever crook has managed to get in and actually fiddle with one or more RIR-maintained WHOIS records. I very explicitly -do not- want to just report this latter class of incidents exclusively and only to the RIRs themselves. Some of these cases raise quite serious questions about the operation of and oversight of various RIRs, and I feel very strongly that those questions deserve to be kicked around in public, and not just between myself and the relevant RIRs, some of whom, at least, may have more than a little incentive to just sweep these things entirely under the carpet. I apologize for being vague and non-specific. For now, I need to be. Later I will be providing further clarity to all I have said above. Regards, rfg From rfg at tristatelogic.com Thu Aug 15 03:45:53 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 14 Aug 2019 20:45:53 -0700 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: <20190810003820.GD2592@jima.tpb.net> Message-ID: <55481.1565840753@segfault.tristatelogic.com> In message <20190810003820.GD2592 at jima.tpb.net>, Niels Bakker wrote: >* rfg at tristatelogic.com (Ronald F. Guilmette) [Sat 10 Aug 2019, 02:26 CEST]: >>As far as I am aware, no RIR makes any effort whatsoever to vet >>changes to WHOIS records, either for IP blocks or ASNs or ORG >>records. > >This is hilarious. You should hear the whining from any EU-based >operator who has to implement the transfer of RIPE NCC resources in >a corporate acquisition. > >I recently was involved with one of those and the amount of due >diligence required by the RIPE NCC was pretty intense. If I were at >an RIR I'd be insulted by your claim of "no... effort whatsoever". I do not and would not dispute that at least a few RIRs... in particular ARIN and RIPE... are -very- good and -very- diligent these days in their vetting of the legitimacy of what the RIRs themselves, and on their (secret) -internal- books list as "registrants" of number resources. But what is listed on the internal books of any given RIR is -not- what appears in the WHOIS records. It's just that simple. Your RIR may have given you a full rectal exam prior to giving you your IP addresses. But how does that help -me- if you're sending me bad packets and your WHOIS records says the following? Registrant: Salvador Dali Address: 12345 Moon St., The Universe, 999999999 Phone: <> Regards, rfg From hank at efes.iucc.ac.il Thu Aug 15 04:33:19 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 15 Aug 2019 07:33:19 +0300 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: <55364.1565838984@segfault.tristatelogic.com> References: <55364.1565838984@segfault.tristatelogic.com> Message-ID: On 15/08/2019 06:16, Ronald F. Guilmette wrote: >> - If the resource owner is no where to be found, why should we as a >> community care? > I'm so glad you asked. > > > Regardless, in -either- the case where no heir can be found -or- in the > case where the rightful heir is either just too dumb or just too lazy > to take the minimal steps necessary to reclaim the property (and/or before > this has ocurred) the community should care because the kind of people who > either steal or squat on IPv4 blocks are, almost without exception, not the > kind of people who anybody sane wants to be accepting packets from, let > alone peering with. There is, in my opinion and experience, a high > degree of correlation between skulduggery with respect to -obtaining- > (illicitly) IPv4 address blocks and using those addresses in a manner > which is not at all conducive to the general welfare of the Internet or > its users. So if the rightful is apathetic, then won't these new "malicious blocks" just end up in numerous blacklists and all the illegal activity being performed from those usurped blocks will just be blocked in the end?  Since the RIRs won't do much(as much as we have tried) why not just leave it be (as much as it may hurt to do that) and let the bad blocks just become part of the blacklist sludgepool? >> Report it on some webpage and call it "Internet >> Resources stolen", document every incident as you do via email, send a >> copy to the appropriate RIR and upstream ISP allowing the hijack in >> question to show that you did the appropriate effort and we can then >> move on. > I can and will stop posting here, and go off an blog about this stuff > instead, if the consensus is that I'm utterly off-topic or utterly > uninteresting and useless. But a few folks have told me they find > this stuff interesting, and it has operational significance, I think. > So for now, at least, I'd like to continue to share here. > > Suggestion: post here a link to your new blog for every incident you find.  State here something like "/22 stolen from xxxx registered in country aaa by yyy located in country bbb".  Those that are interested will click on the link and I suggest you allow comments on every blog post so that people can respond and comment. Regards, Hank From rfg at tristatelogic.com Thu Aug 15 04:40:29 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 14 Aug 2019 21:40:29 -0700 Subject: ARIN Fantasy WHOIS: NET-216-179-183-0-1 Message-ID: <55755.1565844029@segfault.tristatelogic.com> As if to underscore the point I just tried to make about the fundamental unreliability of ARIN WHOIS records, I just stumbled onto this rather curious entity which was apparently given a sub-allocation of 216.179.183.0/24 beneath the 216.179.128.0/17 (Azuki, Inc.) block as of 2012-01-10: OrgName: Rogers Communications Inc OrgId: RC-82 Address: E 2nd St,Campbell City: Gillette StateProv: WY PostalCode: 82716 Country: US RegDate: 2012-01-10 Updated: 2012-01-10 Ref: https://rdap.arin.net/registry/entity/RC-82 Other that the fact that it has an oddly similar name to one of Canada's largest and most well-known Internet and cell phone companies, the only other thing that's rather remarkable about it is that it was given the 216.179.183.0/24 block, by Azuki, Inc. in 2012. What's odd about that? Well, only the fact that this *Wyoming* incarnation of Rogers Communications had apparently already died and gone to Valhalla some 14 years earlier, in 1998: https://wyobiz.wy.gov/Business/FilingDetails.aspx?eFNum=070023242004106130056183154143023082073130141117 Moral of the story: Don't ever let anybody tell you that ghosts... even ghosts of long dead companies... aren't real or that they do not walk among us. Their immortal auras pervade the very ether we breath. And they have their own IPs, apparently. But, you know, if your customers are getting hack attacks emmanating from 216.179.183.0/24... well... to quote the old Ghostbusters tag line "Who you gonna call?" (Hint: Don't waste your time calling the number in the WHOIS record. It's just some bloody preschool.) Regards, rfg From mansaxel at besserwisser.org Thu Aug 15 07:17:30 2019 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Thu, 15 Aug 2019 09:17:30 +0200 Subject: OT: Tech bag In-Reply-To: References: Message-ID: <20190815071730.GG23469@besserwisser.org> Subject: Re: OT: Tech bag Date: Mon, Aug 05, 2019 at 01:07:23PM -0700 Quoting Aaron Russo (arusso at pixar.com): > I have been really happy with my Tom Bihn Brain Bag (https://tombihn.com). > I carry a 15in and 13in laptop along with a snake charmer accessory for all > my cables. If you loosen the straps there’s plenty of room to also stuff a > jacket AND a small to medium sized UPS parcel if need be. The Brain Bag continues to serve me well, after some 10 years. Definitely seconded. As EDC it holds all I need, and works for a short trip, too. For serious install work, (bordering on truck roll) I end up carrying a fiber measurement/maintenance box (a small Peli-style case) and my leather tool case. Anything described with the phrase " distinctive standard issue cases, produced for over half a century." immediately creates desire. https://www.canford.co.uk/Products/16-389_TOOLMARK-TOOL-CASE-No.6-Brown-with-handles -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 Do you guys know we just passed thru a BLACK HOLE in space? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jcurran at arin.net Thu Aug 15 12:01:28 2019 From: jcurran at arin.net (John Curran) Date: Thu, 15 Aug 2019 12:01:28 +0000 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: <55364.1565838984@segfault.tristatelogic.com> References: <55364.1565838984@segfault.tristatelogic.com> Message-ID: On 14 Aug 2019, at 11:16 PM, Ronald F. Guilmette > wrote: Report it on some webpage and call it "Internet Resources stolen", document every incident as you do via email, send a copy to the appropriate RIR and upstream ISP allowing the hijack in question to show that you did the appropriate effort and we can then move on. I can and will stop posting here, and go off an blog about this stuff instead, if the consensus is that I'm utterly off-topic or utterly uninteresting and useless. But a few folks have told me they find this stuff interesting, and it has operational significance, I think. So for now, at least, I'd like to continue to share here. As regards to reporting to RIRs or upstreams, what makes you think that either of those would care one wit? The RIRs are not the Internet Police, or so I am told. Good morning Ron – The RIRs are not the Internet Police, but we do care very much about the integrity of the Internet number registry system. Please report to ARIN any instances of number resource records in the ARIN registry whose organization you believe to be incorrect – while such records are updated only based on appropriate documentation, that doesn’t preclude the use of fraudulent documentation that goes undetected. Thanks! /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at floridavirtualsolutions.com Wed Aug 14 17:54:47 2019 From: nick at floridavirtualsolutions.com (Nick Olsen) Date: Wed, 14 Aug 2019 13:54:47 -0400 Subject: Protecting 1Gb Ethernet From Lightning Strikes In-Reply-To: References: <5D530893.4040002@blastcomm.com> <23892.17552.779451.166121@gargle.gargle.HOWL> Message-ID: This. Very little will protect you from a direct strike. Working for a WISP for a long time as a past life, I've seen radios physically split in half. Chunks of concrete taken out of walls near the equipment. Black ethernet ports that have functionally soldered themselves into the jack. Six figures worth of lost gear over the years (Does sound like much, But at ~$80 a pop for cheap wisp gear. That's a lot of equipment.) Outside of a direct strike, You can still melt gear left and right. The fix is no one solution, But multiple. 1. Shielded Ethernet with proper shielded and bonded ends. 2. Proper Grounding 3. Ethernet Surge Suppressors. 4. Proper Grounding. 5. Proper Grounding. The key is to make your sensitive electronic equipment a higher resistance path instead of your grounding system. You're going to get inductance build up on cables you just have to get it to ground through something that isn't your site switch/router. And it's going to get there one way or another. Sometimes this can be harder then one might think. Even considering sinking your own ground rod, And replacing it every few years. As a ground rod becomes less and less effective with every strike (Depending on what it's sunk in). Ethernet Surge Suppressors CAN help. But only in assisting in getting whatever was already on the cable to ground. And don't forget ground potential differences between different grounding systems. Doing the above will get you through most near by strikes. But all bets are off on direct strikes. The above can also help you with a ton of other interference. Like a giant FM transmitter running at 100KW a stones throw away from your equipment but that's another story for another thread. On Wed, Aug 14, 2019 at 1:34 PM Chris Knipe wrote: > Think surge protectors will protect against strikes that is far away, and > the residual surge it creates. > > A direct strike? Don't think there's anything that will really protect > against that. > > On Wed, Aug 14, 2019 at 7:29 PM wrote: > >> >> Are "surge protectors" really of much use against lightning? I suspect >> not, other than minor inductions tho perhaps some are specially >> designed for lightning. I wouldn't assume, I'd want to see the word >> "lightning" in the specs. >> >> I once had a lightning strike (at Harvard Chemistry), probably just an >> induction on a wire some idiot had strung between building roofs (I >> didn't even know it existed) and the board it was attached to's solder >> was melted and burned, impressive! More impressive was the board >> mostly worked, it was just doing some weird things which led me to >> inspect it...oops. >> >> My understanding was that the only real protection is an "air gap", >> which a piece of fiber will provide in essence, and even that better >> be designed for lightning as it can leap small gaps. >> >> Check your insurance, including the deductibles, keep spares on hand. >> >> P.S. My grandmother would tell a story about how what sounded like the >> ever-controversial "ball lightning" came into her home when she was >> young. Good luck with that! >> >> https://en.wikipedia.org/wiki/Ball_lightning >> >> -- >> -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* >> > > > -- > > Regards, > Chris Knipe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Thu Aug 15 15:10:13 2019 From: job at ntt.net (Job Snijders) Date: Thu, 15 Aug 2019 17:10:13 +0200 Subject: new BGP hijack & =?utf-8?Q?visibility_?= =?utf-8?B?dG9vbCDigJxCR1BhbGVydGVy4oCd?= In-Reply-To: <9088ffb4-eb3b-ebf2-00aa-a12b6d0e1686@swordarmor.fr> References: <9088ffb4-eb3b-ebf2-00aa-a12b6d0e1686@swordarmor.fr> Message-ID: <20190815151013.GZ4901@hanna.meerval.net> Hi Ryan, Alarig, > On 14/08/2019 19:06, Ryan Hamel wrote: > > I appreciate the effort and the intent behind this project, but why > > should the community contribute to an open source project on GitHub > > that is mainly powered by a closed source binary? > On Wed, Aug 14, 2019 at 07:13:47PM +0200, Alarig Le Lay wrote: > You can build it yourself, see > https://github.com/nttgin/BGPalerter#more-information-for-developers > > I think that the binaries are here for thoses that don’t want to install > all the build-chain. Indeed, the binary files in the github repository in the 'bin/' directory are merely provided as a convenience service so interested people don't need to compile the software themselves in order to run tests. This project is 100% open source. At some point in the future ready made binaries should move to a different place, for example perhaps we can distribute packages through the PPA mechanism for debian/ubuntu. It would be cool if we get to the point where one can install the software by simply issuing a command like "apt install bgpalerter". Help with packaging is most welcome! :-) Kind regards, Job From morrowc.lists at gmail.com Thu Aug 15 15:38:17 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 15 Aug 2019 11:38:17 -0400 Subject: =?UTF-8?Q?Re=3A_new_BGP_hijack_=26_visibility_tool_=E2=80=9CBGPalerter?= =?UTF-8?Q?=E2=80=9D?= In-Reply-To: <20190815151013.GZ4901@hanna.meerval.net> References: <9088ffb4-eb3b-ebf2-00aa-a12b6d0e1686@swordarmor.fr> <20190815151013.GZ4901@hanna.meerval.net> Message-ID: This looks like fun! (a few questions for the RIPE folk, I think though below) What is the expected load of streaming clients on the RIPE service? (I wonder because I was/am messing about with something similar, though less node and js... not that that's relevant here). I hadn't seen the ripe folk pipe up anywhere with what their SLO/etc is for the ris-live service? (except their quip about: "used to run in a tmux session I had to occassioanlly ssh into and restart when rebooted" I believe the end of that quip in Iceland was: "and now its' running as a real service") Also, one of the strengths to the 'monitoring as a service' folks is their number of collection points and breadth of ASN to which they interconnect those points/ RISLive, I think, reports out from ~37 or so RIPE probes, how do we (the internet) get more deployed (or better interconnection to the current sets)? and maybe even more imoprtantly... what's the right spread/location/interconnectivity map for these probes? thanks! for showing what's possible with tooling being developed by like minded individuals :) -chris On Thu, Aug 15, 2019 at 11:11 AM Job Snijders wrote: > > Hi Ryan, Alarig, > > > On 14/08/2019 19:06, Ryan Hamel wrote: > > > I appreciate the effort and the intent behind this project, but why > > > should the community contribute to an open source project on GitHub > > > that is mainly powered by a closed source binary? > > > On Wed, Aug 14, 2019 at 07:13:47PM +0200, Alarig Le Lay wrote: > > You can build it yourself, see > > https://github.com/nttgin/BGPalerter#more-information-for-developers > > > > I think that the binaries are here for thoses that don’t want to install > > all the build-chain. > > Indeed, the binary files in the github repository in the 'bin/' > directory are merely provided as a convenience service so interested > people don't need to compile the software themselves in order to run > tests. This project is 100% open source. > > At some point in the future ready made binaries should move to a > different place, for example perhaps we can distribute packages through > the PPA mechanism for debian/ubuntu. It would be cool if we get to the > point where one can install the software by simply issuing a command > like "apt install bgpalerter". Help with packaging is most welcome! :-) > > Kind regards, > > Job From tim.upthegrove at gmail.com Thu Aug 15 14:34:27 2019 From: tim.upthegrove at gmail.com (Tim Upthegrove) Date: Thu, 15 Aug 2019 10:34:27 -0400 Subject: Service function chaining technologies in service provider networks Message-ID: Hi folks, I am wondering if service provider networks are actively implementing service function chaining, and if so, what kinds of technologies they are using in the network to steer traffic to services. Segment routing was suggested to me as an option that could work, and it seems like a good fit; however, I have no clue how widely deployed it is specifically for service function chaining. At this point I'd just like to understand what some of the common deployment models are from anyone who is willing to share. Thanks, -- Tim Upthegrove -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahmed at jalal.pk Thu Aug 15 16:50:15 2019 From: ahmed at jalal.pk (Ahmed Jalal) Date: Thu, 15 Aug 2019 11:50:15 -0500 Subject: AT&T Wireless Calls Failing to Level - 3 DID's In-Reply-To: References: Message-ID: Hi, I am trying to get in touch with someone at AT&T to look into call failures to our DID's in the southern Mississippi region. Please let me know if I am in the wrong list. Any help would be greatly appreciated. Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From goemon at sasami.anime.net Thu Aug 15 20:59:34 2019 From: goemon at sasami.anime.net (Dan Hollis) Date: Thu, 15 Aug 2019 13:59:34 -0700 (PDT) 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> <89f3dc71-36a0-7e92-5e20-b96ff04bccec@satchell.net> <20190812192622.GA7757@gsp.org> Message-ID: On Mon, 12 Aug 2019, Bruce H McIntosh wrote: > On 8/12/19 3:26 PM, Rich Kulawiec wrote: >> Half my grump with Amazon here is that they have, for all practical >> purposes, unlimited money and unlimited personnel. They should be the >> go-to example for How To Do It Right. They should be the model (or one >> of the models) that we're all trying to emulate, the gold standard that >> we can all point to. >> >> But they're not. >> >> The other half of my grump is that they're enormous, and therefore capable >> of inflicting enormous damage. The larger an operation, the more critical >> it is that abuse/security/et.al. be fully supported, highly responsive, >> empowered to act decisively, etc. >> >> But they're not. >> >> And I have yet to see anyone from Amazon (a) admit this and (b) ask for >> help >> fixing it. > > The larger they are, the more immune from having to follow the rules they > think they are. SBL seems the only way to wake them up. -Dan From jay at west.net Thu Aug 15 21:06:56 2019 From: jay at west.net (Jay Hennigan) Date: Thu, 15 Aug 2019 14:06:56 -0700 Subject: AT&T Wireless Calls Failing to Level - 3 DID's In-Reply-To: References: Message-ID: <4e12ae9b-a4f2-a6e8-4f8d-9766529fe01e@west.net> On 8/15/19 09:50, Ahmed Jalal wrote: > Hi, > > I am trying to get in touch with someone at AT&T to look into call > failures to our DID's in the southern Mississippi region. Please let me > know if I am in the wrong list. VoiceOps is likely to be more specific for this issue. https://puck.nether.net/mailman/listinfo/voiceops -- Jay Hennigan - jay at west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV From michel.py at tsisemi.com Thu Aug 15 23:49:30 2019 From: michel.py at tsisemi.com (Michel Py) Date: Thu, 15 Aug 2019 23:49:30 +0000 Subject: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17) In-Reply-To: <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> References: <49474.1565746124@segfault.tristatelogic.com> <06570278-E1AD-4BB0-A9FC-11A77BED76E1@arin.net> Message-ID: <2addf13c4801477b87619466b62dc293@CRA114.am.necel.com> Hi John, > John Curran wrote : > Even so, we at ARIN are in the midst of a Board-directed review of the RPKI legal framework to see if any improvements can be made > – I will provide further updates once it is completed. Thanks, we appreciate the effort. That being said, something has to be done. I feel that the RPKI validation by ARIN is somehow useless. Why : because few download the TAL (at least in part because of the indemnisation clause). Therefore, many networks that do RPKI validation do validate prefixes from the other 4 RIRs but not mine. In simple words : why bother validating, if all of most of the networks that could block invalid prefixes don't, because the TAL agreement is not palatable. I understand that ARIN has to deal with a legal system that makes things difficult, but OTOH I would like ARIN's RPKI validation to provide the same protection than the other RIRs, which it currently does not. I created my ROAs, but I am not protected as well as an Org belonging to another RIR. 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 quan at posteo.net Fri Aug 16 02:53:46 2019 From: quan at posteo.net (Quan Zhou) Date: Fri, 16 Aug 2019 10:53:46 +0800 Subject: ARIN Fantasy WHOIS: NET-216-179-183-0-1 In-Reply-To: <55755.1565844029@segfault.tristatelogic.com> References: <55755.1565844029@segfault.tristatelogic.com> Message-ID: I wonder whom did the ARIN have sent bills to. On 8/15/19 12:40 PM, Ronald F. Guilmette wrote: > As if to underscore the point I just tried to make about the fundamental > unreliability of ARIN WHOIS records, I just stumbled onto this rather > curious entity which was apparently given a sub-allocation of 216.179.183.0/24 > beneath the 216.179.128.0/17 (Azuki, Inc.) block as of 2012-01-10: > > OrgName: Rogers Communications Inc > OrgId: RC-82 > Address: E 2nd St,Campbell > City: Gillette > StateProv: WY > PostalCode: 82716 > Country: US > RegDate: 2012-01-10 > Updated: 2012-01-10 > Ref: https://rdap.arin.net/registry/entity/RC-82 > > Other that the fact that it has an oddly similar name to one of Canada's > largest and most well-known Internet and cell phone companies, the only > other thing that's rather remarkable about it is that it was given the > 216.179.183.0/24 block, by Azuki, Inc. in 2012. What's odd about that? > Well, only the fact that this *Wyoming* incarnation of Rogers Communications > had apparently already died and gone to Valhalla some 14 years earlier, > in 1998: > > https://wyobiz.wy.gov/Business/FilingDetails.aspx?eFNum=070023242004106130056183154143023082073130141117 > > Moral of the story: Don't ever let anybody tell you that ghosts... even > ghosts of long dead companies... aren't real or that they do not walk > among us. Their immortal auras pervade the very ether we breath. > > And they have their own IPs, apparently. > > But, you know, if your customers are getting hack attacks emmanating from > 216.179.183.0/24... well... to quote the old Ghostbusters tag line "Who > you gonna call?" (Hint: Don't waste your time calling the number in the > WHOIS record. It's just some bloody preschool.) > > Regards, > rfg -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1753 bytes Desc: not available URL: From morrowc.lists at gmail.com Fri Aug 16 03:38:37 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 15 Aug 2019 23:38:37 -0400 Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17 In-Reply-To: References: <55364.1565838984@segfault.tristatelogic.com> Message-ID: (I hate to step into the pond, but...) On Thu, Aug 15, 2019 at 8:02 AM John Curran wrote: > > On 14 Aug 2019, at 11:16 PM, Ronald F. Guilmette wrote: > > > > Report it on some webpage and call it "Internet > Resources stolen", document every incident as you do via email, send a > copy to the appropriate RIR and upstream ISP allowing the hijack in > question to show that you did the appropriate effort and we can then > move on. > > > I can and will stop posting here, and go off an blog about this stuff > instead, if the consensus is that I'm utterly off-topic or utterly > uninteresting and useless. But a few folks have told me they find > this stuff interesting, and it has operational significance, I think. > So for now, at least, I'd like to continue to share here. > > As regards to reporting to RIRs or upstreams, what makes you think that > either of those would care one wit? The RIRs are not the Internet > Police, or so I am told. > > > Good morning Ron – > > The RIRs are not the Internet Police, but we do care very much about the integrity of the Internet number registry system. > > Please report to ARIN any instances of number resource records in the ARIN registry whose organization you believe to be incorrect – while such records are updated only based on appropriate documentation, that doesn’t preclude the use of fraudulent documentation that goes undetected. There seem to be 2 different (at least) classes of thing Ron's noting here: 1) an aggregate (an ALLOCATION in RIR resource divying-up parlance) with (perhaps) bad data showing in WHOIS: 216.179.128.0/17 2) a subnet (an ASSIGNMENT in IR resource divying-up parlance) with bad data showing in WHOIS: 216.179.183.0/24 How data gets into the WHOIS system here is mechanically the same, but the control ARIN (or any RIR) can exert is drastically different. During the process of ALLOCATION from the RIR to an LIR (or end-site) there is some process which includes validating "who" and "where" and such, which John (and a few others) have outlined. During the ASSIGNMENT from LIR -> customer / end-site the LIR is solely (well.. mostly, yes the LIR can create and ORG and permit the Customer the ability to send SWIP updates....) in control of what data ends up in the WHOIS. ARIN (for example) has no real say in the records for ASSIGNMENTS. They could, I suppose, do something ... but that seems a lot like drinking from a firehose without any real ability on the part of ARIN (for instance) to validate anything in the inbound data :( -chris From tj at pcguys.us Fri Aug 16 05:28:34 2019 From: tj at pcguys.us (TJ Trout) Date: Thu, 15 Aug 2019 22:28:34 -0700 Subject: ARIN Fantasy WHOIS: NET-216-179-183-0-1 In-Reply-To: References: <55755.1565844029@segfault.tristatelogic.com> Message-ID: If it's legacy, there are no bills? On Thu, Aug 15, 2019 at 7:54 PM Quan Zhou wrote: > I wonder whom did the ARIN have sent bills to. > > On 8/15/19 12:40 PM, Ronald F. Guilmette wrote: > > As if to underscore the point I just tried to make about the fundamental > > unreliability of ARIN WHOIS records, I just stumbled onto this rather > > curious entity which was apparently given a sub-allocation of > 216.179.183.0/24 > > beneath the 216.179.128.0/17 (Azuki, Inc.) block as of 2012-01-10: > > > > OrgName: Rogers Communications Inc > > OrgId: RC-82 > > Address: E 2nd St,Campbell > > City: Gillette > > StateProv: WY > > PostalCode: 82716 > > Country: US > > RegDate: 2012-01-10 > > Updated: 2012-01-10 > > Ref: https://rdap.arin.net/registry/entity/RC-82 > > > > Other that the fact that it has an oddly similar name to one of Canada's > > largest and most well-known Internet and cell phone companies, the only > > other thing that's rather remarkable about it is that it was given the > > 216.179.183.0/24 block, by Azuki, Inc. in 2012. What's odd about that? > > Well, only the fact that this *Wyoming* incarnation of Rogers > Communications > > had apparently already died and gone to Valhalla some 14 years earlier, > > in 1998: > > > > > https://wyobiz.wy.gov/Business/FilingDetails.aspx?eFNum=070023242004106130056183154143023082073130141117 > > > > Moral of the story: Don't ever let anybody tell you that ghosts... even > > ghosts of long dead companies... aren't real or that they do not walk > > among us. Their immortal auras pervade the very ether we breath. > > > > And they have their own IPs, apparently. > > > > But, you know, if your customers are getting hack attacks emmanating from > > 216.179.183.0/24... well... to quote the old Ghostbusters tag line "Who > > you gonna call?" (Hint: Don't waste your time calling the number in the > > WHOIS record. It's just some bloody preschool.) > > > > Regards, > > rfg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Fri Aug 16 09:02:41 2019 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 16 Aug 2019 11:02:41 +0200 Subject: =?UTF-8?Q?Re=3a_new_BGP_hijack_=26_visibility_tool_=e2=80=9cBGPaler?= =?UTF-8?B?dGVy4oCd?= In-Reply-To: References: <9088ffb4-eb3b-ebf2-00aa-a12b6d0e1686@swordarmor.fr> <20190815151013.GZ4901@hanna.meerval.net> Message-ID: <5ec6a69e-96f4-d0f8-dc22-976d881e5778@ripe.net> Hi, On 2019-08-15 17:38, Christopher Morrow wrote: > This looks like fun! > (a few questions for the RIPE folk, I think though below) > > What is the expected load of streaming clients on the RIPE service? (I > wonder because I was/am messing about with something similar, though > less node and js... not that that's relevant here). One of the (IMO) most useful features is that you can filter what you want to receive. In fact this makes the service useful :-) So unless you want to tune in to a significant portion of BGP chatter, the load should not be substantial. > I hadn't seen the ripe folk pipe up anywhere with what their SLO/etc > is for the ris-live service? (except their quip about: "used to run in > a tmux session I had to occassioanlly ssh into and restart when > rebooted" I believe the end of that quip in Iceland was: "and > now its' running as a real service") It's in between those. We now have a conscious setup which should also be able to scale up, but bits and pieces (like full monitoring of the service) are still being developed. > Also, one of the strengths to the 'monitoring as a service' folks is > their number of collection points and breadth of ASN to which they > interconnect those points/ RISLive, I think, reports out from ~37 or > so RIPE probes, how do we (the internet) get more deployed (or better > interconnection to the current sets)? and maybe even more > imoprtantly... what's the right spread/location/interconnectivity map > for these probes? RIS Live provides data from RIS, which has a bunch of collectors around the world (see https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/ris-peering-policy) with many hundreds of peering sessions. But it is by no means complete in terms of coverage. If and how the community (NANOG or RIPE or else) should work on optimal data collection is indeed a useful discussion to have. Cheers, Robert > thanks! for showing what's possible with tooling being developed by > like minded individuals :) > > -chris From valdis.kletnieks at vt.edu Fri Aug 16 12:13:57 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Fri, 16 Aug 2019 08:13:57 -0400 Subject: new BGP hijack & visibility tool “BGPalerter” In-Reply-To: <5ec6a69e-96f4-d0f8-dc22-976d881e5778@ripe.net> References: <9088ffb4-eb3b-ebf2-00aa-a12b6d0e1686@swordarmor.fr> <20190815151013.GZ4901@hanna.meerval.net> <5ec6a69e-96f4-d0f8-dc22-976d881e5778@ripe.net> Message-ID: <386763.1565957637@turing-police> On Fri, 16 Aug 2019 11:02:41 +0200, Robert Kisteleki said: > Hi, > > On 2019-08-15 17:38, Christopher Morrow wrote: > > This looks like fun! > > (a few questions for the RIPE folk, I think though below) > > > > What is the expected load of streaming clients on the RIPE service? (I > > wonder because I was/am messing about with something similar, though > > less node and js... not that that's relevant here). > > One of the (IMO) most useful features is that you can filter what you > want to receive. In fact this makes the service useful :-) So unless you > want to tune in to a significant portion of BGP chatter, the load should > not be substantial. I think Chris's question is more "Is RIPE going to be OK if a lot of people ask for the extra-chatty feed?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From robert at ripe.net Fri Aug 16 12:36:27 2019 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 16 Aug 2019 14:36:27 +0200 Subject: =?UTF-8?Q?Re=3a_new_BGP_hijack_=26_visibility_tool_=e2=80=9cBGPaler?= =?UTF-8?B?dGVy4oCd?= In-Reply-To: <386763.1565957637@turing-police> References: <9088ffb4-eb3b-ebf2-00aa-a12b6d0e1686@swordarmor.fr> <20190815151013.GZ4901@hanna.meerval.net> <5ec6a69e-96f4-d0f8-dc22-976d881e5778@ripe.net> <386763.1565957637@turing-police> Message-ID: <7bb608a2-3a79-401b-5331-a7b6aff4c95b@ripe.net> On 2019-08-16 14:13, Valdis Klētnieks wrote: > On Fri, 16 Aug 2019 11:02:41 +0200, Robert Kisteleki said: >> Hi, >> >> On 2019-08-15 17:38, Christopher Morrow wrote: >>> This looks like fun! >>> (a few questions for the RIPE folk, I think though below) >>> >>> What is the expected load of streaming clients on the RIPE service? (I >>> wonder because I was/am messing about with something similar, though >>> less node and js... not that that's relevant here). >> >> One of the (IMO) most useful features is that you can filter what you >> want to receive. In fact this makes the service useful :-) So unless you >> want to tune in to a significant portion of BGP chatter, the load should >> not be substantial. > > I think Chris's question is more "Is RIPE going to be OK if a lot of people ask > for the extra-chatty feed?" Yes, good point. Of course it could be a problem if too many clients ask for too much data like a full feed... we're not prepared to provide that on a large scale. For the moment we're looking at the effects of what people need and if we can handle it with what we have built. Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 528 bytes Desc: OpenPGP digital signature URL: From mysidia at gmail.com Fri Aug 16 13:30:09 2019 From: mysidia at gmail.com (Sid) Date: Fri, 16 Aug 2019 08:30:09 -0500 Subject: User Unknown (WAS: really amazon?) In-Reply-To: <97FAF157-BC0E-41C9-8E16-B852F05967D7@isc.org> 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> <97FAF157-BC0E-41C9-8E16-B852F05967D7@isc.org> Message-ID: On Wed, Jul 31, 2019 at 5:29 PM Mark Andrews wrote: > 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 It simplifies complaint language/interaction if there is an actual official RIR policy being violated. If the abuse POC bounces, then you can contact the Admin and Technical WHOIS e-mail addresses to tell them about the issue, and why they should care. "You should care, because your non-functioning abuse is a violation of ARIN Registry Policy." If none of the WHOIS e-mail works, then try calling to report the issue as a last resort. Finally, if none of those go directly to a working contact.... then it seems like the only option left is blacklisting. And seems like the RIRs ought to have a policy where when they confirm this; financial sanctions as in penalty fines would be in order to retain those for whatever organization not taking any of their IP Address Registration and availability of contacts seriously. > thing is what should the grace period be? -- -Sid From morrowc.lists at gmail.com Fri Aug 16 14:45:23 2019 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 16 Aug 2019 10:45:23 -0400 Subject: =?UTF-8?Q?Re=3A_new_BGP_hijack_=26_visibility_tool_=E2=80=9CBGPalerter?= =?UTF-8?Q?=E2=80=9D?= In-Reply-To: <5ec6a69e-96f4-d0f8-dc22-976d881e5778@ripe.net> References: <9088ffb4-eb3b-ebf2-00aa-a12b6d0e1686@swordarmor.fr> <20190815151013.GZ4901@hanna.meerval.net> <5ec6a69e-96f4-d0f8-dc22-976d881e5778@ripe.net> Message-ID: On Fri, Aug 16, 2019 at 5:02 AM Robert Kisteleki wrote: > > Hi, > > On 2019-08-15 17:38, Christopher Morrow wrote: > > This looks like fun! > > (a few questions for the RIPE folk, I think though below) > > > > What is the expected load of streaming clients on the RIPE service? (I > > wonder because I was/am messing about with something similar, though > > less node and js... not that that's relevant here). > > One of the (IMO) most useful features is that you can filter what you > want to receive. In fact this makes the service useful :-) So unless you > want to tune in to a significant portion of BGP chatter, the load should > not be substantial. yup, I can see a usecase clearly for: "This is my prefix set, and my transit-as-set, tell me when there are deviations" (which is probably 2 different connections with 2 different filters to the not-fire-hose feed - oh the docs say you can provide more than one filter, ok... cool) The firehose is perhaps more friendly for folk like an ISP that could offer some form of monitoring for their customer's prefixes? It's also useful (to me anyway) to tell me: "I see prefix-A picked up a new Origin? odd?" or "Wow, someone 7007'd themselves!" which isn't clearly (to me anyway) simple to do in the 'not firehose' version of the stream/service... The firehose also looks like a great feed to add to my other internal route monitoring things: 1) get bgp data from my firewall's upstream devices 2) get bgp from my internal network 3) eat bmp from my PE/CE device set 4) add rislive-firehose 5) add routeviews/ris update data when available (poll each 15m min, process mrt && ingest data) determine what patterns/filters/thigns I want to monitor: "did prefixX just change upstream ASN and I should bias traffic differently toward that prefix?" etc... > > I hadn't seen the ripe folk pipe up anywhere with what their SLO/etc > > is for the ris-live service? (except their quip about: "used to run in > > a tmux session I had to occassioanlly ssh into and restart when > > rebooted" I believe the end of that quip in Iceland was: "and > > now its' running as a real service") > > It's in between those. We now have a conscious setup which should also > be able to scale up, but bits and pieces (like full monitoring of the > service) are still being developed. > ok cool! as with my question to John Curran about ARIN service SLOs I'm really asking: "Hey, if I inputting this data into my business process I want to know what to expect from a performance/scalability/outage/reliability perspective" if that's not written down and published then some folks MAY chose to believe: "Well, it's available now, and now and now.. so 'always, 100%!!' seems sane!" or others may choose to believe; "Well, nice toy you have there... let me know when it's ready for me to ingest into my production monitoring/etc systems" > > Also, one of the strengths to the 'monitoring as a service' folks is > > their number of collection points and breadth of ASN to which they > > interconnect those points/ RISLive, I think, reports out from ~37 or > > so RIPE probes, how do we (the internet) get more deployed (or better > > interconnection to the current sets)? and maybe even more > > imoprtantly... what's the right spread/location/interconnectivity map > > for these probes? > > RIS Live provides data from RIS, which has a bunch of collectors around > the world (see > https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/ris-peering-policy) > with many hundreds of peering sessions. But it is by no means complete > in terms of coverage. > > If and how the community (NANOG or RIPE or else) should work on optimal > data collection is indeed a useful discussion to have. > ok, cool! :) > Cheers, > Robert > > > thanks! for showing what's possible with tooling being developed by > > like minded individuals :) > > > > -chris > From nanog at shankland.org Fri Aug 16 22:04:39 2019 From: nanog at shankland.org (Jim Shankland) Date: Fri, 16 Aug 2019 15:04:39 -0700 Subject: syn flood attacks from NL-based netblocks Message-ID: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Greetings, I'm seeing slow-motion (a few per second, per IP/port pair) syn flood attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18 , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood, and BCP 38 not yet fully adopted). Why is this syn flood different from all other syn floods? Well ... 1. Rate seems too slow to do any actual damage (is anybody really bothered by a few bad SYN packets per second per service, at this point?); but 2. IPs/port combinations with actual open services are being targeted (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs with those services running), implying somebody checked for open services first; 3. I'm seeing this in at least 2 locations, to addresses in different, completely unrelated ASes, implying it may be pretty widespread. Is anybody else seeing the same thing? Any thoughts on what's going on? Or should I just be ignoring this and getting on with the weekend? Jim From bruce.curtis at ndsu.edu Fri Aug 16 22:18:28 2019 From: bruce.curtis at ndsu.edu (Curtis, Bruce) Date: Fri, 16 Aug 2019 22:18:28 +0000 Subject: syn flood attacks from NL-based netblocks In-Reply-To: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: <61068738-6A81-410A-ABEC-C2BFC9D7BA2B@ndus.edu> On Aug 16, 2019, at 5:04 PM, Jim Shankland > wrote: Greetings, I'm seeing slow-motion (a few per second, per IP/port pair) syn flood attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18 , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood, and BCP 38 not yet fully adopted). Why is this syn flood different from all other syn floods? Well ... 1. Rate seems too slow to do any actual damage (is anybody really bothered by a few bad SYN packets per second per service, at this point?); but 2. IPs/port combinations with actual open services are being targeted (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs with those services running), implying somebody checked for open services first; 3. I'm seeing this in at least 2 locations, to addresses in different, completely unrelated ASes, implying it may be pretty widespread. Is anybody else seeing the same thing? Any thoughts on what's going on? Or should I just be ignoring this and getting on with the weekend? Jim We are seeing that here also. Saw similar traffic ostensibly originating from NL at least as long ago as last Sunday August 17. — Bruce Curtis bruce.curtis at ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at netfire.net Fri Aug 16 22:20:09 2019 From: matt at netfire.net (Matt Harris) Date: Fri, 16 Aug 2019 17:20:09 -0500 Subject: syn flood attacks from NL-based netblocks In-Reply-To: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: On Fri, Aug 16, 2019 at 5:05 PM Jim Shankland wrote: > 1. Rate seems too slow to do any actual damage (is anybody really > bothered by a few bad SYN packets per second per service, at this > point?); but > Common technique used by port scanners to evade detection as a DoS attack by fw/ids/etc. 2. IPs/port combinations with actual open services are being targeted > (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs > with those services running), implying somebody checked for open > services first; > Or they're just checking if certain common ports are open with the intention of later trying known exploits against those which are reachable in order to attempt to compromise the hosts. Build the DB of reachable hosts/ports now, come back with exploits later. 3. I'm seeing this in at least 2 locations, to addresses in different, > completely unrelated ASes, implying it may be pretty widespread. > Sounds like a relatively common pattern though. Is anybody else seeing the same thing? Any thoughts on what's going on? > Or should I just be ignoring this and getting on with the weekend? > I wouldn't worry too much about it unless you have reason to believe some of the likely-forthcoming exploits may actually work. Of course, if that's the case, you should fix them anyhow. Have a good weekend! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jms at vols.utk.edu Fri Aug 16 22:26:46 2019 From: jms at vols.utk.edu (Jared Smith) Date: Fri, 16 Aug 2019 18:26:46 -0400 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: <55182e6b-27d4-4b0a-959c-17362420faf1@Spark> I would think Shodan/Zmap/pick your multi-IP-block-scanning-tool would portray similar behavior. Echoing Matt’s “probably shouldn’t worry” sentiment, this could just be someone running an incantation of such tools for research or recreational purposes. Best, Jared On Aug 16, 2019, 18:21 -0400, Matt Harris , wrote: > On Fri, Aug 16, 2019 at 5:05 PM Jim Shankland wrote: > > > 1. Rate seems too slow to do any actual damage (is anybody really > > > bothered by a few bad SYN packets per second per service, at this > > > point?); but > > > > Common technique used by port scanners to evade detection as a DoS attack by fw/ids/etc. > > > > > 2. IPs/port combinations with actual open services are being targeted > > > (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs > > > with those services running), implying somebody checked for open > > > services first; > > > > Or they're just checking if certain common ports are open with the intention of later trying known exploits against those which are reachable in order to attempt to compromise the hosts. Build the DB of reachable hosts/ports now, come back with exploits later. > > > > > 3. I'm seeing this in at least 2 locations, to addresses in different, > > > completely unrelated ASes, implying it may be pretty widespread. > > > > Sounds like a relatively common pattern though. > > > > > Is anybody else seeing the same thing? Any thoughts on what's going on? > > > Or should I just be ignoring this and getting on with the weekend? > > > > I wouldn't worry too much about it unless you have reason to believe some of the likely-forthcoming exploits may actually work. Of course, if that's the case, you should fix them anyhow. > > > > Have a good weekend! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From troy at wolvtech.com Fri Aug 16 22:48:49 2019 From: troy at wolvtech.com (Troy Mursch) Date: Fri, 16 Aug 2019 15:48:49 -0700 Subject: syn flood attacks from NL-based netblocks In-Reply-To: <55182e6b-27d4-4b0a-959c-17362420faf1@Spark> References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> <55182e6b-27d4-4b0a-959c-17362420faf1@Spark> Message-ID: The traffic "from" 88.208.0.0/18, 5.11.80.0/21, and 78.140.128.0/18 doesn't match the packet signatures for Masscan, ZMap, or any other well-known scanner. The traffic is likely spoofed. __ *Troy Mursch* @bad_packets On Fri, Aug 16, 2019 at 3:28 PM Jared Smith wrote: > I would think Shodan/Zmap/pick your multi-IP-block-scanning-tool would > portray similar behavior. > > Echoing Matt’s “probably shouldn’t worry” sentiment, this could just be > someone running an incantation of such tools for research or recreational > purposes. > > Best, > Jared > On Aug 16, 2019, 18:21 -0400, Matt Harris , wrote: > > On Fri, Aug 16, 2019 at 5:05 PM Jim Shankland wrote: > > 1. Rate seems too slow to do any actual damage (is anybody really > bothered by a few bad SYN packets per second per service, at this > point?); but > > > Common technique used by port scanners to evade detection as a DoS attack > by fw/ids/etc. > > 2. IPs/port combinations with actual open services are being targeted > (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs > with those services running), implying somebody checked for open > services first; > > > Or they're just checking if certain common ports are open with the > intention of later trying known exploits against those which are reachable > in order to attempt to compromise the hosts. Build the DB of reachable > hosts/ports now, come back with exploits later. > > 3. I'm seeing this in at least 2 locations, to addresses in different, > completely unrelated ASes, implying it may be pretty widespread. > > > Sounds like a relatively common pattern though. > > Is anybody else seeing the same thing? Any thoughts on what's going on? > Or should I just be ignoring this and getting on with the weekend? > > > I wouldn't worry too much about it unless you have reason to believe some > of the likely-forthcoming exploits may actually work. Of course, if that's > the case, you should fix them anyhow. > > Have a good weekend! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emille at abccommunications.com Fri Aug 16 22:50:17 2019 From: emille at abccommunications.com (Emille Blanc) Date: Fri, 16 Aug 2019 22:50:17 +0000 Subject: syn flood attacks from NL-based netblocks In-Reply-To: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: <2e0954103f094a8b8d816caf8d82df35@EX2K13.ad.abccommunications.com> Have been seeing these at $DAYJOB off and on for the past week. First logged events began for on 2019-08-04, at approx 1500hrs PST. Impact for us has been negligible, but some older ASA's were having trouble with the scan volume and their configured log levels which has since been remedied. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jim Shankland Sent: Friday, August 16, 2019 3:05 PM To: nanog at nanog.org Subject: syn flood attacks from NL-based netblocks Greetings, I'm seeing slow-motion (a few per second, per IP/port pair) syn flood attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18 , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood, and BCP 38 not yet fully adopted). Why is this syn flood different from all other syn floods? Well ... 1. Rate seems too slow to do any actual damage (is anybody really bothered by a few bad SYN packets per second per service, at this point?); but 2. IPs/port combinations with actual open services are being targeted (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs with those services running), implying somebody checked for open services first; 3. I'm seeing this in at least 2 locations, to addresses in different, completely unrelated ASes, implying it may be pretty widespread. Is anybody else seeing the same thing? Any thoughts on what's going on? Or should I just be ignoring this and getting on with the weekend? Jim From nanog at shankland.org Sat Aug 17 01:58:24 2019 From: nanog at shankland.org (Jim Shankland) Date: Fri, 16 Aug 2019 18:58:24 -0700 Subject: syn flood attacks from NL-based netblocks In-Reply-To: <2e0954103f094a8b8d816caf8d82df35@EX2K13.ad.abccommunications.com> References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> <2e0954103f094a8b8d816caf8d82df35@EX2K13.ad.abccommunications.com> Message-ID: <08a64f4c-8471-3e38-5a09-6ff726c1ca83@shankland.org> On 8/16/19 3:50 PM, Emille Blanc wrote: > Have been seeing these at $DAYJOB off and on for the past week. > First logged events began for on 2019-08-04, at approx 1500hrs PST. > > Impact for us has been negligible, but some older ASA's were having trouble with the scan volume and their configured log levels which has since been remedied. Thanks for the various responses. The pattern I (and apparently quite a few others) are seeing differs from an ordinary probe in that it is repeated a few times per second (if somebody wants to know who has a visible ssh server on port 22, and what version of sshd is running, they don't have to hit it multiple times per second). It differs from a SYN flood DoS attack in that its rate is too low to be effective. And it differs from both a port probe and a SYN flood attack (or somebody "learning how to use nmap") in that it is targeting a broad set of destinations in parallel; if source addresses are forged, they are from a fairly narrow set of source IPs. The atypical pattern seems noteworthy in itself. Not a crisis, but not quite routine, either. Jim From ximaera at gmail.com Sat Aug 17 07:14:57 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Sat, 17 Aug 2019 10:14:57 +0300 Subject: syn flood attacks from NL-based netblocks In-Reply-To: <08a64f4c-8471-3e38-5a09-6ff726c1ca83@shankland.org> References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> <2e0954103f094a8b8d816caf8d82df35@EX2K13.ad.abccommunications.com> <08a64f4c-8471-3e38-5a09-6ff726c1ca83@shankland.org> Message-ID: On Sat, Aug 17, 2019, 4:59 AM Jim Shankland wrote: > On 8/16/19 3:50 PM, Emille Blanc wrote: > Thanks for the various responses. The pattern I (and apparently quite a > few others) are seeing differs from an ordinary probe in that it is > repeated a few times per second (if somebody wants to know who has a > visible ssh server on port 22, and what version of sshd is running, they > don't have to hit it multiple times per second). It differs from a SYN > flood DoS attack in that its rate is too low to be effective. And it > differs from both a port probe and a SYN flood attack (or somebody > "learning how to use nmap") in that it is targeting a broad set of > destinations in parallel > Seen a similar pattern a few years ago. Discovered it's a couple of students basically developing mass scanning software for a bachelor's degree who forgot to turn the running code off production before the summer break. That's the white noise of the Internet. Unless it's hitting you multiple thousand times/s as opposed to multiple times/s, it's only a matter of unpaid curiosity to start figuring out the reason. I guess Amazon or microsoft dot com have quite a museum of that staff. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian at google.com Sat Aug 17 22:16:33 2019 From: damian at google.com (Damian Menscher) Date: Sat, 17 Aug 2019 15:16:33 -0700 Subject: syn flood attacks from NL-based netblocks In-Reply-To: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: On Fri, Aug 16, 2019 at 3:05 PM Jim Shankland wrote: > I'm seeing slow-motion (a few per second, per IP/port pair) syn flood > attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18 > , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood, > and BCP 38 not yet fully adopted). > > Is anybody else seeing the same thing? Any thoughts on what's going on? > Or should I just be ignoring this and getting on with the weekend? > This appears to be a TCP amplification attack. Similar to UDP amplification (DNS, NTP, etc) you can get some amplification by sending a SYN packet with a spoofed source, and watching your victims receive multiple SYN-ACK retries. It's a fairly weak form of attack (as the amplification factor is small), but if the victim's gear is vulnerable to high packet rates it may be effective. The victim (or law enforcement) could identify the true source of the attack by asking transit providers to check their netflow to see where it enters their networks. Damian -------------- next part -------------- An HTML attachment was scrubbed... URL: From amir.lists at gmail.com Sat Aug 17 22:35:55 2019 From: amir.lists at gmail.com (Amir Herzberg) Date: Sat, 17 Aug 2019 18:35:55 -0400 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: Hmm, I doubt this is the output of TCP amplification since Jim reported it as SYN spoofing, i.e., SYN packets, not SYN-ACK packets (as for typical TCP amplification). Unless the given _hosts_ respond with multiple SYN-ACKs in which case these may be experiments by an attacker to measure if these IP:ports could be abused as TCP amplifiers. But, at least if these IP:ports do not amplify, I suspect it's more likely that, as Töma wrote, this is simply result of some learning-experiment by students (or by wanna-be hackers). Yes, such (unethical, unprofessional) experimentation happens, and can be easily confused with some clever new attack... which is a pity since we always like to learn of new attacks! Of course one (i.e., Jim) could try to trace back and find the source (likely spoofer) but it seems quite likely to be some students or script kiddies, which may be underwhelming... -- Amir On Sat, Aug 17, 2019 at 6:18 PM Damian Menscher via NANOG wrote: > On Fri, Aug 16, 2019 at 3:05 PM Jim Shankland wrote: > >> I'm seeing slow-motion (a few per second, per IP/port pair) syn flood >> attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18 >> , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood, >> and BCP 38 not yet fully adopted). >> >> Is anybody else seeing the same thing? Any thoughts on what's going on? >> Or should I just be ignoring this and getting on with the weekend? >> > > This appears to be a TCP amplification attack. Similar to UDP > amplification (DNS, NTP, etc) you can get some amplification by sending a > SYN packet with a spoofed source, and watching your victims receive > multiple SYN-ACK retries. It's a fairly weak form of attack (as the > amplification factor is small), but if the victim's gear is vulnerable to > high packet rates it may be effective. > > The victim (or law enforcement) could identify the true source of the > attack by asking transit providers to check their netflow to see where it > enters their networks. > > Damian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian at google.com Sat Aug 17 22:56:19 2019 From: damian at google.com (Damian Menscher) Date: Sat, 17 Aug 2019 15:56:19 -0700 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: On Sat, Aug 17, 2019 at 3:36 PM Amir Herzberg wrote: > Hmm, I doubt this is the output of TCP amplification since Jim reported it > as SYN spoofing, i.e., SYN packets, not SYN-ACK packets (as for typical TCP > amplification). Unless the given _hosts_ respond with multiple SYN-ACKs in > which case these may be experiments by an attacker to measure if these > IP:ports could be abused as TCP amplifiers. > Clarifying for those unfamiliar with this attack: - Attacker is sending SYN packets spoofed "from" NL to Jim (and others) - Jim (and others) have applications listening on those ports and respond with SYN-ACK packets to the victim in NL - When the victim (NL) fails to complete the handshake (which they didn't initiate!) Jim (and others) sends another SYN-ACK So they're not probing to see if Jim (and others) are abusable as TCP amplifiers... they've already determined they can be abused and are using those machines to conduct an actual attack against victims in NL. Damian On Sat, Aug 17, 2019 at 6:18 PM Damian Menscher via NANOG > wrote: > >> On Fri, Aug 16, 2019 at 3:05 PM Jim Shankland >> wrote: >> >>> I'm seeing slow-motion (a few per second, per IP/port pair) syn flood >>> attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18 >>> , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn >>> flood, >>> and BCP 38 not yet fully adopted). >>> >>> Is anybody else seeing the same thing? Any thoughts on what's going on? >>> Or should I just be ignoring this and getting on with the weekend? >>> >> >> This appears to be a TCP amplification attack. Similar to UDP >> amplification (DNS, NTP, etc) you can get some amplification by sending a >> SYN packet with a spoofed source, and watching your victims receive >> multiple SYN-ACK retries. It's a fairly weak form of attack (as the >> amplification factor is small), but if the victim's gear is vulnerable to >> high packet rates it may be effective. >> >> The victim (or law enforcement) could identify the true source of the >> attack by asking transit providers to check their netflow to see where it >> enters their networks. >> >> Damian >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amir.lists at gmail.com Sat Aug 17 23:02:38 2019 From: amir.lists at gmail.com (Amir Herzberg) Date: Sat, 17 Aug 2019 19:02:38 -0400 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: Damian, sure, that's what I meant - it's possible, but only _if_ Jim's machines actually respond with multiple SYN-ACK packets. Which I _think_ Jim probably would have noticed. Or maybe not ? btw, some TCP amplifications can be quite severe, if anyone wants I can send the citation to a nice paper exploring this issue. BR... -- Amir Herzberg Comcast professor for security innovation Dept. of Computer Science and Engineering, University of Connecticut On Sat, Aug 17, 2019 at 6:56 PM Damian Menscher wrote: > On Sat, Aug 17, 2019 at 3:36 PM Amir Herzberg > wrote: > >> Hmm, I doubt this is the output of TCP amplification since Jim reported >> it as SYN spoofing, i.e., SYN packets, not SYN-ACK packets (as for typical >> TCP amplification). Unless the given _hosts_ respond with multiple SYN-ACKs >> in which case these may be experiments by an attacker to measure if these >> IP:ports could be abused as TCP amplifiers. >> > > Clarifying for those unfamiliar with this attack: > - Attacker is sending SYN packets spoofed "from" NL to Jim (and others) > - Jim (and others) have applications listening on those ports and > respond with SYN-ACK packets to the victim in NL > - When the victim (NL) fails to complete the handshake (which they > didn't initiate!) Jim (and others) sends another SYN-ACK > > So they're not probing to see if Jim (and others) are abusable as TCP > amplifiers... they've already determined they can be abused and are using > those machines to conduct an actual attack against victims in NL. > > Damian > > On Sat, Aug 17, 2019 at 6:18 PM Damian Menscher via NANOG >> wrote: >> >>> On Fri, Aug 16, 2019 at 3:05 PM Jim Shankland >>> wrote: >>> >>>> I'm seeing slow-motion (a few per second, per IP/port pair) syn flood >>>> attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18 >>>> , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn >>>> flood, >>>> and BCP 38 not yet fully adopted). >>>> >>>> Is anybody else seeing the same thing? Any thoughts on what's going on? >>>> Or should I just be ignoring this and getting on with the weekend? >>>> >>> >>> This appears to be a TCP amplification attack. Similar to UDP >>> amplification (DNS, NTP, etc) you can get some amplification by sending a >>> SYN packet with a spoofed source, and watching your victims receive >>> multiple SYN-ACK retries. It's a fairly weak form of attack (as the >>> amplification factor is small), but if the victim's gear is vulnerable to >>> high packet rates it may be effective. >>> >>> The victim (or law enforcement) could identify the true source of the >>> attack by asking transit providers to check their netflow to see where it >>> enters their networks. >>> >>> Damian >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nanog at shankland.org Sun Aug 18 02:57:10 2019 From: nanog at shankland.org (Jim Shankland) Date: Sat, 17 Aug 2019 19:57:10 -0700 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: <2725314a-58c4-b1c5-83d5-3db972e9346d@shankland.org> On 8/17/19 3:16 PM, Damian Menscher wrote: > On Fri, Aug 16, 2019 at 3:05 PM Jim Shankland > wrote: > > I'm seeing slow-motion (a few per second, per IP/port pair) syn flood > attacks ostensibly originating from 3 NL-based IP blocks: > 88.208.0.0/18 > , 5.11.80.0/21 , and 78.140.128.0/18 > ("ostensibly" because ... syn flood, > and BCP 38 not yet fully adopted). > > Is anybody else seeing the same thing? Any thoughts on what's > going on? > Or should I just be ignoring this and getting on with the weekend? > > > This appears to be a TCP amplification attack.  Similar to UDP > amplification (DNS, NTP, etc) you can get some amplification by > sending a SYN packet with a spoofed source, and watching your victims > receive multiple SYN-ACK retries. It's a fairly weak form of attack > (as the amplification factor is small), but if the victim's gear is > vulnerable to high packet rates it may be effective. > That thought crossed my mind, but it seems to me that the weak amplification factor, plus the broadly distributed set of forged source addresses (within the blocks cited above), would make the attack ineffective -- the whole point of DDoS being to focus a broadly distributed set of (illegitimately obtained) source resources on a narrow set of destination targets. Attacking 2 /18 blocks plus a /21 block in parallel with a weak-amplification attack doesn't look like a successful DDoS strategy to me. Jim > The victim (or law enforcement) could identify the true source of the > attack by asking transit providers to check their netflow to see where > it enters their networks. > > Damian -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike-nanog at tiedyenetworks.com Sun Aug 18 03:01:30 2019 From: mike-nanog at tiedyenetworks.com (Mike) Date: Sat, 17 Aug 2019 20:01:30 -0700 Subject: syn flood attacks from NL-based netblocks In-Reply-To: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: On 8/16/19 3:04 PM, Jim Shankland wrote: > Greetings, > > I'm seeing slow-motion (a few per second, per IP/port pair) syn flood > attacks ostensibly originating from 3 NL-based IP blocks: > 88.208.0.0/18 , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" > because ... syn flood, and BCP 38 not yet fully adopted). > > Why is this syn flood different from all other syn floods? Well ... > > 1. Rate seems too slow to do any actual damage (is anybody really > bothered by a few bad SYN packets per second per service, at this > point?); but > > 2. IPs/port combinations with actual open services are being targeted > (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs > with those services running), implying somebody checked for open > services first; > > 3. I'm seeing this in at least 2 locations, to addresses in different, > completely unrelated ASes, implying it may be pretty widespread. > > Is anybody else seeing the same thing? Any thoughts on what's going > on? Or should I just be ignoring this and getting on with the weekend? > > Jim > > > > I am seeing this against my recursive revolvers - one syn in, and many syn-ack's back with no connection obviously. Low rate to be sure, but what was surprising to me was that my revolvers (PowerDNS) definitely have an allowed-networks ACL which specifies my permitted client addresses, and I thought this would effectively filter any inbound queries. But it looks like this ACL is applied only AFTER connection setup. Maybe I have been blind this entire time thinking I wouldn't respond to any packets sent to my resolver from non-allowed-networks addresses. But anyways just a good data-point for anyone else to check your revolvers too and consider the TCP case may behave as mine do. I fixed it by implementing a revised iptables firewall which definitely corrects the issue and drops outright all packets to non-allowed-networks addresses, thank you ipset... Mike- From amir.lists at gmail.com Sun Aug 18 13:41:40 2019 From: amir.lists at gmail.com (Amir Herzberg) Date: Sun, 18 Aug 2019 09:41:40 -0400 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: The number of TCP syn-ack amplifiers is large. It may suffice to allow clogging a provider or IX, using low load per amplifier, as described. Such low load is likely to be undetected by most operators, and even when detected (e.g. by Jim), only few (e.g. Mike) will have sufficient motivation to block it - esp. considering that there blocking it would often be non-trivial, in Mike's case, the amplifiers were DNS servers and sounds like he simply blocked packets to unallowed networks (good practice for DNS anyway - although I wonder why not block the incoming requests instead). Notice that one annoying aspect of these attacks is that tcp congestion control isn't relevant. The current packets could be part of a research experiment about this threat, or the instrumentation part of preparing such attack. I would not rule out research, since it isn't trivial to know if the attack can be really viable to clog a provider or IX; in fact finding this out in an ethical way appears a non-trivial challenge, I'll give it some thought (ideas welcome). Also I wonder what would be good _defenses_ against such attack. Of course one way would be to prevent spoofed-IP packets, but that goal has proved quite difficult... -- Amir Herzberg Comcast professor for security innovation Dept. of Computer Science and Engineering, University of Connecticut On Sat, Aug 17, 2019 at 11:03 PM Mike wrote: > On 8/16/19 3:04 PM, Jim Shankland wrote: > > Greetings, > > > > I'm seeing slow-motion (a few per second, per IP/port pair) syn flood > > attacks ostensibly originating from 3 NL-based IP blocks: > > 88.208.0.0/18 , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" > > because ... syn flood, and BCP 38 not yet fully adopted). > > > > Why is this syn flood different from all other syn floods? Well ... > > > > 1. Rate seems too slow to do any actual damage (is anybody really > > bothered by a few bad SYN packets per second per service, at this > > point?); but > > > > 2. IPs/port combinations with actual open services are being targeted > > (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs > > with those services running), implying somebody checked for open > > services first; > > > > 3. I'm seeing this in at least 2 locations, to addresses in different, > > completely unrelated ASes, implying it may be pretty widespread. > > > > Is anybody else seeing the same thing? Any thoughts on what's going > > on? Or should I just be ignoring this and getting on with the weekend? > > > > Jim > > > > > > > > > > I am seeing this against my recursive revolvers - one syn in, and many > syn-ack's back with no connection obviously. Low rate to be sure, but > what was surprising to me was that my revolvers (PowerDNS) definitely > have an allowed-networks ACL which specifies my permitted client > addresses, and I thought this would effectively filter any inbound > queries. But it looks like this ACL is applied only AFTER connection > setup. Maybe I have been blind this entire time thinking I wouldn't > respond to any packets sent to my resolver from non-allowed-networks > addresses. But anyways just a good data-point for anyone else to check > your revolvers too and consider the TCP case may behave as mine do. I > fixed it by implementing a revised iptables firewall which definitely > corrects the issue and drops outright all packets to > non-allowed-networks addresses, thank you ipset... > > Mike- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike-nanog at tiedyenetworks.com Sun Aug 18 15:48:08 2019 From: mike-nanog at tiedyenetworks.com (Mike) Date: Sun, 18 Aug 2019 08:48:08 -0700 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: <7227f8d1-d1bc-f292-2912-84f09b11e3ac@tiedyenetworks.com> On 8/18/19 6:41 AM, Amir Herzberg wrote: > The number of TCP syn-ack amplifiers is large. It may suffice to allow > clogging a provider or IX, using low load per amplifier, as described. > Such low load is likely to be undetected by most operators, and even > when detected (e.g. by Jim), only few (e.g. Mike) will have sufficient > motivation to block it - esp. considering that there blocking it would > often be non-trivial, in Mike's case, the amplifiers were DNS servers > and sounds like he simply blocked packets to unallowed networks (good > practice for DNS anyway - although I wonder why not block the incoming > requests instead). Notice that one annoying aspect of these attacks is > that tcp congestion control isn't relevant.  > > The current packets could be part of a research experiment about this > threat, or the instrumentation part of preparing such attack. I would > not rule out research, since it isn't trivial to know if the attack > can be really viable to clog a provider or IX; in fact finding this > out in an ethical way appears a non-trivial challenge, I'll give it > some thought (ideas welcome). Also I wonder what would be good > _defenses_ against such attack. Of course one way would be to prevent > spoofed-IP packets, but that goal has proved quite difficult... I just shared this idea over on the powerdns list, but I do have an idea that may be potentially a good mitigation strategy and for the exact reason stated above; low load to individual end points may still, in aggregate, overwhelm an IX or provider, so cutting off the SYN-ACK traffic to those hosts which have not requested connections is good internet hygiene... My idea is to maintain a penaltybox for any client IP that initiated a connection but did not complete, while also maintaining a whitelist of 'frequent fliers' who have previously completed their connections successful. The penalty could simply be to drop traffic sourced from those client ips that do not complete the handshake, for some configurable timeout period. The whitelisting feature could give a pass to good clients and allow these to bypass the penalty filtering, for a longer timeout period (but of course, passing it along so other ACL's can take effect). I'd say, perhaps, a 5 minute timeout would be sufficient for a penalty, while 1 day or longer would be sufficient for whitelisting. It would depend on your traffic of course, and definitely you would want something efficient such as linux ipset as opposed to individual iptables rules. While looking around, I came across the SYNPROXY netfilter module.. it appears to be very complete but missing the above functionality to avoid responding to spoofed clients. I'm going to see about hacking up a proof of concept. I'll post here if I come up with something to play with. Mike- From cb.list6 at gmail.com Sun Aug 18 21:49:17 2019 From: cb.list6 at gmail.com (Ca By) Date: Sun, 18 Aug 2019 14:49:17 -0700 Subject: Centurylink Looking Glass fail Message-ID: Paging someone at Centurylink to fix your looking glass. https://lookingglass.centurylink.com None of the functions in any of the cities work Your network is kind of a big deal, so please try to provide visibility to your routing state so the rest of us can do our day-job, on Sunday -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian at google.com Mon Aug 19 04:37:32 2019 From: damian at google.com (Damian Menscher) Date: Sun, 18 Aug 2019 21:37:32 -0700 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: On Sun, Aug 18, 2019 at 6:42 AM Amir Herzberg wrote: > The current packets could be part of a research experiment about this > threat, or the instrumentation part of preparing such attack. I would not > rule out research, since it isn't trivial to know if the attack can be > really viable to clog a provider or IX; in fact finding this out in an > ethical way appears a non-trivial challenge, I'll give it some thought > (ideas welcome). Also I wonder what would be good _defenses_ against such > attack. Of course one way would be to prevent spoofed-IP packets, but that > goal has proved quite difficult... > The high packet rate (millions of packets/second) and broad targeting (several /24s, not just a handful of machines) make it clear this was an actual attack, not an experiment or reconnaissance. (There are also other clear signals, such as the timing of the attacks, source(s) originating the spoofed packets, etc.) Most kernels will return 3-5 SYN-ACK packets for an incoming SYN, so it's not particularly interesting for attackers or defenders. While a long-term mitigation could be to limit ourselves to a single SYN-ACK (via /proc/sys/net/ipv4/tcp_synack_retries) it's somewhat pointless to worry about a small amplification factor -- an attacker could attack directly... or use UDP to get a massive bandwidth (or even significant packet) amplification. A counter-argument presented in the paper "Hell of a Handshake: Abusing TCP for Reflective Amplification DDoS Attacks" is that several broken TCP stacks that will provide a much greater amplification factor. I disagree that preventing spoofed packets is difficult -- it's trivial for transit providers to use their netflow to identify the true source(s) of spoofed attacks, and then apply filters on their problematic customers (who refuse to apply egress filters themselves). If transit providers can't be bothered to be proactive about this, law enforcement can serve them with legal process to identify the problem customers, who might then be held responsible for the attacks they're facilitating. I commented on this approach in my talk at NANOG 76. Damian -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete at ots.utsystem.edu Mon Aug 19 05:49:10 2019 From: pete at ots.utsystem.edu (Mitcheltree, Harold B) Date: Mon, 19 Aug 2019 05:49:10 +0000 Subject: Centurylink Looking Glass fail In-Reply-To: References: Message-ID: +1, or reactivate the Level(3) AS 3356 LG. --pete ________________________________ From: NANOG on behalf of Ca By Sent: Sunday, August 18, 2019 4:49 PM To: North American Network Operators' Group Subject: Centurylink Looking Glass fail Paging someone at Centurylink to fix your looking glass. https://lookingglass.centurylink.com None of the functions in any of the cities work Your network is kind of a big deal, so please try to provide visibility to your routing state so the rest of us can do our day-job, on Sunday This message is from an external sender. Learn more about why this matters. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Mon Aug 19 10:56:32 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 19 Aug 2019 13:56:32 +0300 Subject: syn flood attacks from NL-based netblocks In-Reply-To: <7227f8d1-d1bc-f292-2912-84f09b11e3ac@tiedyenetworks.com> References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> <7227f8d1-d1bc-f292-2912-84f09b11e3ac@tiedyenetworks.com> Message-ID: Peace, On Sun, Aug 18, 2019 at 6:48 PM Mike wrote: > [..] I do have an idea > that may be potentially a good mitigation strategy and for the exact > reason stated above; low load to individual end points may still, in > aggregate, overwhelm an IX or provider, so cutting off the SYN-ACK > traffic to those hosts which have not requested connections is good > internet hygiene... In theory, yes, but it's incredibly complicated to do that properly at scale. > My idea is to maintain a penaltybox for any client IP that initiated a > connection but did not complete, while also maintaining a whitelist of > 'frequent fliers' who have previously completed their connections > successful. Unless a connection is completed, you do not know if the source IP address of your client is spoofed or not. (Under certain circumstances you don't know it even then, but it is unlikely that you would have to take such a possibiity into account). Therefore, you should not populate anything in your RAM from such a source. See also my short talk from RIPE 77 for more information: - https://ripe77.ripe.net/presentations/154-ddoswww_ripe77_004.pdf - https://ripe77.ripe.net/archives/video/2336/ Also, odds are a whitelist won't help either. > While looking around, I came across the SYNPROXY netfilter module. Not sure if it's still supported. I think I've read in LKML that it was dropped since Linux 4.4. Anyhow, it's impossible to scale without a complete rewrite. -- Töma From ximaera at gmail.com Mon Aug 19 11:14:54 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 19 Aug 2019 14:14:54 +0300 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: Peace, On Mon, Aug 19, 2019 at 7:39 AM Damian Menscher via NANOG wrote: > Most kernels will return 3-5 SYN-ACK packets for an incoming > SYN, so it's not particularly interesting for attackers or defenders. Well, producing 1000 Gbps as opposed to 200 Gbps is still pretty impressive, isn't it? More on that later, b/c the point here aren't even jiggabits, > it's somewhat pointless to worry about a small amplification > factor -- an attacker could [..] use UDP to get a massive > bandwidth (or even significant packet) amplification. Most of the resources hosted by a typical hosting company are essentially Web sites.[citation needed] Unless you are really really dependant on QUIC (and, unless we're all really unlucky and recent initiatives to get rid of TCP/TLS fallback in HTTP/3 would gain support), as a Web hosting company, you can use whatever you want to get rid of UDP completely very quickly, and that won't harm your business a lot. Dealing with TCP flags is a different story: - Your ability to handle them with the likes of RFC 5575 depend on what particular sort of equipment is deployed in your network; - To make matters worse, for a huge portion of customers the ability to connect to an external service/API gateway/Web site via TCP is crucial. A simple example is Google which cannot survive for long if Googlebot keeps being unable to operate. Think also OAuth, Skyscanner, credit scoring systems, insurance companies, etc.; - To ensure proper handling of spoofed SYN/ACKs while still maintaining a possibility to connect to an external service you, as a hosting company under an attack, would have to track all of the outgoing SYNs to match them against received SYN/ACKs later. This is where the "1kGbps-vs-200Gbps" argument becomes important, b/c every existing free connection state tracking solution doesn't scale beyond 200 Gbps at best given the best hardware money can buy given a single machine, and no existing solution is able to share its state across multiple machines. [there are proprietary products doing that though, we have one, but proprietary solutions are always a different kind of story] -- Töma From damian at google.com Mon Aug 19 17:12:46 2019 From: damian at google.com (Damian Menscher) Date: Mon, 19 Aug 2019 10:12:46 -0700 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: On Mon, Aug 19, 2019 at 4:15 AM Töma Gavrichenkov wrote: > Dealing with TCP flags is a different story: > I agree these attacks can be large: the one under discussion probably exceeded 10Mpps (Gbps is the wrong metric for small-packet attacks) I agree they can cause significant outages: this style of attack played a role in the Liberia outages in 2016 My main disagreement is whether small amplification factors are noteworthy. A factor of 2 is "rounding error" and we probably shouldn't waste our time on it (eg, by designing solutions to reduce amplification factors) when we could instead be targeting the sources of spoofed traffic. I was highlighting this as a DDoS (rather than a port scan) mainly to raise awareness. This is definitely an interesting form of attack, largely for the reasons you state (it's subtle to detect and therefore harder to mitigate). But this particular "carpet-bombing" attack isn't likely to be mitigated at the network layer anyway... the load is distributed across thousands of machines which can each trivially handle the state. It's more a question of bandwidth to the provider... and if you're targeting the provider's bandwidth you'd do better to use traditional UDP amplification. Damian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Mon Aug 19 17:44:47 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 19 Aug 2019 20:44:47 +0300 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: On Mon, Aug 19, 2019 at 8:12 PM Damian Menscher wrote: > A factor of 2 is "rounding error" and we probably shouldn't > waste our time on it (eg, by designing solutions to reduce > amplification factors) when we could instead be targeting > the sources of spoofed traffic. Ah, fine. Spoofing is obviously the root cause here. I was mostly addressing the statement that factors of 2 to 5 aren't "particularly interesting for attackers or defenders". In my experience they certainly are. > this particular "carpet-bombing" attack isn't likely to be > mitigated at the network layer anyway... the load is > distributed across thousands of machines which can > each trivially handle the state. Not in a typical DC/ISP environment! With the solution you propose, a perfect routing symmetry is a hard requirement, b/c you need to make sure a returning SYN/ACK hits the very same machine as the initial SYN. As long as you expect a DDoS to be handled somewhere close to the border of your network, this is hardly achievable for a network growing in size. -- Töma From valdis.kletnieks at vt.edu Mon Aug 19 17:56:59 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Mon, 19 Aug 2019 13:56:59 -0400 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> Message-ID: <201327.1566237419@turing-police> On Mon, 19 Aug 2019 20:44:47 +0300, T�ma Gavrichenkov said: > Not in a typical DC/ISP environment! With the solution you propose, a > perfect routing symmetry is a hard requirement, b/c you need to make > sure a returning SYN/ACK hits the very same machine as the initial > SYN. If your load balancer isn't doing something to make that situation work properly, you need to talk to your vendor. -------------- 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 Mon Aug 19 18:18:49 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 19 Aug 2019 21:18:49 +0300 Subject: syn flood attacks from NL-based netblocks In-Reply-To: <201327.1566237419@turing-police> References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> <201327.1566237419@turing-police> Message-ID: On Mon, Aug 19, 2019, 8:57 PM Valdis Klētnieks wrote: > On Mon, 19 Aug 2019 20:44:47 +0300, Töma Gavrichenkov said: > > > Not in a typical DC/ISP environment! With the solution you propose, a > > perfect routing symmetry is a hard requirement, b/c you need to make > > sure a returning SYN/ACK hits the very same machine as the initial > > SYN. > > If your load balancer isn't doing something to make that situation work > properly, > you need to talk to your vendor. > If you're doing load balancing for *outgoing* traffic — and in exactly the same manner as you do with incoming — then maybe. This also assumes that instead of mitigating an attack near the border you set up and keep an internal cluster of filtering machines somewhere and route, in the worst case scenario, *all* of your traffic through that cluster. Depending on the size of your network, it might or might not be an effective solution. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valdis.kletnieks at vt.edu Mon Aug 19 18:27:33 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Mon, 19 Aug 2019 14:27:33 -0400 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> <201327.1566237419@turing-police> Message-ID: <215315.1566239253@turing-police> On Mon, 19 Aug 2019 21:18:49 +0300, T�ma Gavrichenkov said: > If you're doing load balancing for *outgoing* traffic — and in exactly the > same manner as you do with incoming — then maybe. On the other hand, your servers should probably be doing non-loadbalanced outbound on a different IP address than the inbound load balancer, and thus the syn-ack should have zero trouble getting back to the box it thought the syn came from. -------------- 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 Mon Aug 19 18:51:34 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 19 Aug 2019 21:51:34 +0300 Subject: syn flood attacks from NL-based netblocks In-Reply-To: <215315.1566239253@turing-police> References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> <201327.1566237419@turing-police> <215315.1566239253@turing-police> Message-ID: On Mon, Aug 19, 2019, 9:27 PM Valdis Klētnieks wrote: > On Mon, 19 Aug 2019 21:18:49 +0300, Töma Gavrichenkov said: > > > If you're doing load balancing for *outgoing* traffic — and in exactly > the > > same manner as you do with incoming — then maybe. > > On the other hand, your servers should probably be doing non-loadbalanced > outbound on a different IP address than the inbound load balancer, and > thus the > syn-ack should have zero trouble getting back to the box it thought the syn > came from. > Killing it with the packet rate in the process? I assume this is about time to start drawing diagrams, otherwise we'll be quickly lost in context. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Mon Aug 19 19:05:30 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 19 Aug 2019 22:05:30 +0300 Subject: syn flood attacks from NL-based netblocks In-Reply-To: <1566239092096782915@squareflow.net> References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> <201327.1566237419@turing-police> <1566239092096782915@squareflow.net> Message-ID: On Mon, Aug 19, 2019, 9:24 PM Florian Brandstetter wrote: > ​Load balancing is done on Layer 4 or Layer 3 when routing, so your > ingress connection will have the same hash as the outgoing connection > (unless the source port of the connection changes on the ACK - which it > really should not). > If the hash is symmetric, yes. No wonder topology issues would have more impact, my point was that there are also other things to look at here. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccosta92630 at gmail.com Mon Aug 19 22:18:13 2019 From: ccosta92630 at gmail.com (Chris Costa) Date: Mon, 19 Aug 2019 15:18:13 -0700 Subject: SMF Tie Cable Standards for Data Center Applications Message-ID: In our new data center builds we're transitioning from MMF to SMF for the tie cabling between networking gear in the MDF/IDF racks to the server racks. Today those interconnects are short (under 100 meters) 10GE and 40GE-LX4 over MMF. We’re transitioning to SMF to support services beyond that, such as 100GBASE-LR4. Would G.652.D be the right specification for the infrastructure tie cabling? Are there other considerations around this? Thank you From sean at donelan.com Tue Aug 20 06:36:47 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 20 Aug 2019 02:36:47 -0400 (EDT) Subject: FCC: December 27, 2018 CenturyLink Network Outage Report Message-ID: The FCC announced the release of a report detailing the cause and impact of a nationwide CenturyLink network outage that occurred last December, along with recommendations to help prevent similar outages from occurring in the future https://www.fcc.gov/document/fcc-issues-report-centurylink-network-outage December 27, 2018 CenturyLink Network Outage Report In the early morning of December 27, 2018, CenturyLink experienced a nationwide outage on its fiber network that lasted for almost 37 hours. This outage was caused by an equipment failure catastrophically exacerbated by a network configuration error. It affected communications service providers, business customers, and consumers who directly or indirectly relied upon CenturyLink’s transport services, which route communications traffic from various providers to locations across the country, resulting in extensive disruptions to phone service, including 911 calling. The effects included dropped calls, disconnected 911 call centers (known as “Public Safety Answering Points”), and fast-busy signals for people who called 911. As many as 22 million customers across 39 states were affected by the outage, including approximately 17 million customers across 29 states who lacked reliable access to 911. Indeed, at least 886 calls to 911 were not delivered.1 Fortunately, based on discussions with affected service providers and public safety officials from affected states, as well as a review of media reports, the Public Safety and Homeland Security Bureau (Bureau) is not aware of any harm to life or property resulting from the outage. [...] From florianb at globalone.io Mon Aug 19 18:25:47 2019 From: florianb at globalone.io (Florian Brandstetter) Date: Mon, 19 Aug 2019 19:25:47 +0100 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: <0d54a7aa-2847-7469-a9a8-7e1e7f50c5c0@shankland.org> <201327.1566237419@turing-police> Message-ID: <1566239147548790284@globalone.io> ​​Load balancing is done on Layer 4 or Layer 3 when routing, so your ingress connection will have the same hash as the outgoing connection (unless the source port of the connection changes on the ACK - which it really should not). On Mon, 08/19/2019 06:18 PM, Töma Gavrichenkov wrote: > On Mon, Aug 19, 2019, 8:57 PM Valdis Klētnieks wrote: > > On Mon, 19 Aug 2019 20:44:47 +0300, Töma Gavrichenkov said: > > > Not in a typical DC/ISP environment! With the solution you propose, a > > perfect routing symmetry is a hard requirement, b/c you need to make > > sure a returning SYN/ACK hits the very same machine as the initial > > SYN. > > If your load balancer isn't doing something to make that situation work properly, > you need to talk to your vendor. > If you're doing load balancing for *outgoing* traffic — and in exactly the same manner as you do with incoming — then maybe. This also assumes that instead of mitigating an attack near the border you set up and keep an internal cluster of filtering machines somewhere and route, in the worst case scenario, *all* of your traffic through that cluster. Depending on the size of your network, it might or might not be an effective solution. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jheitz at cisco.com Tue Aug 20 14:08:26 2019 From: jheitz at cisco.com (Jakob Heitz (jheitz)) Date: Tue, 20 Aug 2019 14:08:26 +0000 Subject: syn flood attacks from NL-based netblocks In-Reply-To: References: Message-ID: <0710B713-1D6C-4B2B-A6E6-5129B005DF7B@cisco.com> The source address in the SYN is spoofed. What if the real owner of the source address wanted to connect to you? Then your penaltybox would block him. An attacker could now use your penaltybox to cause a DoS to the real owner of the IP address. > Date: Sun, 18 Aug 2019 08:48:08 -0700 > From: Mike > > My idea is to maintain a penaltybox for any client IP that initiated a > connection but did not complete, while also maintaining a whitelist of > 'frequent fliers' who have previously completed their connections > successful. The penalty could simply be to drop traffic sourced from > those client ips that do not complete the handshake, for some > configurable timeout period. The whitelisting feature could give a pass > to good clients and allow these to bypass the penalty filtering, for a > longer timeout period (but of course, passing it along so other ACL's > can take effect). I'd say, perhaps, a 5 minute timeout would be > sufficient for a penalty, while 1 day or longer would be sufficient for > whitelisting. It would depend on your traffic of course, and definitely > you would want something efficient such as linux ipset as opposed to > individual iptables rules. > > While looking around, I came across the SYNPROXY netfilter module.. it > appears to be very complete but missing the above functionality to avoid > responding to spoofed clients. I'm going to see about hacking up a proof > of concept. I'll post here if I come up with something to play with. > > Mike- From ximaera at gmail.com Wed Aug 21 19:44:00 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Wed, 21 Aug 2019 22:44:00 +0300 Subject: Reflection DDoS last week (was: syn flood attacks from NL-based netblocks) Message-ID: Peace, Here's to confirm that the pattern reported before in NANOG was indeed a reflection DDoS attack. On Sunday, it also hit our customer, here's the report: https://www.prnewswire.com/news-releases/root-cause-analysis-and-incident-report-on-the-august-ddos-attack-300905405.html tl;dr: basically that was a rather massive reflected SYN/ACK carpet bombing against several datacenter prefixes (no particular target was identified). -- Töma On Sat, Aug 17, 2019, 1:06 AM Jim Shankland wrote: > Greetings, > > I'm seeing slow-motion (a few per second, per IP/port pair) syn flood > attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18 > , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood, > and BCP 38 not yet fully adopted). > > Why is this syn flood different from all other syn floods? Well ... > > 1. Rate seems too slow to do any actual damage (is anybody really > bothered by a few bad SYN packets per second per service, at this > point?); but > > 2. IPs/port combinations with actual open services are being targeted > (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs > with those services running), implying somebody checked for open > services first; > > 3. I'm seeing this in at least 2 locations, to addresses in different, > completely unrelated ASes, implying it may be pretty widespread. > > Is anybody else seeing the same thing? Any thoughts on what's going on? > Or should I just be ignoring this and getting on with the weekend? > > Jim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian at google.com Wed Aug 21 21:17:24 2019 From: damian at google.com (Damian Menscher) Date: Wed, 21 Aug 2019 14:17:24 -0700 Subject: Reflection DDoS last week (was: syn flood attacks from NL-based netblocks) In-Reply-To: References: Message-ID: Thanks for following up, and for publishing two bits of key data: - This was part of a larger attack campaign that included CLDAP amplification - The SYN/ACK amplification resulted in 208Mpps (or more) Some additional questions, if you're able to answer them (off-list is fine if there are things that can't be shared broadly): - How large was the CLDAP amplification attack? What was the packet rate of the initial fragments? - The post suggested that the 208Mpps saturated some links. Did it cause other problems as well? - Was the attack referred to law enforcement? - Were any transit providers asked to trace the source of the spoofing to either stop the attack or facilitate the law enforcement investigation? Damian On Wed, Aug 21, 2019 at 12:44 PM Töma Gavrichenkov wrote: > Peace, > > Here's to confirm that the pattern reported before in NANOG was indeed a > reflection DDoS attack. On Sunday, it also hit our customer, here's the > report: > > > https://www.prnewswire.com/news-releases/root-cause-analysis-and-incident-report-on-the-august-ddos-attack-300905405.html > > tl;dr: basically that was a rather massive reflected SYN/ACK carpet > bombing against several datacenter prefixes (no particular target was > identified). > > -- > Töma > > On Sat, Aug 17, 2019, 1:06 AM Jim Shankland wrote: > >> Greetings, >> >> I'm seeing slow-motion (a few per second, per IP/port pair) syn flood >> attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18 >> , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood, >> and BCP 38 not yet fully adopted). >> >> Why is this syn flood different from all other syn floods? Well ... >> >> 1. Rate seems too slow to do any actual damage (is anybody really >> bothered by a few bad SYN packets per second per service, at this >> point?); but >> >> 2. IPs/port combinations with actual open services are being targeted >> (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs >> with those services running), implying somebody checked for open >> services first; >> >> 3. I'm seeing this in at least 2 locations, to addresses in different, >> completely unrelated ASes, implying it may be pretty widespread. >> >> Is anybody else seeing the same thing? Any thoughts on what's going on? >> Or should I just be ignoring this and getting on with the weekend? >> >> Jim >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ximaera at gmail.com Wed Aug 21 22:20:51 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Thu, 22 Aug 2019 01:20:51 +0300 Subject: Reflection DDoS last week (was: syn flood attacks from NL-based netblocks) In-Reply-To: References: Message-ID: Peace, On Thu, Aug 22, 2019 at 12:17 AM Damian Menscher wrote: > Some additional questions, if you're able to answer them (off-list is fine if there are things that can't be shared broadly): > - Was the attack referred to law enforcement? It is being referred to now. This would most probably get going under the jurisdiction of the Netherlands. Whether the latter would be able to address it properly or not remains to be seen, but honestly I'm not quite optimistic here. > - Were any transit providers asked to trace the > source of the spoofing to either stop the attack > or facilitate the law enforcement investigation? No. Initially we were busy setting up the game and pushing the upstreams to accept our new customer prefix advertisements a.s.a.p. Afterwards we were too busy trying to understand why some of the upstreams didn't work as expected (that part was mentioned in the report). Hence, tracing the source was not deemed a high priority task. -- Töma From amir.lists at gmail.com Thu Aug 22 01:45:54 2019 From: amir.lists at gmail.com (Amir Herzberg) Date: Wed, 21 Aug 2019 21:45:54 -0400 Subject: Reflection DDoS last week (was: syn flood attacks from NL-based netblocks) In-Reply-To: References: Message-ID: Töma, thanks for this interesting update. The best defense against this type of DDoS attacks seems idd to be relaying to sufficiently-large-bandwidth cloud/CDN, and filtering TCP traffic (received not from the relay). Such relaying should be done well - smart attacks may still be possible for `naive' relaying. -- Amir On Wed, Aug 21, 2019 at 3:46 PM Töma Gavrichenkov wrote: > Peace, > > Here's to confirm that the pattern reported before in NANOG was indeed a > reflection DDoS attack. On Sunday, it also hit our customer, here's the > report: > > > https://www.prnewswire.com/news-releases/root-cause-analysis-and-incident-report-on-the-august-ddos-attack-300905405.html > > tl;dr: basically that was a rather massive reflected SYN/ACK carpet > bombing against several datacenter prefixes (no particular target was > identified). > > -- > Töma > > On Sat, Aug 17, 2019, 1:06 AM Jim Shankland wrote: > >> Greetings, >> >> I'm seeing slow-motion (a few per second, per IP/port pair) syn flood >> attacks ostensibly originating from 3 NL-based IP blocks: 88.208.0.0/18 >> , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly" because ... syn flood, >> and BCP 38 not yet fully adopted). >> >> Why is this syn flood different from all other syn floods? Well ... >> >> 1. Rate seems too slow to do any actual damage (is anybody really >> bothered by a few bad SYN packets per second per service, at this >> point?); but >> >> 2. IPs/port combinations with actual open services are being targeted >> (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs >> with those services running), implying somebody checked for open >> services first; >> >> 3. I'm seeing this in at least 2 locations, to addresses in different, >> completely unrelated ASes, implying it may be pretty widespread. >> >> Is anybody else seeing the same thing? Any thoughts on what's going on? >> Or should I just be ignoring this and getting on with the weekend? >> >> Jim >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at donelan.com Thu Aug 22 19:42:25 2019 From: sean at donelan.com (Sean Donelan) Date: Thu, 22 Aug 2019 15:42:25 -0400 (EDT) Subject: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar Message-ID: I haven't been paying attention to the WISP market, so I'm not up to speed on these issues. https://www.fcc.gov/document/fcc-proposes-fines-against-wisps-and-issues-warning-industry-0 The Federal Communications Commission’s Enforcement Bureau today announced proposed fines and issued a formal industry warning related to devices that apparently caused interference to the Federal Aviation Administration’s terminal doppler weather radar station in San Juan, Puerto Rico. The Enforcement Bureau proposed three separate $25,000 fines against wireless Internet service providers Boom Solutions, Integra Wireless, and WinPR. [...] In addition to the proposed fines, the Bureau’s Enforcement Advisory warned operators, manufacturers, and marketers of Unlicensed National Information Infrastructure devices that these devices must be certified under FCC rules. Such devices that operate in the 5.25 GHz to 5.35 GHz and 5.47 GHz to 5.725 GHz bands risk interfering with radar systems if not properly configured to share the spectrum [...] From bradley at wifastnetworks.com Thu Aug 22 21:09:26 2019 From: bradley at wifastnetworks.com (Bradley Burch) Date: Thu, 22 Aug 2019 17:09:26 -0400 Subject: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar In-Reply-To: References: Message-ID: <1E43717C-AF92-4DFA-9230-CA19A2C4E102@wifastnetworks.com> Most gear now will hop frequencies automatically if they receive a DFS interference. If your gear supports this, turn it on. Brad, > On Aug 22, 2019, at 3:42 PM, Sean Donelan wrote: > > I haven't been paying attention to the WISP market, so I'm not up to speed on these issues. > > > https://www.fcc.gov/document/fcc-proposes-fines-against-wisps-and-issues-warning-industry-0 > > The Federal Communications Commission’s Enforcement Bureau today announced proposed fines and issued a formal industry warning related to devices that apparently caused interference to the Federal Aviation Administration’s terminal doppler weather radar station in San Juan, Puerto Rico. The Enforcement Bureau proposed three separate $25,000 fines against wireless Internet service providers Boom Solutions, Integra Wireless, and WinPR. > > [...] > > In addition to the proposed fines, the Bureau’s Enforcement Advisory warned operators, manufacturers, and marketers of Unlicensed National Information Infrastructure devices that these devices must be certified under FCC rules. Such devices that operate in the 5.25 GHz to 5.35 GHz and 5.47 GHz to 5.725 GHz bands risk interfering with radar systems if not properly configured to share the spectrum > > [...] From emille at abccommunications.com Thu Aug 22 21:31:46 2019 From: emille at abccommunications.com (Emille Blanc) Date: Thu, 22 Aug 2019 21:31:46 +0000 Subject: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar In-Reply-To: <1E43717C-AF92-4DFA-9230-CA19A2C4E102@wifastnetworks.com> References: <1E43717C-AF92-4DFA-9230-CA19A2C4E102@wifastnetworks.com> Message-ID: <6d8f18d8d04a40078f184790cdc2b2ac@EX2K13.ad.abccommunications.com> $25k seems like a cheap fine, really. Have you seen the price of spectrum these days? And links operating in a licensed spectrum tend to incur $1k per link per year in usage fees. > Most gear now will hop frequencies automatically if they receive a DFS interference. > If your gear supports this, turn it on. Said gear almost always has an option to ignore it too, thanks to different regulatory requirements. North-American operator: Hey, you're actually in India, so don't do DFS on those channels! Radio equipment: 'Kay. Queue argument for doing it right and having a link in a non-DFS susceptible channel to survive those many-minute long radar event triggered outages. And counter-argument for the increased costs, so what's the point in using cheap 5GHz radios and spectrum in the first place? Counter-counter-argument that 5GHz gear is so cheap! Such throughput! Wow! I've seen and heard these stories before, and that's usually how it goes. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bradley Burch Sent: Thursday, August 22, 2019 2:09 PM To: Sean Donelan Cc: nanog at nanog.org Subject: Re: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar Most gear now will hop frequencies automatically if they receive a DFS interference. If your gear supports this, turn it on. Brad, > On Aug 22, 2019, at 3:42 PM, Sean Donelan wrote: > > I haven't been paying attention to the WISP market, so I'm not up to speed on these issues. > > > https://www.fcc.gov/document/fcc-proposes-fines-against-wisps-and-issues-warning-industry-0 > > The Federal Communications Commission’s Enforcement Bureau today announced proposed fines and issued a formal industry warning related to devices that apparently caused interference to the Federal Aviation Administration’s terminal doppler weather radar station in San Juan, Puerto Rico. The Enforcement Bureau proposed three separate $25,000 fines against wireless Internet service providers Boom Solutions, Integra Wireless, and WinPR. > > [...] > > In addition to the proposed fines, the Bureau’s Enforcement Advisory warned operators, manufacturers, and marketers of Unlicensed National Information Infrastructure devices that these devices must be certified under FCC rules. Such devices that operate in the 5.25 GHz to 5.35 GHz and 5.47 GHz to 5.725 GHz bands risk interfering with radar systems if not properly configured to share the spectrum > > [...] From mattlists at rivervalleyinternet.net Thu Aug 22 21:42:35 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Thu, 22 Aug 2019 17:42:35 -0400 Subject: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar In-Reply-To: <6d8f18d8d04a40078f184790cdc2b2ac@EX2K13.ad.abccommunications.com> References: <1E43717C-AF92-4DFA-9230-CA19A2C4E102@wifastnetworks.com> <6d8f18d8d04a40078f184790cdc2b2ac@EX2K13.ad.abccommunications.com> Message-ID: <9BACCCC2-5BA8-42EE-B935-4A55F3427D39@rivervalleyinternet.net> I don’t know where you’re doing your licensing but I pay about $500 every 10 years for my license links. And $25,000 is what you paid to use the link in legally possibly causing wanton endangerment to life, and then you have to stop using it. > On Aug 22, 2019, at 5:31 PM, Emille Blanc wrote: > > $25k seems like a cheap fine, really. Have you seen the price of spectrum these days? > And links operating in a licensed spectrum tend to incur $1k per link per year in usage fees. > >> Most gear now will hop frequencies automatically if they receive a DFS interference. >> If your gear supports this, turn it on. > > Said gear almost always has an option to ignore it too, thanks to different regulatory requirements. > > North-American operator: Hey, you're actually in India, so don't do DFS on those channels! > Radio equipment: 'Kay. > > Queue argument for doing it right and having a link in a non-DFS susceptible channel to survive those many-minute long radar event triggered outages. > And counter-argument for the increased costs, so what's the point in using cheap 5GHz radios and spectrum in the first place? > Counter-counter-argument that 5GHz gear is so cheap! Such throughput! Wow! > > I've seen and heard these stories before, and that's usually how it goes. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bradley Burch > Sent: Thursday, August 22, 2019 2:09 PM > To: Sean Donelan > Cc: nanog at nanog.org > Subject: Re: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar > > > Most gear now will hop frequencies automatically if they receive a DFS interference. > > If your gear supports this, turn it on. > Brad, > >> On Aug 22, 2019, at 3:42 PM, Sean Donelan wrote: >> >> I haven't been paying attention to the WISP market, so I'm not up to speed on these issues. >> >> >> https://www.fcc.gov/document/fcc-proposes-fines-against-wisps-and-issues-warning-industry-0 >> >> The Federal Communications Commission’s Enforcement Bureau today announced proposed fines and issued a formal industry warning related to devices that apparently caused interference to the Federal Aviation Administration’s terminal doppler weather radar station in San Juan, Puerto Rico. The Enforcement Bureau proposed three separate $25,000 fines against wireless Internet service providers Boom Solutions, Integra Wireless, and WinPR. >> >> [...] >> >> In addition to the proposed fines, the Bureau’s Enforcement Advisory warned operators, manufacturers, and marketers of Unlicensed National Information Infrastructure devices that these devices must be certified under FCC rules. Such devices that operate in the 5.25 GHz to 5.35 GHz and 5.47 GHz to 5.725 GHz bands risk interfering with radar systems if not properly configured to share the spectrum >> >> [...] > From emille at abccommunications.com Thu Aug 22 21:51:50 2019 From: emille at abccommunications.com (Emille Blanc) Date: Thu, 22 Aug 2019 21:51:50 +0000 Subject: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar In-Reply-To: <9BACCCC2-5BA8-42EE-B935-4A55F3427D39@rivervalleyinternet.net> References: <1E43717C-AF92-4DFA-9230-CA19A2C4E102@wifastnetworks.com> <6d8f18d8d04a40078f184790cdc2b2ac@EX2K13.ad.abccommunications.com> <9BACCCC2-5BA8-42EE-B935-4A55F3427D39@rivervalleyinternet.net> Message-ID: > I don’t know where you’re doing your licensing but I pay about $500 every 10 years for my license links. I should have clarified - CA operator here. I expect Industry Canada fees differ quite a bit, but that's about our average for licensing in the upper bands. -----Original Message----- From: Matt Hoppes [mailto:mattlists at rivervalleyinternet.net] Sent: Thursday, August 22, 2019 2:43 PM To: Emille Blanc Cc: Bradley Burch; Sean Donelan; nanog at nanog.org Subject: Re: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar I don’t know where you’re doing your licensing but I pay about $500 every 10 years for my license links. And $25,000 is what you paid to use the link in legally possibly causing wanton endangerment to life, and then you have to stop using it. > On Aug 22, 2019, at 5:31 PM, Emille Blanc wrote: > > $25k seems like a cheap fine, really. Have you seen the price of spectrum these days? > And links operating in a licensed spectrum tend to incur $1k per link per year in usage fees. > >> Most gear now will hop frequencies automatically if they receive a DFS interference. >> If your gear supports this, turn it on. > > Said gear almost always has an option to ignore it too, thanks to different regulatory requirements. > > North-American operator: Hey, you're actually in India, so don't do DFS on those channels! > Radio equipment: 'Kay. > > Queue argument for doing it right and having a link in a non-DFS susceptible channel to survive those many-minute long radar event triggered outages. > And counter-argument for the increased costs, so what's the point in using cheap 5GHz radios and spectrum in the first place? > Counter-counter-argument that 5GHz gear is so cheap! Such throughput! Wow! > > I've seen and heard these stories before, and that's usually how it goes. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bradley Burch > Sent: Thursday, August 22, 2019 2:09 PM > To: Sean Donelan > Cc: nanog at nanog.org > Subject: Re: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar > > > Most gear now will hop frequencies automatically if they receive a DFS interference. > > If your gear supports this, turn it on. > Brad, > >> On Aug 22, 2019, at 3:42 PM, Sean Donelan wrote: >> >> I haven't been paying attention to the WISP market, so I'm not up to speed on these issues. >> >> >> https://www.fcc.gov/document/fcc-proposes-fines-against-wisps-and-issues-warning-industry-0 >> >> The Federal Communications Commission’s Enforcement Bureau today announced proposed fines and issued a formal industry warning related to devices that apparently caused interference to the Federal Aviation Administration’s terminal doppler weather radar station in San Juan, Puerto Rico. The Enforcement Bureau proposed three separate $25,000 fines against wireless Internet service providers Boom Solutions, Integra Wireless, and WinPR. >> >> [...] >> >> In addition to the proposed fines, the Bureau’s Enforcement Advisory warned operators, manufacturers, and marketers of Unlicensed National Information Infrastructure devices that these devices must be certified under FCC rules. Such devices that operate in the 5.25 GHz to 5.35 GHz and 5.47 GHz to 5.725 GHz bands risk interfering with radar systems if not properly configured to share the spectrum >> >> [...] > From mattlists at rivervalleyinternet.net Thu Aug 22 22:01:08 2019 From: mattlists at rivervalleyinternet.net (Matt Hoppes) Date: Thu, 22 Aug 2019 18:01:08 -0400 Subject: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar In-Reply-To: References: <1E43717C-AF92-4DFA-9230-CA19A2C4E102@wifastnetworks.com> <6d8f18d8d04a40078f184790cdc2b2ac@EX2K13.ad.abccommunications.com> <9BACCCC2-5BA8-42EE-B935-4A55F3427D39@rivervalleyinternet.net> Message-ID: <473A8A67-8705-4E27-BD0D-61284C80BD66@rivervalleyinternet.net> Ouch!!!! On Aug 22, 2019, at 5:51 PM, Emille Blanc wrote: >> I don’t know where you’re doing your licensing but I pay about $500 every 10 years for my license links. > > I should have clarified - CA operator here. > I expect Industry Canada fees differ quite a bit, but that's about our average for licensing in the upper bands. > > -----Original Message----- > From: Matt Hoppes [mailto:mattlists at rivervalleyinternet.net] > Sent: Thursday, August 22, 2019 2:43 PM > To: Emille Blanc > Cc: Bradley Burch; Sean Donelan; nanog at nanog.org > Subject: Re: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar > > I don’t know where you’re doing your licensing but I pay about $500 every 10 years for my license links. > > And $25,000 is what you paid to use the link in legally possibly causing wanton endangerment to life, and then you have to stop using it. > >> On Aug 22, 2019, at 5:31 PM, Emille Blanc wrote: >> >> $25k seems like a cheap fine, really. Have you seen the price of spectrum these days? >> And links operating in a licensed spectrum tend to incur $1k per link per year in usage fees. >> >>> Most gear now will hop frequencies automatically if they receive a DFS interference. >>> If your gear supports this, turn it on. >> >> Said gear almost always has an option to ignore it too, thanks to different regulatory requirements. >> >> North-American operator: Hey, you're actually in India, so don't do DFS on those channels! >> Radio equipment: 'Kay. >> >> Queue argument for doing it right and having a link in a non-DFS susceptible channel to survive those many-minute long radar event triggered outages. >> And counter-argument for the increased costs, so what's the point in using cheap 5GHz radios and spectrum in the first place? >> Counter-counter-argument that 5GHz gear is so cheap! Such throughput! Wow! >> >> I've seen and heard these stories before, and that's usually how it goes. >> >> -----Original Message----- >> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bradley Burch >> Sent: Thursday, August 22, 2019 2:09 PM >> To: Sean Donelan >> Cc: nanog at nanog.org >> Subject: Re: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar >> >> >> Most gear now will hop frequencies automatically if they receive a DFS interference. >> >> If your gear supports this, turn it on. >> Brad, >> >>> On Aug 22, 2019, at 3:42 PM, Sean Donelan wrote: >>> >>> I haven't been paying attention to the WISP market, so I'm not up to speed on these issues. >>> >>> >>> https://www.fcc.gov/document/fcc-proposes-fines-against-wisps-and-issues-warning-industry-0 >>> >>> The Federal Communications Commission’s Enforcement Bureau today announced proposed fines and issued a formal industry warning related to devices that apparently caused interference to the Federal Aviation Administration’s terminal doppler weather radar station in San Juan, Puerto Rico. The Enforcement Bureau proposed three separate $25,000 fines against wireless Internet service providers Boom Solutions, Integra Wireless, and WinPR. >>> >>> [...] >>> >>> In addition to the proposed fines, the Bureau’s Enforcement Advisory warned operators, manufacturers, and marketers of Unlicensed National Information Infrastructure devices that these devices must be certified under FCC rules. Such devices that operate in the 5.25 GHz to 5.35 GHz and 5.47 GHz to 5.725 GHz bands risk interfering with radar systems if not properly configured to share the spectrum >>> >>> [...] >> > From bradley at wifastnetworks.com Thu Aug 22 23:22:05 2019 From: bradley at wifastnetworks.com (Bradley Burch) Date: Thu, 22 Aug 2019 19:22:05 -0400 Subject: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar In-Reply-To: <6d8f18d8d04a40078f184790cdc2b2ac@EX2K13.ad.abccommunications.com> References: <1E43717C-AF92-4DFA-9230-CA19A2C4E102@wifastnetworks.com> <6d8f18d8d04a40078f184790cdc2b2ac@EX2K13.ad.abccommunications.com> Message-ID: Good equipment uses GPS and manages frequency allowance accordingly. :) > On Aug 22, 2019, at 5:31 PM, Emille Blanc wrote: > > $25k seems like a cheap fine, really. Have you seen the price of spectrum these days? > And links operating in a licensed spectrum tend to incur $1k per link per year in usage fees. > >> Most gear now will hop frequencies automatically if they receive a DFS interference. >> If your gear supports this, turn it on. > > Said gear almost always has an option to ignore it too, thanks to different regulatory requirements. > > North-American operator: Hey, you're actually in India, so don't do DFS on those channels! > Radio equipment: 'Kay. > > Queue argument for doing it right and having a link in a non-DFS susceptible channel to survive those many-minute long radar event triggered outages. > And counter-argument for the increased costs, so what's the point in using cheap 5GHz radios and spectrum in the first place? > Counter-counter-argument that 5GHz gear is so cheap! Such throughput! Wow! > > I've seen and heard these stories before, and that's usually how it goes. > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Bradley Burch > Sent: Thursday, August 22, 2019 2:09 PM > To: Sean Donelan > Cc: nanog at nanog.org > Subject: Re: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar > > > Most gear now will hop frequencies automatically if they receive a DFS interference. > > If your gear supports this, turn it on. > Brad, > >> On Aug 22, 2019, at 3:42 PM, Sean Donelan wrote: >> >> I haven't been paying attention to the WISP market, so I'm not up to speed on these issues. >> >> >> https://www.fcc.gov/document/fcc-proposes-fines-against-wisps-and-issues-warning-industry-0 >> >> The Federal Communications Commission’s Enforcement Bureau today announced proposed fines and issued a formal industry warning related to devices that apparently caused interference to the Federal Aviation Administration’s terminal doppler weather radar station in San Juan, Puerto Rico. The Enforcement Bureau proposed three separate $25,000 fines against wireless Internet service providers Boom Solutions, Integra Wireless, and WinPR. >> >> [...] >> >> In addition to the proposed fines, the Bureau’s Enforcement Advisory warned operators, manufacturers, and marketers of Unlicensed National Information Infrastructure devices that these devices must be certified under FCC rules. Such devices that operate in the 5.25 GHz to 5.35 GHz and 5.47 GHz to 5.725 GHz bands risk interfering with radar systems if not properly configured to share the spectrum >> >> [...] > From sean at donelan.com Thu Aug 22 23:25:42 2019 From: sean at donelan.com (Sean Donelan) Date: Thu, 22 Aug 2019 19:25:42 -0400 (EDT) Subject: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar In-Reply-To: References: <1E43717C-AF92-4DFA-9230-CA19A2C4E102@wifastnetworks.com> <6d8f18d8d04a40078f184790cdc2b2ac@EX2K13.ad.abccommunications.com> Message-ID: On Thu, 22 Aug 2019, Bradley Burch wrote: > Good equipment uses GPS and manages frequency allowance accordingly. > :) In the business plan, cheap equipment beats good equipment every time :-) Cutting corners on safety is great for the business plan too .... From lists.nanog at monmotha.net Fri Aug 23 05:28:22 2019 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 23 Aug 2019 01:28:22 -0400 Subject: FCC Takes Action Against WISPs That Interfered with FCC Weather Radar In-Reply-To: <1E43717C-AF92-4DFA-9230-CA19A2C4E102@wifastnetworks.com> References: <1E43717C-AF92-4DFA-9230-CA19A2C4E102@wifastnetworks.com> Message-ID: On 8/22/19 5:09 PM, Bradley Burch wrote: > Most gear now will hop frequencies automatically if they receive a DFS interference. "Most" should mean "everything intended for sale in FCC-controlled territories" since it's a requirement to use that spectrum for part 15 purposes at all. If you don't support DFS, you're not supposed to use that spectrum at all, and therefore you shouldn't offer to configure it for the user if you support regulatory domain type compliance at all. I suspect at least some gear gets around that with the whole "intended for configuration by qualified individuals" schtick, but that's pretty weak IMO. > If your gear supports this, turn it on. More like don't turn it off if you're using most stuff and don't defeat the regulatory domain functionality, either. If you're using gear intended for the aforementioned "qualified individuals", well, make sure you're qualified to configure the thing. I want to say most of the low-cost wISP targeted gear that I'm aware of has never supported the DFS-required spectrum without actually implementing DFS. If you're buying high-$$$ carrier-class gear, I should at least hope you know how to configure it properly. Oddly, I have some general-purpose access points that do, though the instructions are clear that they're for indoor use only when using those channels. -- Brandon Martin From mark.tinka at seacom.mu Fri Aug 23 05:46:03 2019 From: mark.tinka at seacom.mu (Mark Tinka) Date: Fri, 23 Aug 2019 07:46:03 +0200 Subject: Fwd: [safnog] SAFNOG-5 Is Ready For You In-Reply-To: <1566480611986.32667@safnog.net> References: <1566480611986.32667@safnog.net> Message-ID: FYI - SAFNOG-5 in Johannesburg, next week. Mark. -------- Forwarded Message -------- Subject: [safnog] SAFNOG-5 Is Ready For You Date: Thu, 22 Aug 2019 13:30:12 +0000 From: Portia Rabonda To: safnog at safnog.org Hello All, With just 4 days to go to SAFNOG-5 in Johannesburg, South Africa, we are excited to have you join us for what is going to be a very informative, educational and fun agenda. Highlights from the program include: * 3 keynotes: o Sunil Tagare (OpenCables), talking about the impact of the submarine cables - on Africa - that Facebook and Google have announced, and what it could mean for the continent. o Byron Clatterbuck (SEACOM), also speaking about submarine cable realities in Africa, how to make them sustainable and help effect change in the region. o Jerome Fleury (Cloudflare), who will be going into detail about the outage his organization faced on June 24th of this year, due to a massive BGP leak. * The first carrier-neutral data centre that will go live in Kampala, Uganda, at the end of 2019. * A panel on the relevance (or lack of thereof) of generalized speed tests in 2019 as minimum bandwidth increases for consumers, enterprises and service providers. * South Africa's first FTTH service provider that is delivering native IPv6 to home users. * Numerous tutorials/workshops that will provide training on: o IPv6 deployment. o IRR, RPKI and ROV for a secure, global BGP. o Critical infrastructure vis a vis what the Internet should be, and what it actually is. There will also be a number of social events taking place, which will connect all participants to further network with one another and create opportunities on helping further grow the Internet within the region, and the rest of the world. To register for the event, and for more details on the agenda, please visit:​ http://www.safnog.org/ We look forward to seeing you in Johannesburg.​ Regards, SAFNOG-5 Programme Committee -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ safnog mailing list safnog at safnog.org http://lists.safnog.org/listinfo/safnog From harbor235 at gmail.com Fri Aug 23 18:40:30 2019 From: harbor235 at gmail.com (harbor235) Date: Fri, 23 Aug 2019 14:40:30 -0400 Subject: Tiered operations support Message-ID: Hi noggers, First some background; I have inherited a real-time services delivery infrastructure that while technically functional is absent of a wworking tiered operational support structure. In addition, the infrastructure was not implemented with technology best practices and has some remaining single points of failure. T3/engineering handles engineering, operational support, testing, and development. T1 and T2 perform some tasks but not what is expected of a traditional support structure, As we are attempting to scale our program our limitations are obvious. We are trying to scale the program and need to remedy all single points of failure and implement technical and management best practices. While we try to remedy all of the above, our customer expects routine capability enhancements. Question(s) 1) how to pivot to a tiered operational support structure and set expectations for each tier level. How do I do that without having my entire staff leave? Current staff is not a professional organization and are used to a purely reactive state. 2) ITIL process are great and we have started to implement what makes sense but I need a operational support stucture/model to support and manage this effort. 3) How do you manage your engineering and operational projects? Currently I am using Excel for all projects short and long term and also use a seperate spreadsheet for my short term project sprints? Basic project tracking with no mature processes involve. How are you pulling this all together? I would like to hire key positions that can bring essential capabilities to my project but I am limited hiring new staff. thoughts, suggestions Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From clayton at MNSi.Net Fri Aug 23 18:47:08 2019 From: clayton at MNSi.Net (Clayton Zekelman) Date: Fri, 23 Aug 2019 14:47:08 -0400 Subject: Tiered operations support In-Reply-To: References: Message-ID: <1566586032_85706@surgemail.mnsi.net> Find a new job. At 02:40 PM 23/08/2019, harbor235 wrote: >Hi noggers, > >First some background; > >I have inherited a real-time services delivery >infrastructure that while technically functional >is absent of a wworking tiered operational >support structure. In addition, the >infrastructure was not implemented with >technology best practices and has some remaining >single points of failure. T3/engineering handles >engineering, operational support, testing, and >development. T1 and T2 perform some tasks but >not what is expected of a traditional support >structure, As we are attempting to scale our >program our limitations are obvious. > >We are trying to scale the program and need to >remedy all single points of failure and >implement technical and management best >practices. While we try to remedy all of the >above, our customer expects routine capability enhancements. > >Question(s) >1) how to pivot to a tiered operational support >structure and set expectations for each tier >level. How do I do that without having my entire staff leave? >      Current staff is not a professional >organization and are used to a purely reactive state. > >2) ITIL process are great and we have started to >implement what makes sense but I need a >operational support stucture/model to support and manage this effort. > >3) How do you manage your engineering and >operational projects? Currently I am using Excel >for all projects short and long term and also >use a seperate spreadsheet for my short term >project sprints? Basic project tracking with no mature processes involve. > >How are you pulling this all together? > >I would like to hire key positions that can >bring essential capabilities to my project but I am limited hiring new staff. > >thoughts, suggestions > >Mike From surfer at mauigateway.com Fri Aug 23 19:00:24 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 23 Aug 2019 12:00:24 -0700 Subject: Tiered operations support Message-ID: <20190823120024.AE704724@m0117164.ppops.net> --- harbor235 at gmail.com wrote: How do I do that without having my entire staff leave? Current staff is not a professional organization and are used to a purely reactive state. ----------------------------------------------------- Maybe you want some of them to leave, if they're "not a professional organization". Get some fresh folks from professional minded organizations and see if the others quit being reactionary only and step up their game. scott From mfidelman at meetinghouse.net Fri Aug 23 20:23:01 2019 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 23 Aug 2019 16:23:01 -0400 Subject: Tiered operations support In-Reply-To: <1566586032_85706@surgemail.mnsi.net> References: <1566586032_85706@surgemail.mnsi.net> Message-ID: <91a047d3-55d6-4941-f043-cb40b0d32236@meetinghouse.net> Both of those would be my first reactions. Or... depending on how "not professional" your staff is, you might consider sending them out for some training, or bringing someone in to do some training. Heck, you could challenge your your staff with "ok team, go figure out a more mature approach." Miles Fidelman ---harbor235 at gmail.com wrote: Maybe you want some of them to leave, if they're "not a professional organization". Get some fresh folks from professional minded organizations and see if the others quit being reactionary only and step up their game. and On 8/23/19 2:47 PM, Clayton Zekelman wrote: > > Find a new job. > > At 02:40 PM 23/08/2019, harbor235 wrote: >> Hi noggers, >> >> First some background; >> >> I have inherited a real-time services delivery infrastructure that >> while technically functional is absent of a wworking tiered >> operational support structure. In addition, the infrastructure was >> not implemented with technology best practices and has some remaining >> single points of failure. T3/engineering handles engineering, >> operational support, testing, and development. T1 and T2 perform some >> tasks but not what is expected of a traditional support structure, As >> we are attempting to scale our program our limitations are obvious. >> >> We are trying to scale the program and need to remedy all single >> points of failure and implement technical and management best >> practices. While we try to remedy all of the above, our customer >> expects routine capability enhancements. >> >> Question(s) >> 1) how to pivot to a tiered operational support structure and set >> expectations for each tier level. How do I do that without having my >> entire staff leave? >>        Current staff is not a professional organization and are >> used to a purely reactive state. >> >> 2) ITIL process are great and we have started to implement what makes >> sense but I need a operational support stucture/model to support and >> manage this effort. >> >> 3) How do you manage your engineering and operational projects? >> Currently I am using Excel for all projects short and long term and >> also use a seperate spreadsheet for my short term project sprints? >> Basic project tracking with no mature processes involve. >> >> How are you pulling this all together? >> >> I would like to hire key positions that can bring essential >> capabilities to my project but I am limited hiring new staff. >> >> thoughts, suggestions >> >> Mike -- 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 contemno at gmail.com Fri Aug 23 21:02:15 2019 From: contemno at gmail.com (Joshua Miller) Date: Fri, 23 Aug 2019 17:02:15 -0400 Subject: Tiered operations support In-Reply-To: <91a047d3-55d6-4941-f043-cb40b0d32236@meetinghouse.net> References: <1566586032_85706@surgemail.mnsi.net> <91a047d3-55d6-4941-f043-cb40b0d32236@meetinghouse.net> Message-ID: Mike, You're essentially trying to change the culture of the organization. Unless you have senior management buy-in, it will be pretty fruitless. Maybe while announcing the restructuring, offer bonuses to keep people from leaving prematurely? People can adapt if the rate of change isn't too high. Like others have said, turnover isn't bad as long as you can maintain continuity of operations. Keep in mind, the highest performers are the most mobile. Best, Joshua On Fri, Aug 23, 2019 at 4:24 PM Miles Fidelman wrote: > Both of those would be my first reactions. > > Or... depending on how "not professional" your staff is, you might > consider sending them out for some training, or bringing someone in to do > some training. > > Heck, you could challenge your your staff with "ok team, go figure out a > more mature approach." > > Miles Fidelman > > > ---harbor235 at gmail.com wrote: > > Maybe you want some of them to leave, if they're "not > a professional organization". Get some fresh folks > from professional minded organizations and see if > the others quit being reactionary only and step up > their game. > > and > > > On 8/23/19 2:47 PM, Clayton Zekelman wrote: > > > > Find a new job. > > > > At 02:40 PM 23/08/2019, harbor235 wrote: > >> Hi noggers, > >> > >> First some background; > >> > >> I have inherited a real-time services delivery infrastructure that > >> while technically functional is absent of a wworking tiered > >> operational support structure. In addition, the infrastructure was > >> not implemented with technology best practices and has some remaining > >> single points of failure. T3/engineering handles engineering, > >> operational support, testing, and development. T1 and T2 perform some > >> tasks but not what is expected of a traditional support structure, As > >> we are attempting to scale our program our limitations are obvious. > >> > >> We are trying to scale the program and need to remedy all single > >> points of failure and implement technical and management best > >> practices. While we try to remedy all of the above, our customer > >> expects routine capability enhancements. > >> > >> Question(s) > >> 1) how to pivot to a tiered operational support structure and set > >> expectations for each tier level. How do I do that without having my > >> entire staff leave? > >>       Current staff is not a professional organization and are > >> used to a purely reactive state. > >> > >> 2) ITIL process are great and we have started to implement what makes > >> sense but I need a operational support stucture/model to support and > >> manage this effort. > >> > >> 3) How do you manage your engineering and operational projects? > >> Currently I am using Excel for all projects short and long term and > >> also use a seperate spreadsheet for my short term project sprints? > >> Basic project tracking with no mature processes involve. > >> > >> How are you pulling this all together? > >> > >> I would like to hire key positions that can bring essential > >> capabilities to my project but I am limited hiring new staff. > >> > >> thoughts, suggestions > >> > >> Mike > > -- > 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 harbor235 at gmail.com Fri Aug 23 21:32:28 2019 From: harbor235 at gmail.com (harbor235) Date: Fri, 23 Aug 2019 17:32:28 -0400 Subject: Tiered operations support In-Reply-To: References: <1566586032_85706@surgemail.mnsi.net> <91a047d3-55d6-4941-f043-cb40b0d32236@meetinghouse.net> Message-ID: Thank you for all your replies, I agree it is a culture change and we have made significant changes in the last 2 years. The changes we have made included letting some of the personnel move on which allowed me to realize some gains. Regarding ITIL, I made organizational changes to control the engineering work that is integrated to production by instituting an engineering review board and change control board for customer visibility and participation. It is also used to capture project intellectual property and to document testing and implementation plans. I believe I knew what noggers were going to say (though very much the same) but wanted validation, I am overwhelmed with the enormity of the required changes and the challenges of the customer interaction to approve of all changes. But we are making progress, I need to make a big pivot now to drive the organization into the correct model. thank you everyone for your replies, I value this community, if you have more thoughts please do not hesitate. Mike On Fri, Aug 23, 2019 at 5:04 PM Joshua Miller wrote: > Mike, > > You're essentially trying to change the culture of the organization. > Unless you have senior management buy-in, it will be pretty fruitless. > > Maybe while announcing the restructuring, offer bonuses to keep people > from leaving prematurely? People can adapt if the rate of change isn't too > high. > > Like others have said, turnover isn't bad as long as you can maintain > continuity of operations. Keep in mind, the highest performers are the most > mobile. > > Best, > Joshua > > On Fri, Aug 23, 2019 at 4:24 PM Miles Fidelman > wrote: > >> Both of those would be my first reactions. >> >> Or... depending on how "not professional" your staff is, you might >> consider sending them out for some training, or bringing someone in to do >> some training. >> >> Heck, you could challenge your your staff with "ok team, go figure out a >> more mature approach." >> >> Miles Fidelman >> >> >> ---harbor235 at gmail.com wrote: >> >> Maybe you want some of them to leave, if they're "not >> a professional organization". Get some fresh folks >> from professional minded organizations and see if >> the others quit being reactionary only and step up >> their game. >> >> and >> >> >> On 8/23/19 2:47 PM, Clayton Zekelman wrote: >> > >> > Find a new job. >> > >> > At 02:40 PM 23/08/2019, harbor235 wrote: >> >> Hi noggers, >> >> >> >> First some background; >> >> >> >> I have inherited a real-time services delivery infrastructure that >> >> while technically functional is absent of a wworking tiered >> >> operational support structure. In addition, the infrastructure was >> >> not implemented with technology best practices and has some remaining >> >> single points of failure. T3/engineering handles engineering, >> >> operational support, testing, and development. T1 and T2 perform some >> >> tasks but not what is expected of a traditional support structure, As >> >> we are attempting to scale our program our limitations are obvious. >> >> >> >> We are trying to scale the program and need to remedy all single >> >> points of failure and implement technical and management best >> >> practices. While we try to remedy all of the above, our customer >> >> expects routine capability enhancements. >> >> >> >> Question(s) >> >> 1) how to pivot to a tiered operational support structure and set >> >> expectations for each tier level. How do I do that without having my >> >> entire staff leave? >> >>       Current staff is not a professional organization and are >> >> used to a purely reactive state. >> >> >> >> 2) ITIL process are great and we have started to implement what makes >> >> sense but I need a operational support stucture/model to support and >> >> manage this effort. >> >> >> >> 3) How do you manage your engineering and operational projects? >> >> Currently I am using Excel for all projects short and long term and >> >> also use a seperate spreadsheet for my short term project sprints? >> >> Basic project tracking with no mature processes involve. >> >> >> >> How are you pulling this all together? >> >> >> >> I would like to hire key positions that can bring essential >> >> capabilities to my project but I am limited hiring new staff. >> >> >> >> thoughts, suggestions >> >> >> >> Mike >> >> -- >> 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 mehmet at akcin.net Sat Aug 24 04:07:41 2019 From: mehmet at akcin.net (Mehmet Akcin) Date: Fri, 23 Aug 2019 23:07:41 -0500 Subject: Asset management recommendations Message-ID: Hey there I am looking for a tool recommendation for network and server asset management which can scale in multiple sites and integrate with other platforms like nagios, librenms. Being able to do patch management is plus. Mostly linux and juniper shop Any recommendations? -- Mehmet +1-424-298-1903 -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.herbert at gmail.com Sat Aug 24 08:36:39 2019 From: george.herbert at gmail.com (George Herbert) Date: Sat, 24 Aug 2019 01:36:39 -0700 Subject: Asset management recommendations In-Reply-To: References: Message-ID: Do you really want asset management tools, or configuration management tools with asset discovery / inventory capability? Juniper supports Chef configuration management pretty extensively, and is widely used for systems management and patch management on Linux. Scales to multisite well. There are tie-ins to be able to export monitoring and alerting tool configurations based on server and network inventories, etc. https://www.juniper.net/documentation/en_US/junos-chef11.10/topics/concept/chef-overview.html There are also Puppet, Ansible, and Saltstack in this product space, slightly less well supported with Juniper as I understand it (haven't looked extensively, someone else may have better info). On Fri, Aug 23, 2019 at 9:10 PM Mehmet Akcin wrote: > Hey there > > I am looking for a tool recommendation for network and server asset > management which can scale in multiple sites and integrate with other > platforms like nagios, librenms. Being able to do patch management is plus. > Mostly linux and juniper shop > > Any recommendations? > > > -- > Mehmet > +1-424-298-1903 > -- -george william herbert george.herbert at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhellenthal at dataix.net Sat Aug 24 12:05:16 2019 From: jhellenthal at dataix.net (J. Hellenthal) Date: Sat, 24 Aug 2019 07:05:16 -0500 Subject: Asset management recommendations In-Reply-To: References: Message-ID: <267022A7-B25F-4F0F-AE8C-A4B54B1EC386@dataix.net> I would have to agree with this too. Unless you are looking at a multifaceted approach where you can compare two different sources of knowledge then use the config mgmt tools to cover that baseline is pretty adequate until.... You have client computers and hardware along that level to track. So in that instance since everything has an IP these days then phpIPAM or similar can do quite the job storing serial numbers, makes, models, descriptions and tracking the on and offline status plus plenty more. https://phpipam.net/documents/screenshots/ -- 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 Aug 24, 2019, at 03:37, George Herbert wrote: > >  > Do you really want asset management tools, or configuration management tools with asset discovery / inventory capability? > > Juniper supports Chef configuration management pretty extensively, and is widely used for systems management and patch management on Linux. Scales to multisite well. There are tie-ins to be able to export monitoring and alerting tool configurations based on server and network inventories, etc. > > https://www.juniper.net/documentation/en_US/junos-chef11.10/topics/concept/chef-overview.html > > There are also Puppet, Ansible, and Saltstack in this product space, slightly less well supported with Juniper as I understand it (haven't looked extensively, someone else may have better info). > >> On Fri, Aug 23, 2019 at 9:10 PM Mehmet Akcin wrote: >> Hey there >> >> I am looking for a tool recommendation for network and server asset management which can scale in multiple sites and integrate with other platforms like nagios, librenms. Being able to do patch management is plus. Mostly linux and juniper shop >> >> Any recommendations? >> >> >> -- >> Mehmet >> +1-424-298-1903 > > > -- > -george william herbert > george.herbert at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ray at oneunified.net Sat Aug 24 12:41:39 2019 From: ray at oneunified.net (Raymond Burkholder) Date: Sat, 24 Aug 2019 06:41:39 -0600 Subject: Asset management recommendations In-Reply-To: <267022A7-B25F-4F0F-AE8C-A4B54B1EC386@dataix.net> References: <267022A7-B25F-4F0F-AE8C-A4B54B1EC386@dataix.net> Message-ID: <7cb33385-a480-bae2-d9cb-01736a72b8c3@oneunified.net> Expanding further, there are those that use ansible for network management.  But I don't think it does well in scaling out for functionality.  I have used saltstack for network config and server builds, as it becomes the source of truth for the infrastructure, allowing for consistent upgrades and additions. Combining with something like netbox for infrastructure source of truth, one can build to spec, and then use something like rancid as an independent confirmation of 'build to spec'. I've been able to script builds to automatically boot a blank device via pxeboot, get an operating system and customized modules installed, restarted, automatically registered to receive the starting configuration, register against a check_mk/nagios based monitoring system, and for servers, to automatically create and build containers and their contents.  It greatly simplifies the maintenance and upgrade tasks in to repeatable and reproducible build solutions.  Plus the source of truth configuration files can be version controlled to provide a history infrastructure adjustments. What I like about saltstack and netbox, is that they are both based upon python, which is a relatively common skillset and a growing ecosystem. https://netbox.readthedocs.io/en/latest/ https://docs.saltstack.com/en/latest/ref/states/ On 2019-08-24 6:05 a.m., J. Hellenthal via NANOG wrote: > I would have to agree with this too. Unless you are looking at a > multifaceted approach where you can compare two different sources of > knowledge then use the config mgmt tools to cover that baseline is > pretty adequate until.... > > You have client computers and hardware along that level to track. So > in that instance since everything has an IP these days then phpIPAM or > similar can do quite the job storing serial numbers, makes, models, > descriptions and tracking the on and offline status plus plenty more. > > https://phpipam.net/documents/screenshots/ > > > -- >  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 Aug 24, 2019, at 03:37, George Herbert >> wrote: >> >>  >> Do you really want asset management tools, or configuration >> management tools with asset discovery / inventory capability? >> >> Juniper supports Chef configuration management pretty extensively, >> and is widely used for systems management and patch management on >> Linux.  Scales to multisite well.  There are tie-ins to be able to >> export monitoring and alerting tool configurations based on server >> and network inventories, etc. >> >> https://www.juniper.net/documentation/en_US/junos-chef11.10/topics/concept/chef-overview.html >> >> There are also Puppet, Ansible, and Saltstack in this product space, >> slightly less well supported with Juniper as I understand it (haven't >> looked extensively, someone else may have better info). >> >> On Fri, Aug 23, 2019 at 9:10 PM Mehmet Akcin > > wrote: >> >> Hey there >> >> I am looking for a tool recommendation for network and server >> asset management which can scale in multiple sites and integrate >> with other platforms like nagios, librenms. Being able to do >> patch management is plus. Mostly linux and juniper shop >> >> Any recommendations? >> >> >> -- >> Mehmet >> +1-424-298-1903 >> >> >> >> -- >> -george william herbert >> george.herbert at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nuclearcat at nuclearcat.com Sat Aug 24 19:01:34 2019 From: nuclearcat at nuclearcat.com (Denys Fedoryshchenko) Date: Sat, 24 Aug 2019 22:01:34 +0300 Subject: Reflection DDoS last week In-Reply-To: References: Message-ID: <00faabc85eebcd8db076a379dfae666f@nuclearcat.com> Hi, Same happened in Lebanon(country). Similar pattern: carpet bombing for multiple prefixes of specific ASN. I suspect it is a new trend in DDoS-for-hire, and ISP who did not install data scrubbing appliances will feel severe pain from such attacks, since they use SYN + ACK from legit servers. On 2019-08-21 22:44, Töma Gavrichenkov wrote: > Peace, > > Here's to confirm that the pattern reported before in NANOG was indeed > a reflection DDoS attack. On Sunday, it also hit our customer, here's > the report: > > https://www.prnewswire.com/news-releases/root-cause-analysis-and-incident-report-on-the-august-ddos-attack-300905405.html > > tl;dr: basically that was a rather massive reflected SYN/ACK carpet > bombing against several datacenter prefixes (no particular target was > identified). > > -- > Töma > > On Sat, Aug 17, 2019, 1:06 AM Jim Shankland > wrote: > >> Greetings, >> >> I'm seeing slow-motion (a few per second, per IP/port pair) syn >> flood >> attacks ostensibly originating from 3 NL-based IP blocks: >> 88.208.0.0/18 [1] >> , 5.11.80.0/21 [2], and 78.140.128.0/18 [3] ("ostensibly" because >> ... syn flood, >> and BCP 38 not yet fully adopted). >> >> Why is this syn flood different from all other syn floods? Well ... >> >> 1. Rate seems too slow to do any actual damage (is anybody really >> bothered by a few bad SYN packets per second per service, at this >> point?); but >> >> 2. IPs/port combinations with actual open services are being >> targeted >> (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs >> >> with those services running), implying somebody checked for open >> services first; >> >> 3. I'm seeing this in at least 2 locations, to addresses in >> different, >> completely unrelated ASes, implying it may be pretty widespread. >> >> Is anybody else seeing the same thing? Any thoughts on what's going >> on? >> Or should I just be ignoring this and getting on with the weekend? >> >> Jim > > > Links: > ------ > [1] http://88.208.0.0/18 > [2] http://5.11.80.0/21 > [3] http://78.140.128.0/18 From james.voip at gmail.com Sun Aug 25 02:15:28 2019 From: james.voip at gmail.com (james jones) Date: Sat, 24 Aug 2019 22:15:28 -0400 Subject: report domains found in malware distrabution Message-ID: just quick question: is the abuse emails still best way to report domains that are being used in malware scripts? or is there a more central place to report such things? -James -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at hypergeek.net Sun Aug 25 05:06:15 2019 From: john at hypergeek.net (John A. Kilpatrick) Date: Sat, 24 Aug 2019 22:06:15 -0700 Subject: Asset management recommendations In-Reply-To: <7cb33385-a480-bae2-d9cb-01736a72b8c3@oneunified.net> References: <267022A7-B25F-4F0F-AE8C-A4B54B1EC386@dataix.net> <7cb33385-a480-bae2-d9cb-01736a72b8c3@oneunified.net> Message-ID: Agreed. Current environment is a saltstack/netbox combo that's, shall we say, "in development". On Sat, Aug 24, 2019, at 5:43 AM, Raymond Burkholder wrote: > Expanding further, there are those that use ansible for network management. But I don't think it does well in scaling out for functionality. I have used saltstack for network config and server builds, as it becomes the source of truth for the infrastructure, allowing for consistent upgrades and additions. Combining with something like netbox for infrastructure source of truth, one can build to spec, and then use something like rancid as an independent confirmation of 'build to spec'. > > I've been able to script builds to automatically boot a blank device via pxeboot, get an operating system and customized modules installed, restarted, automatically registered to receive the starting configuration, register against a check_mk/nagios based monitoring system, and for servers, to automatically create and build containers and their contents. It greatly simplifies the maintenance and upgrade tasks in to repeatable and reproducible build solutions. Plus the source of truth configuration files can be version controlled to provide a history infrastructure adjustments. > > What I like about saltstack and netbox, is that they are both based upon python, which is a relatively common skillset and a growing ecosystem. > > https://netbox.readthedocs.io/en/latest/ > https://docs.saltstack.com/en/latest/ref/states/ > > > On 2019-08-24 6:05 a.m., J. Hellenthal via NANOG wrote: >> I would have to agree with this too. Unless you are looking at a multifaceted approach where you can compare two different sources of knowledge then use the config mgmt tools to cover that baseline is pretty adequate until.... >> >> You have client computers and hardware along that level to track. So in that instance since everything has an IP these days then phpIPAM or similar can do quite the job storing serial numbers, makes, models, descriptions and tracking the on and offline status plus plenty more. >> >> https://phpipam.net/documents/screenshots/ >> >> >> -- >> 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 Aug 24, 2019, at 03:37, George Herbert wrote: >>> >>> >>> Do you really want asset management tools, or configuration management tools with asset discovery / inventory capability? >>> >>> Juniper supports Chef configuration management pretty extensively, and is widely used for systems management and patch management on Linux. Scales to multisite well. There are tie-ins to be able to export monitoring and alerting tool configurations based on server and network inventories, etc. >>> >>> https://www.juniper.net/documentation/en_US/junos-chef11.10/topics/concept/chef-overview.html >>> >>> There are also Puppet, Ansible, and Saltstack in this product space, slightly less well supported with Juniper as I understand it (haven't looked extensively, someone else may have better info). >>> >>> On Fri, Aug 23, 2019 at 9:10 PM Mehmet Akcin wrote: >>>> Hey there >>>> >>>> I am looking for a tool recommendation for network and server asset management which can scale in multiple sites and integrate with other platforms like nagios, librenms. Being able to do patch management is plus. Mostly linux and juniper shop >>>> >>>> Any recommendations? >>>> >>>> >>>> -- >>>> >>>> Mehmet >>>> +1-424-298-1903 >>> >>> >>> -- >>> >>> -george william herbert >>> george.herbert at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From blakangel at gmail.com Sun Aug 25 15:53:07 2019 From: blakangel at gmail.com (blakangel at gmail.com) Date: Sun, 25 Aug 2019 08:53:07 -0700 Subject: report domains found in malware distrabution In-Reply-To: References: Message-ID: <5fc861e9-882a-5c08-096e-3182ab5667b9@gmail.com> james jones wrote on 8/24/2019 19:15: > just quick question: > > is the abuse emails still best way to report domains that are being > used in malware scripts? or is there a more central place to report > such things? > > -James I always submit to google for phish emails that use hacked sites: https://safebrowsing.google.com/safebrowsing/report_badware/?hl=en From askoorb+nanog at gmail.com Sun Aug 25 17:40:35 2019 From: askoorb+nanog at gmail.com (Alex Brooks) Date: Sun, 25 Aug 2019 18:40:35 +0100 Subject: report domains found in malware distrabution In-Reply-To: References: Message-ID: Hi, On Sun, 25 Aug 2019 at 03:17, james jones wrote: > > just quick question: > > is the abuse emails still best way to report domains that are being used in malware scripts? or is there a more central place to report such things? This may be more from a sysadmin perspective than network operations. However: - Microsoft has a URL reputation service as well as Google, it's called Windows Defender SmartScreen (https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-smartscreen/windows-defender-smartscreen-overview). This is used by default in Edge, IE, Exchange, Office365, Outlook,com etc - Windows comes with Windows Defender as part of the licence. - Windows Defender has an optional feature enablable by the sysadmin called Network Protection. Network Protection causes *all* HTTP(S) connections made by the system to be checked against the URL reputation list, regardless of a process is making the connection (https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/network-protection-exploit-guard). - Microsoft also shares malware information with other security organisations, so reporting to Microsoft can often also mean that security software from other vendors will start blocking the site (https://docs.microsoft.com/en-gb/windows/security/threat-protection/intelligence/cybersecurity-industry-partners). If you use Windows desktops/laptops in your business, enabling Network Protection can be useful. Likewise, because of the number of Windows machines out there (and the ubiquity of Exchange / Office365) reporting to Microsoft can also be useful, especially as other security organisations can get details of the submission and start blocking both the site and the malware. You can report to Microsoft by going to https://www.microsoft.com/en-us/wdsi/support/report-unsafe-site (also allows for bulk submissions) or https://feedback.smartscreen.microsoft.com/feedback.aspx?url= and putting the address you want to report after the =. You can also submit whole phishing (or spam) emails to Microsoft by using the addresses at https://docs.microsoft.com/en-gb/office365/SecurityCompliance/submit-spam-non-spam-and-phishing-scam-messages-to-microsoft-for-analysis. *phishing* sites are also collected by US-CERT at https://www.us-cert.gov/report-phishing. I have no idea what they actually do with them though. Alex From fergdawgster at mykolab.com Sun Aug 25 19:23:13 2019 From: fergdawgster at mykolab.com (Paul Ferguson) Date: Sun, 25 Aug 2019 12:23:13 -0700 Subject: IP Route Hijacking Bad Actor: AS57129/RU-SERVERSGET-KRSK, RU/Optibit LLC Message-ID: <447b944d-28d5-3dd4-d4a0-a1ff1cf3c91e@mykolab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Howdy, I'm soliciting any background information, anecdotes, shared experiences, previous evidence, etc. of bad behavior and/or IP route hijacking for this 'hijack factory', as I've heard it called privately. They are actively -- and illegitimately -- announcing prefixes which are (legitimately) allocated to other organizations, a couple of them are very large & well-known U.S. healthcare providers. I'd also be interesting in hearing suggestion on the course of action one of these organizations might take to make this stop.... Thanks in advance, - - ferg - -- Paul Ferguson Seattle, WA USA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAl1i4CEACgkQKJasdVTchbJVHAEA0s7Ej73VPQth2Rho4xwTnv8e qQFJ6SB+qulM1HFHoUgA/RXAL1BFJC3wq9GsXYJ4sqLSrje/gPm1JzVMeEJMTGlQ =r3mY -----END PGP SIGNATURE----- From creynolds at tsieda.com Sat Aug 24 14:54:32 2019 From: creynolds at tsieda.com (Chuck Reynolds) Date: Sat, 24 Aug 2019 10:54:32 -0400 Subject: Asset management recommendations In-Reply-To: References: Message-ID: <3DFF2903-F4FD-4CDE-BF4A-6DA09665085E@tsieda.com> Quali CLoudshell does this and much more. Give me a call or email and we can hook you up. 407-257-3069 Sent from my iPhone > On Aug 24, 2019, at 12:07 AM, Mehmet Akcin wrote: > > Hey there > > I am looking for a tool recommendation for network and server asset management which can scale in multiple sites and integrate with other platforms like nagios, librenms. Being able to do patch management is plus. Mostly linux and juniper shop > > Any recommendations? > > > -- > Mehmet > +1-424-298-1903 From creynolds at tsieda.com Sat Aug 24 14:55:23 2019 From: creynolds at tsieda.com (Chuck Reynolds) Date: Sat, 24 Aug 2019 10:55:23 -0400 Subject: Asset management recommendations In-Reply-To: References: Message-ID: <9AA3754B-023D-4441-9D2B-546BBAC62644@tsieda.com> Cisco and juniper both use CLoudShell for these activities. Sent from my iPhone > On Aug 24, 2019, at 4:36 AM, George Herbert wrote: > > Do you really want asset management tools, or configuration management tools with asset discovery / inventory capability? > > Juniper supports Chef configuration management pretty extensively, and is widely used for systems management and patch management on Linux. Scales to multisite well. There are tie-ins to be able to export monitoring and alerting tool configurations based on server and network inventories, etc. > > https://www.juniper.net/documentation/en_US/junos-chef11.10/topics/concept/chef-overview.html > > There are also Puppet, Ansible, and Saltstack in this product space, slightly less well supported with Juniper as I understand it (haven't looked extensively, someone else may have better info). > >> On Fri, Aug 23, 2019 at 9:10 PM Mehmet Akcin wrote: >> Hey there >> >> I am looking for a tool recommendation for network and server asset management which can scale in multiple sites and integrate with other platforms like nagios, librenms. Being able to do patch management is plus. Mostly linux and juniper shop >> >> Any recommendations? >> >> >> -- >> Mehmet >> +1-424-298-1903 > > > -- > -george william herbert > george.herbert at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at satchell.net Mon Aug 26 02:03:29 2019 From: list at satchell.net (Stephen Satchell) Date: Sun, 25 Aug 2019 19:03:29 -0700 Subject: DNS cache hold of SERVFAIL responses Message-ID: <370f447b-ee4a-4fd8-9ac9-09feeb0bfaa8@satchell.net> This is for any Google admin on this list: When you receive a SERVFAIL from a name server listed as authoritative for a given domain, how long is that negative look-up cached? When you receive a SERVFAIL from the root servers, how long is that negative lookup cached? Does Google follow RFC 2308? Is there a common cache for all resolvers, or do each resolver in your DNS server corps maintain a local cache? When a SOA (when you see one) says 14400 for the minimum TTL (or negative cache TTL) does Google honor that hold time? From sean at donelan.com Mon Aug 26 17:03:41 2019 From: sean at donelan.com (Sean Donelan) Date: Mon, 26 Aug 2019 13:03:41 -0400 (EDT) Subject: SLA language about monitoring route leaks and inter-connection issues Message-ID: Do any major ISPs have SLA language about monitoring inter-provider agreements for route hijacking, route leaks, address spoofing, and so on? I'm looking for something more proactive than waiting for a customer to notice a problem and open a trouble ticket. From ximaera at gmail.com Mon Aug 26 18:43:23 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 26 Aug 2019 21:43:23 +0300 Subject: SLA language about monitoring route leaks and inter-connection issues In-Reply-To: References: Message-ID: Peace, On Mon, Aug 26, 2019, 8:05 PM Sean Donelan wrote: > Do any major ISPs have SLA language about monitoring inter-provider > agreements for route hijacking, route leaks, address spoofing, and so on? > > I'm looking for something more proactive than waiting for a customer to > notice a problem and open a trouble ticket. > BWAHHHAHHAHAAHAHAAAA No. -- Töma > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Mon Aug 26 18:54:22 2019 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 26 Aug 2019 14:54:22 -0400 Subject: SLA language about monitoring route leaks and inter-connection issues In-Reply-To: References: Message-ID: <05865BE4-62FF-47CC-A830-2A73B956A241@puck.nether.net> Sean, > On Aug 26, 2019, at 2:43 PM, Töma Gavrichenkov wrote: > > Peace, > > On Mon, Aug 26, 2019, 8:05 PM Sean Donelan wrote: > Do any major ISPs have SLA language about monitoring inter-provider > agreements for route hijacking, route leaks, address spoofing, and so on? > > I'm looking for something more proactive than waiting for a customer to > notice a problem and open a trouble ticket. > > BWAHHHAHHAHAAHAHAAAA > > No. We do our own internal monitoring of our announcements for now. Our general reaction is to deactivate sites where this is seen and work to understand what happened. Most commonly we see things before our network partners are aware, including issues within their own networks. It has been improving over the years and I think we are steadily seeing more monitoring and measurement but there’s many subtle things we see. There’s a few well-known hijackers out there that need and will become depeered before too long, but mostly we see providers doing things they aren’t even aware they just did. The number of /30s and similar things that happen, but many events are just detour routing. - Jared From ximaera at gmail.com Mon Aug 26 19:04:38 2019 From: ximaera at gmail.com (=?UTF-8?Q?T=C3=B6ma_Gavrichenkov?=) Date: Mon, 26 Aug 2019 22:04:38 +0300 Subject: SLA language about monitoring route leaks and inter-connection issues In-Reply-To: <05865BE4-62FF-47CC-A830-2A73B956A241@puck.nether.net> References: <05865BE4-62FF-47CC-A830-2A73B956A241@puck.nether.net> Message-ID: Peace, On Mon, Aug 26, 2019, 9:54 PM Jared Mauch wrote: > We do our own internal monitoring of our announcements for now. Good for you and your customers! That is already a clear signal of an extraordinary service to your customers. Not to underestimate your effort which I respect, but the original question was about the SLA language for that. Do you have one, legally? Our general > reaction is to deactivate sites where this is seen and work to understand > what > happened. This is not clear to me, may I ask you to elaborate? Deactivating a site sounds like a local action while hijacking or leak is commonly an issue affecting either all or a lot of sites. -- Töma -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Aug 27 01:27:12 2019 From: owen at delong.com (Owen DeLong) Date: Mon, 26 Aug 2019 18:27:12 -0700 Subject: IP Route Hijacking Bad Actor: AS57129/RU-SERVERSGET-KRSK, RU/Optibit LLC In-Reply-To: <447b944d-28d5-3dd4-d4a0-a1ff1cf3c91e@mykolab.com> References: <447b944d-28d5-3dd4-d4a0-a1ff1cf3c91e@mykolab.com> Message-ID: <9E10D541-4700-4631-9D9D-8B9D87E40AE5@delong.com> Have no history/background that I can share. In terms of actions, this seems obvious, but… Look at the AS Paths fo the hijacked prefixes announced from 57129 and start with the second to last AS and work backwards asking that at least those prefixes from 57129 be rejected/filtered. Most legitimate providers faced with appropriate documentation of prefix registration in the relevant RIR will do the following: 1. Contact their customer/peer and ask them to stop announcing. 2. Install the necessary filters. 3. If 1 is not successful in a reasonable amount of time, potentially escalate to disconnection/depeering. Owen > On Aug 25, 2019, at 12:23 , Paul Ferguson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Howdy, > > I'm soliciting any background information, anecdotes, shared > experiences, previous evidence, etc. of bad behavior and/or IP route > hijacking for this 'hijack factory', as I've heard it called privately. > > They are actively -- and illegitimately -- announcing prefixes which > are (legitimately) allocated to other organizations, a couple of them > are very large & well-known U.S. healthcare providers. > > I'd also be interesting in hearing suggestion on the course of action > one of these organizations might take to make this stop.... > > Thanks in advance, > > - - ferg > > > - -- > Paul Ferguson > Seattle, WA USA > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iF4EAREIAAYFAl1i4CEACgkQKJasdVTchbJVHAEA0s7Ej73VPQth2Rho4xwTnv8e > qQFJ6SB+qulM1HFHoUgA/RXAL1BFJC3wq9GsXYJ4sqLSrje/gPm1JzVMeEJMTGlQ > =r3mY > -----END PGP SIGNATURE----- From fohdeesha at gmail.com Tue Aug 27 02:52:27 2019 From: fohdeesha at gmail.com (Jon Sands) Date: Mon, 26 Aug 2019 22:52:27 -0400 Subject: Looking for a Google contact (peering frustrations) Message-ID: AS397031 here, located in Telehouse (7 Teleport). We picked up a port on NYIIX specifically to peer with google and cloudflare. We were doing around 6gbps inbound from google over the NYIIX for some time then without warning google withdrew routes from us, I'm guessing because too much bandwidth over an IIX and they prefer a private interconnect at that point. So we requested to peer with them via a PNI and were denied, saying they can't do that either as they're not located in any Telehouse buildings. So I'm left with no Google peering A 10gb wave from where we are to the nearest google peering point is basically the same cost as 10gbps from HE, so trying to figure out my best options here. Open to suggestions! Ideally we would love to peer with google again over NYIIX if possible. -- Jon Sands MFI Labs https://fohdeesha.com/ From dylan at ambauen.com Tue Aug 27 19:40:16 2019 From: dylan at ambauen.com (Dylan Ambauen) Date: Tue, 27 Aug 2019 12:40:16 -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: Shall we change the subject to 44/9? Yes +1 Joe and Owen. HamWAN.org is a fantastic example. There are others in Miami and BC. Pnwdigital.net trunks MotoTrbo DMR repeaters over HamWan. 44net is a wonderful resource. Thank you Brian Kantor and John Hayes and all the other AMPR volunteers. Dylan Ambauen KI7SBI On Wed, Jul 24, 2019, 07:19 Joe Hamelin wrote: > 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 sean at donelan.com Tue Aug 27 21:50:01 2019 From: sean at donelan.com (Sean Donelan) Date: Tue, 27 Aug 2019 17:50:01 -0400 (EDT) Subject: Facebook launches alerts for local first responders Message-ID: Facebook announced its new Local Alerts feature. Potential uses include storm warnings and advisories for extreme temperatures, evacuations, road closures, active shooter situations, bomb threats, missing person reports, water main breaks and more. The aim is to keep its users “safe and in-the-know.” https://www.washingtonpost.com/weather/2019/08/27/facebook-launching-local-alerts-keep-you-safe-during-emergencies-including-severe-weather/ The Facebook Local Alerts appears to be a closed, walled-garden system, requiring local emergency managers to setup and maintain Facebook accounts. Emergency managers have used multiple social media platforms for several years, but its always a bit hit&miss reaching the public using different platforms. Smart assistants like Alexia, Google Assistant, Apple Siri or streaming services like Netflix and Hulu don't don't proactively provide local emergency alerts like Cable, TV and radio broadcasters. If you need to ask Alexa if there is a tornado warning, you probably already know there is a tornado. From damian at google.com Tue Aug 27 23:23:19 2019 From: damian at google.com (Damian Menscher) Date: Tue, 27 Aug 2019 16:23:19 -0700 Subject: Reflection DDoS last week (was: syn flood attacks from NL-based netblocks) In-Reply-To: References: Message-ID: On Wed, Aug 21, 2019 at 3:21 PM Töma Gavrichenkov wrote: > On Thu, Aug 22, 2019 at 12:17 AM Damian Menscher > wrote: > > Some additional questions, if you're able to answer them (off-list is > fine if there are things that can't be shared broadly): > > - Was the attack referred to law enforcement? > > It is being referred to now. This would most probably get going under > the jurisdiction of the Netherlands. > Deeper analysis and discussion indicates there were several victims: we saw brief attacks targeting some of our cloud customers with syn-ack peaks above 125 Mpps; another provider reported seeing 275Mpps sustained. So presumably there are a few law enforcement investigations under way, in various jurisdictions. > - Were any transit providers asked to trace the > > source of the spoofing to either stop the attack > > or facilitate the law enforcement investigation? > > No.... tracing the source was not deemed a high priority task. > Fair enough. I just didn't want to duplicate effort. The source of the spoofing has been traced. The responsible hosting provider has kicked off their problem customer, and is exploring the necessary filtering to prevent a recurrence. If anyone sees more of this style of attack please send up a flare so the community knows to track down the new source. Damian -------------- next part -------------- An HTML attachment was scrubbed... URL: From fohdeesha at gmail.com Wed Aug 28 00:32:25 2019 From: fohdeesha at gmail.com (Jon Sands) Date: Tue, 27 Aug 2019 20:32:25 -0400 Subject: Looking for a Google contact (peering frustrations) In-Reply-To: References: Message-ID: <5a666f69-95be-8964-360a-7ec965548489@gmail.com> Fixed off list by (several) google employees. Thanks! On 8/26/2019 10:52 PM, Jon Sands wrote: > AS397031 here, located in Telehouse (7 Teleport). We picked up a port > on NYIIX specifically to peer with google and cloudflare. We were > doing around 6gbps inbound from google over the NYIIX for some time > then without warning google withdrew routes from us, I'm guessing > because too much bandwidth over an IIX and they prefer a private > interconnect at that point. So we requested to peer with them via a > PNI and were denied, saying they can't do that either as they're not > located in any Telehouse buildings. So I'm left with no Google peering > > A 10gb wave from where we are to the nearest google peering point is > basically the same cost as 10gbps from HE, so trying to figure out my > best options here. Open to suggestions! Ideally we would love to peer > with google again over NYIIX if possible. > -- Jon Sands MFI Labs https://fohdeesha.com/ From ross at tajvar.io Wed Aug 28 00:35:34 2019 From: ross at tajvar.io (Ross Tajvar) Date: Tue, 27 Aug 2019 20:35:34 -0400 Subject: Looking for a Google contact (peering frustrations) In-Reply-To: <5a666f69-95be-8964-360a-7ec965548489@gmail.com> References: <5a666f69-95be-8964-360a-7ec965548489@gmail.com> Message-ID: What was the outcome? On Tue, Aug 27, 2019, 8:35 PM Jon Sands wrote: > Fixed off list by (several) google employees. Thanks! > > On 8/26/2019 10:52 PM, Jon Sands wrote: > > AS397031 here, located in Telehouse (7 Teleport). We picked up a port > > on NYIIX specifically to peer with google and cloudflare. We were > > doing around 6gbps inbound from google over the NYIIX for some time > > then without warning google withdrew routes from us, I'm guessing > > because too much bandwidth over an IIX and they prefer a private > > interconnect at that point. So we requested to peer with them via a > > PNI and were denied, saying they can't do that either as they're not > > located in any Telehouse buildings. So I'm left with no Google peering > > > > A 10gb wave from where we are to the nearest google peering point is > > basically the same cost as 10gbps from HE, so trying to figure out my > > best options here. Open to suggestions! Ideally we would love to peer > > with google again over NYIIX if possible. > > > > -- > Jon Sands > MFI Labs > https://fohdeesha.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fohdeesha at gmail.com Wed Aug 28 01:08:35 2019 From: fohdeesha at gmail.com (Jon Sands) Date: Tue, 27 Aug 2019 21:08:35 -0400 Subject: Looking for a Google contact (peering frustrations) In-Reply-To: References: <5a666f69-95be-8964-360a-7ec965548489@gmail.com> Message-ID: <8f15c869-78fc-6048-cb4c-acc952a29df1@gmail.com> It seems they accidentally stopped sending any prefixes at all to the IIX and we were somehow the only ones to notice - that's been fixed. Also was offered a cache appliance since we're approaching near 10gbps of youtube traffic. Very happy with how it turned out On 8/27/2019 8:35 PM, Ross Tajvar wrote: > What was the outcome? > > On Tue, Aug 27, 2019, 8:35 PM Jon Sands > wrote: > > Fixed off list by (several) google employees. Thanks! > > On 8/26/2019 10:52 PM, Jon Sands wrote: > > AS397031 here, located in Telehouse (7 Teleport). We picked up a > port > > on NYIIX specifically to peer with google and cloudflare. We were > > doing around 6gbps inbound from google over the NYIIX for some time > > then without warning google withdrew routes from us, I'm guessing > > because too much bandwidth over an IIX and they prefer a private > > interconnect at that point. So we requested to peer with them via a > > PNI and were denied, saying they can't do that either as they're > not > > located in any Telehouse buildings. So I'm left with no Google > peering > > > > A 10gb wave from where we are to the nearest google peering > point is > > basically the same cost as 10gbps from HE, so trying to figure > out my > > best options here. Open to suggestions! Ideally we would love to > peer > > with google again over NYIIX if possible. > > > > -- > Jon Sands > MFI Labs > https://fohdeesha.com/ > -- Jon Sands MFI Labs https://fohdeesha.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Aug 28 03:52:19 2019 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Aug 2019 20:52:19 -0700 Subject: 44/8 In-Reply-To: References: <20190719025758.GB29374@puck.nether.net> Message-ID: <5AF8C324-8AB5-47E8-B903-512083D87CF1@delong.com> > On Jul 26, 2019, at 21:59 , Doug Barton wrote: > > 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? > Certainly part of my anger is that I did not know some of them were happening. However, most of my anger is around the fact that: 1. It never in a million years would have occurred to me that these people who I also consider friends and also trust explicitly would take this particular action without significant prior (and much wider) consultation with the amateur radio community. 2. I believe this was done quietly and carefully orchestrated specifically to avoid any risk of successful backlash by the time the community became aware of this particular intended action. If you want to say shame on us for trusting these people and not noticing the severe corporate governance problems with ARDC until they took this particular action, then I suppose that’s a fair comment. > 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? > All of those are good questions. I don’t have data to answer any of them other than that removing a /10 from a /8 is obviously a 25% reduction in the total space, so clearly a somewhat larger (though I don’t know by how much) reduction in available space since available space is some fraction of the remaining 1.5 /9s. > 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? > Taking another look is not at all out of line. Discarding 25% of it before letting the community in question on a broader scale take a look is absolutely very far out of line IMHO. > 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. > In actual fact, had the ARDC board approached the broader amateur radio community with a plan to sell the space, it’s entirely likely that I would have lent my support to the plan. That does not change the fact that I feel it was beyond their mandate and out of line for them to take the action first and neither consult the community before nor after. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Wed Aug 28 06:27:08 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 27 Aug 2019 23:27:08 -0700 Subject: The Curious Case of 143.95.0.0/16 Message-ID: <80277.1566973628@segfault.tristatelogic.com> Fair Warning: Those of you not enamored of my long-winded exposés of various remarkable oddities of the IPv4 address space may wish to click on the tiny little wastebasket icons on your mail clients at this point. For the rest of you, please read on. I think you may find the following story intriguing. It contains at least a few surprising twists. +_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ Our story today consists of three acts. Act 1 - It is Born ------------------ In mid-February of 1990 a new venture-capital backed company was formed in Sunnyvale, California. In some ways it was no different than the hundreds or thousands of hopeful high-tech startups that had been formed in Silicon Valley, both before and since. It started with a hopeful dream that, in the end, just didn't work out. The founders of this company settled initially on a temporary placeholder company name, XYZ Corporation: https://drive.google.com/file/d/1CkDNKq4M1DQKuTxBBhlYxUNAjU2cvDnY/view The mission of the company was to design and manufacture so-called X-Windows terminals. These would be diskless workstations, complete with CPUs, color (CRT) displays, graphics, memory, and an ethernet interface. The basic idea what that such a diskless workstation could run the free X-Windows client software, and that the system would be cheaper than ordinary PeeCees due to it not having any hard drives or optical drives. By some odd twist of fate, I myself was working in the same geographic area as a software engineer at around the same time, but I worked for a different Silicon Valley startup, just down the road from XYZ Corporation. And by a rather remarkable coincidence, the company I worked for had exactly the same goal and mission as the XYZ Corporation. The name of this other X-Windows workstation startup was Network Computing Devices, or just "NCD" for short. Quite obviously, both companies were inherently "network-centric" and thus, both requested and were granted blocks of IPv4 addresses. That wasn't at all within my area of responsibility at NCD, so I don't know who actually issued those blocks. My guess, based on published historical accounts, was that it was most probably Dr. Jon Postel who assigned the blocks. I'm sure that someone will correct me if I'm wrong. Months passed, and eventually the founders of XYZ Corporation settled on something they would use as a permanent replacement for their temporary placeholder corporate name. They decided to call the thing Athenix, Inc. Once they had settled on that name, they filed papers to update their records with the California Secretary of State's office: https://drive.google.com/file/d/1dUjsvSkzzdzUsIbIZCS7RF0afsI3uU0l/view At some point, they also and likewise updated the ARIN WHOIS record for the /16 block which had been assigned to them, on or about 1990-09-06, as was appropriate to reflect their new permanent corporate identity: https://pastebin.com/raw/YbH6zYrR More time passed and eventually it became clear that the entire world was not in fact breathlessly waiting for -two- companies to bring to market diskless X-Windows workstations. In fact, as history now shows, market demand would not support even one such company over the long term. Thus it came to pass in the year 1993 that an all-too-familiar end-of-life ritual played out once again in Silicon Valley. At Athenix, Inc. HQ in Sunnyvale, the people were all let go, including the founders. The desks, the chairs, the phones, the computers, and the tools were all sold at auction, with the proceeds going to the preferred shareholders, i.e. the poor fools who had put up all of the money for this now-failed venture in the first place, the venture capitalists. Foremost among those in this instance, was the venerable Menlo Park venture capital firm Kleiner Perkins. I've confirmed this historical account of the rise and fall of the original 1990-vintage Athenix, Inc. in multiple phone and email exchanges with both the original CEO of the original Athenix, Mr. Robert ("Bob") Garrow. lately of Los Altos, California, and also the original CTO of the company, Mr. John Garman, lately of Reno, Nevada. Act 2 - Rebirth - The Athenix Phoenix ------------------------------------- Fast forward fifteen years. On April 22, 2008 a pair of gentlemen in the Commonwealth of Massachusetts elected to establish a new corporate entity within the commonwealth. It's name would be Athenic, Inc.[1] https://drive.google.com/file/d/1jYUqtgYprI4iyJkTT91-yRBYJt0c2ufF/view https://drive.google.com/file/d/1mlVML8z7vzp7aeGmOK-3cWBBJeNBuThn/view As you can see in the documents above, a certain Mr. Ofer Inbar and a certain Mr. Robert Anita, both of the greater Boston area, formed this new corporate entity in Massachusetts. At its formation, the younger Mr. Inbar was the President, while the more senior Mr. Antia served as the corporate secretary and treasurer. Various other records, which I shall not include here, suggest that both Mr. Inbar and Mr. Anita were at some point in the distant past affiliated, in at least some tangential way, with the well-regarded white-hat Boston area hacking collective known as L0pht, aka L0pht Heavy Industries. I cannot say much about this apparent connection, other than to say that the details I have ferreted out about this connection are sketchy at best. I do however have it on reasonably good authority that Mr. Inbar has of late relocated to the greater Seattle metropolitan area, and that he is or was working as a network administrator for Google, Inc. in that area. Mr. Antia, in contrast, is still, when I last checked, a resident of the greater Boston area, and is a well regarded "graybeard" in the computing community in and around Boston, having been in the business, one way or another, for decades. Mr. Anita currently serves as President of the Boston area chapter of the public/private critical infrastructure cybersecurity defense partnership known as InfraGuard. https://infragard-boston.org/ The evidence currently available to me suggests that not long after the creation of Mr. Inbar's and Mr. Antia's Massachusetts Athenix, Inc., ARIN elected to delegate responsibility for the reverse DNS for the 143.95.0.0/16 IPv4 block to a pair of name servers called dns1.athenixinc.com and dns2.athenixinc.com. That delegation was already in place by 2010-06-24, which is about the time that Farsight Security Inc., my data source, first began passively collecting its historical archives of DNS response records. Historical records made available to me by Domaintools, LLC indicate that the athenixinc.com domain name was, at least initially, registered to Mr. Anita in Lincoln, Massachusetts. https://pastebin.com/raw/GNhbFDFz Subsequent historical WHOIS data collected by Domaintools in relation to the athenixinc.com domain name shows that after Mr. Anita, the domain name registration passed into the hands of at least one other individual, and eventually, to an entirely different corporate entity. We will come to that shortly. Almost a year ago now, when I was first investigating the 143.95.0.0/16 block, I attempted to interview Mr. Inbar by phone regarding his and Mr. Anita's Athenix, Inc. and the unusual history of the 143.95.0.0/16 block. It did not go well. Mr. Inbar was apparently reluctant to engage with me by phone on these or any other topics. He and I did have a few brief and truncated email exchanges after that however, but apparently my questions regarding how Mr. Inbar and Mr. Anita came to exercise effective day-to-day control over the 143.95.0.0/16 ARIN legacy block were not ones that Mr. Inbar felt in any way obliged to answer, and at some point he simply ceased answering my emails. In contrast, Mr. Antia was a veritable fount of information and he and I had multiple phone conversations as well as multiple email exchanges. From these exchanges I quickly deduced that Mr. Antia saw absolutely nothing wrong with, much less anything at all to be shy about with respect to the history of the 143.95.0.0/16 block -or- his formation, along with Mr. Inbar, of a new Athenix, Inc. in Massachusetts back in in 2008. Quite the contrary! Mr. Anita was kind enough for forward me a copy of the following really rather remarkable lease agreement, in which Mr. Inbar and Mr. Anita together undertook to lease the 143.95.0.0/16 IPv4 block to a certain Nevada- incorporated and Colorado-resident limited liability company known as Media Breakaway, LLC: https://drive.google.com/file/d/1ASXrUsiNAIq1IIZO5Lw1BqjD1qucqFmI/view As you can see, the term of the lease is 20 years, beginning from the 28th day of May, 2008. The compensation to be paid to Mr. Inbar's and Mr. Anita's Massachusetts Athenic, Inc. in return for this 20 year leasehold was to be $100,000 USD As Mr. Anita related to me, this sum was in fact paid, and Mr. Inbar and Mr. Anita split it evenly. (But of course, I have no way to independently verify that.) For those unaware, I pause here just long enough to note that the CEO of Media Breakaway, LLC is none other than Mr. Scott Richter, one-time "Spam King" and a man who both Wikipedia and the KrebsOnSecurity blog have asserted is a convicted felon. And of couurse, this is the very same Scott Richter who figured so prominently in Brian Krebs' report about pilfered legacy ARIN /16 blocks, published on the Washington Post, way back in April, 2008. Of course, in my phone conversations with Mr. Anita, I acquainted him with these relevant historical allegations. He confessed at the time that he had not personally done much at all in the way of due diligence with respect to either Mr. Richter or his company -- a lapse which I personally found (and find) quite unfortunate, to say the least, and not least because of Mr. Anita's position as the President of the Boston Chapter of Infraguard, the public/private partnership whose mission is the protection of the nation's critical infrastructure assets from cyber-threats. I would have hoped that a person in such a position would have been in the general habit of exercising at least some due diligence with respect to the people he does business with and, in this specific instance, preferably at some moment *before* Mr. Anita cashed his $50,000 check. Act 3 - Final Dispensation -------------------------- Now we come to the final remarkable chapter in the already remarkable history of the 143.95.0.0/16 legacy IPv4 ARIN address block. Some months after the formation of the Massachusetts "Athenix, Inc.", on Sepetember 2nd, 2008 a new corporate entity calling itself "Athenix Corporation" was incorporated in the State of California. Curiously, this third Athenix gave both its actual address and its mailing address as 10 Corporate Drive, Burlington, MA 01813. https://drive.google.com/file/d/1GHhwuPGPKdx5n46cYQ2UhTGiMSdxonFu/view https://drive.google.com/file/d/1ZLtcY2HWoi5vmNFAJleHep8DxIS3igVR/view As it happens, that street address is also the headquarters address of the publicly-traded Endurance International Group, Inc. (EIGI). There is substantial evidence indicating that EIGI is effectively in complete functional control of the 143.95.0.0/16 address block at the present moment. The company's primary ASN, AS29873 and also, an AS number belonging to one of the company's many acquired subsidiaries, A Small Orange LLC, AS62729 are each routing significant portions of the 143.95.0.0/16 block at the present time. https://bgp.he.net/AS29873#_prefixes https://bgp.he.net/AS62729#_prefixes Additionally, on or about 2017-05-22, EIGI became the registrant of the athenixinc.com domain, whose associated name servers (dns1 dns2) had provided revserse DNS service for the entire 143.95.0.0/16 block during 2011 and 2012. Delegation of the reverse DNS responsibility for the entire 143.95.0.0/16 block changed on or about 2013-11-28 so that the new name servers were ones associated with the domain name asonoc.com, at least according to the relevant historical data provided to me by Farsight Security, Inc. https://pastebin.com/raw/MVmzhirc Historically, and as recently as 2018-04-20, the domain name asonoc.com was and has been registered to the EIGI subsidiary A Small Orange LLC. https://pastebin.com/raw/Xy8UHZNw Responsibility for the reverse DNS for the entire 143.95.0.0/16 block remains delegated to the rdns1.asonoc.com and rdns2.asonoc.com name servers at the present moment. EIGI is primarily a web hosting company. It has, over time. exhibited a tendency to acquire other and smaller web hosting companies which it has then absorbed into and under its corporate unbrella. Unlike most other corporate acquirers however, EIGI is somewhat unique in its notable tendency to not rebrand its acqusitions so that they would be additive to its main corporate brand, generally electing instead to maintain the pre-acqusition brand names for its newly acquired web hosting businesses. One such EIGI- acquired propery that has retained its pre-acqusition brand name is the aforementioned Texas-based web hosting company called A Small Orange LLC, aka AS62729. (Those who may be interested in more backgound regarding EIGI and past controversies, specifically with relating to the company's accounting practices as well as the online activities of its clientele, are encouraged to consult the footnotes below.[2]) The available evidence suggests the clear possibility that EIGI and its subsidiary, A Small Orange LLC. may be controling and using the 143.95.0.0/16 block in a manner inconsistant with ordinary business rules of fair dealing and/or in a manner inconsistant with current ARIN policy, and further, that the company and/or its various C-suite officers may have arrived at this current situation not by happentance but rather by some very carefully considered premeditation. I mention specifically EIGI's C-suite officers, because the available evidence suggests that EIGI's apparent takeover of the 143.95.0.0/16 block was not purely or only the product of some unsanctioned rogue activity on the part of lower-level company functionaries. Multiple publicly available records obtained from the web site of the California Secretary of State implicate multiple current and former EIGI C-suite officers as having been, at the very least, directly aware of the formation of the third "Athenix", even if perhaps not directly or personally responsible for that rather suspicious company formation. https://drive.google.com/file/d/12gm41jG9iFIC9KvIJmfWNjUqCmRtTfxN/view https://drive.google.com/file/d/1zdhru_hpYVIJfVKi-s5X1MW0znrErJzQ/view https://drive.google.com/file/d/1dVHDSPKD4Qvur9rzCK9YZDEtOkFA2raS/view Plese note that Mr. Hari Ravichandran is the now-former CEO of EIGI. Mr. David Bryson was and remains EIGI's Chief Legal Officer. Mr. Marc Montagner was and remains EIGI's Chief Financial Officer. Mr. Jeffrey Fox is EIGI's current CEO, having succeded Mr. Ravichandran in that post. https://www.endurance.com/our-company/our-team https://exechange.com/7850/endurance-ceo-hari-ravichandran-leaves-2/7850 https://www.linkedin.com/in/hari-ravichandran-9b949b8 https://jumpv.com/meet-the-team/ https://www.linkedin.com/in/davidbryson https://www1.salary.com/David-C-Bryson-Salary-Bonus-Stock-Options-for-ENDURANCE-INTL-GRP-HLDGS-INC.html https://www.linkedin.com/in/marc-montagner-b112a1b1 https://wallmine.com/people/6106/marc-montagner https://www.linkedin.com/in/jeff-fox-820a0413 https://wallmine.com/people/2962/jeffrey-h-fox Given that EIGI's rights in and/or legal title to the 143.95.0.0/16 block appear to be, at best, on somewhat shaky ground, and given that the new 2008-vintage Athenix Corporation does not obviously possess any other obvious or apparent assets to speak of, it appears, to this writer at least, more than a little incongruous to see that EIGI apparently listed Athenix Corporation as a collateral asset on what, to a layman such as myself, appears to be a bank collateral statement which was filed, apparently in 2013, with the United States Securities and Exchange Comission. https://www.sec.gov/Archives/edgar/data/1237746/000119312514077774/d635170dex1025.htm All I can say about that is that I personally was turned down for a bank loan, some years ago, when I attempted to use the monthly -liability- of my recurring water bills as collateral for the loan. But then I have never been anywhere near as accomplished at high finance as any of the gentlemen mentioned above surely are. Responses --------- More than 24 hours prior to posting this message, I reached out to the press contact email address listed on EIGI's web site, press (at) endurance.com, for comment about the facts elaborated above. No response was received from the company by press time. Prior to posting, I also reached out to John Curran @ ARIN for his response to the facts set forth above. John was kind enough to provide the following official on-the-record ARIN response: ARIN does not comment on specific registry changes (as number resource change requests are made in confidence), but we do take matters of potential number resource fraud quite seriously. I would recommend that you report potential incidents of registry fraud (if you have not done so already) via our Internet Number Resource Fraud Reporting process at https://www.arin.net/resources/fraud/, and we will promptly investigate. – John Curran, CEO, ARIN +_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ FULL DISCLOSURE: I hold no postions, either short or long in EIGI or in any related company. +_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ Acknowledgements ---------------- My thanks to Farsight Security, Inc. and to Domaintools, LLC for their kind support of this research. Footnotes: ======================================================================= [1] Rather remarkably, the Massachusetts Athenix, Inc. was incorporated a mere six days before my friend, journalist Brian Krebs, put up a story on the Washington Post web site, detailing how a pair of legacy ARIN IPv4 /16 blocks had somewhat inexplicably ended up in the hands of one of the world's most notorious spammers, Scott Richter. That story, as some of you will already know, alleged that a rather simple and yet elaborate fraud had been perpetrated against ARIN, a fraud which amounted to nothing less than corporate identity theft, with the one and only apparent goal being the effective take-over of two quite valuable legacy ARIN IPv4 /16 blocks, a goal which was, it appeared, successfully achieved with only a relatively minor investment of effort and expense. [2] In recent years, all has not gone well for EIGI. In the year 2015, a somewhat mysterious New York City short seller using the pen name Gotham City Research published a sequence of four reports detailing his beliefs that all was not as it should be at EIGI, both with respect to the company's financial statements and with respect to its clientele and their (allegedly) questionable online activities. 2015-04-28 - Endurance International Group - A Web of Deceit https://bit.ly/2KZXPLA 2015-04-29 - Initial Follow-up To: A Web of Deceit https://bit.ly/2L5Vv4o 2015-05-05 - EIGI’s Adjusted EBITDA is a Meaningless Metric https://bit.ly/342x4xE 2015-08-03 - Endurance International Group: Malicious Activities https://bit.ly/30Gk4vr The value of EIGI stock dropped rather precepitously following the publication of the Gotham City Research reports and has yet to recover to its earlier highs. https://drive.google.com/file/d/1BaGzFglnrbAca9DsRIqt2eD0m_jnrCMw/view The SEC's investigation of EIGI, and the SEC's subsequent enforcement actions against the company and its officers in 2018 also didn't help matters much with respect to EIGI and its stock price: https://www.sec.gov/enforce/33-10504-s https://www.bizjournals.com/boston/news/2018/08/22/former-endurance-group-execs-pay-1-4m-to-settle.html From Bryan at bryanfields.net Wed Aug 28 06:50:27 2019 From: Bryan at bryanfields.net (Bryan Fields) Date: Wed, 28 Aug 2019 02:50:27 -0400 Subject: 44/8 In-Reply-To: <5AF8C324-8AB5-47E8-B903-512083D87CF1@delong.com> References: <20190719025758.GB29374@puck.nether.net> <5AF8C324-8AB5-47E8-B903-512083D87CF1@delong.com> Message-ID: <46aff4fc-593e-4ef4-b4bd-767dfbd60ab9@bryanfields.net> On 8/27/19 11:52 PM, Owen DeLong wrote: >> On Jul 26, 2019, at 21:59 , Doug Barton wrote: >> 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 will say most people ignored them, as TBQH, nothing changes in amateur radio until people die. ARDC finally allocated space, got reverse DNS working, and basically did nothing else. It was a technical org doing nothing of any real value. I had brought up the issues of governance numerous times, and said it didn't look right to have people on the board with conflicts, or even licensed amateurs. There were other personnel issues brought up as well and no action was taken. If was an org doing the bare minimums and we got what we needed from it, so why rock the boat? > However, most of my anger is around the fact that: 1. It never in a million > years would have occurred to me that these people who I also consider > friends and also trust explicitly would take this particular action without > significant prior (and much wider) consultation with the amateur radio > community. > > 2. I believe this was done quietly and carefully orchestrated specifically > to avoid any risk of successful backlash by the time the community became > aware of this particular intended action. Bingo. > If you want to say shame on us for trusting these people and not noticing > the severe corporate governance problems with ARDC until they took this > particular action, then I suppose that’s a fair comment. Many know these people, and you cannot let that acquaintance cloud your judgment here. If these were people you did not know and they did this, you'd call it what it is. If an acquaintance does the same action, is it not the same? Does it pass the smell test that 44/8 was used, with no benefit to ARDC by CAIDA? This use held back deployment of 44/8 for years by the amateur users. Does it smell funny that the majority of the board members of ARDC were CAIDA board members? >> 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? >> >> > All of those are good questions. I don’t have data to answer any of them > other than that removing a /10 from a /8 is obviously a 25% reduction in > the total space, so clearly a somewhat larger (though I don’t know by how > much) reduction in available space since available space is some fraction > of the remaining 1.5 /9s. Based on the way this was handled we suspect it was part of an unsolicited offer by the buyer. If an organization decided to sell off 1/4 of it's assets and start a charitable giving process, the first thing done would be define the charitable giving areas and process. Get your house in order, build up a board full of talented people aligned with this new mission, and then effect the sale, no? Considering ARDC is only giving to IRS approved 501c3 organizations, the sale of the part of the space dedicated to non-US use (44.128.0.0/9) doesn't seem right. Seems like if you're going to sell space not for use in the US, you should have a plan to benefit those who it was taken from, no? The first inkling of any of this was reverse DNS for 44/8 users was broken. Mail was rejected, and people started to ask questions. There was no consultation of anyone with technical clue on this. Had there been, we could have prevented a 5+ day outage. I think we all get that '44.in-addr.arpa. NS $SERVERS' would need to move to the next byte boundary in configuration. Sure, it's 192 new records that need to be made at ARIN, and even if they can't script it, it's an hour or two of typing in the ARIN portal. Based on the absolute secrecy this was done with and the lack of process or thinking that went into it, I have to think it was an unsolicited bid, and likely negotiated by ARDC personal lacking real-world business savvy. >> 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? >> > Taking another look is not at all out of line. Discarding 25% of it before > letting the community in question on a broader scale take a look is > absolutely very far out of line IMHO. While I never knew Jon personally, I can't think he would have expected the value of IPv4 space either. I can only think his allocation policies would have been much more different. > In actual fact, had the ARDC board approached the broader amateur radio > community with a plan to sell the space, it’s entirely likely that I would > have lent my support to the plan. That does not change the fact that I feel > it was beyond their mandate and out of line for them to take the action > first and neither consult the community before nor after. This has been my position all along. A discussion should have been had. There was no pressing reason it had to be done right now. Based on my personal discussion with Brian Kantor in 2014, he was 100% against selling, or even leasing it as he stated ARDC merely was the custodian of the space for amateur use. I can't think what changed, other than his employment situation. "They drove a dump-truck full of money up to my house, I'm not made of stone!" -- Herschel Krustofsky -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net From nuclearcat at nuclearcat.com Wed Aug 28 10:51:45 2019 From: nuclearcat at nuclearcat.com (Denys Fedoryshchenko) Date: Wed, 28 Aug 2019 13:51:45 +0300 Subject: Reflection DDoS last week In-Reply-To: References: Message-ID: <91b9baabf0d0241d533b7abdbe426a6a@nuclearcat.com> On 2019-08-28 02:23, Damian Menscher via NANOG wrote: > On Wed, Aug 21, 2019 at 3:21 PM Töma Gavrichenkov > wrote: > >> On Thu, Aug 22, 2019 at 12:17 AM Damian Menscher >> wrote: >>> Some additional questions, if you're able to answer them (off-list >> is fine if there are things that can't be shared broadly): >>> - Was the attack referred to law enforcement? >> >> It is being referred to now. This would most probably get going >> under >> the jurisdiction of the Netherlands. > > Deeper analysis and discussion indicates there were several victims: > we saw brief attacks targeting some of our cloud customers with > syn-ack peaks above 125 Mpps; another provider reported seeing 275Mpps > sustained. So presumably there are a few law enforcement > investigations under way, in various jurisdictions. > >>> - Were any transit providers asked to trace the >>> source of the spoofing to either stop the attack >>> or facilitate the law enforcement investigation? >> >> No.... tracing the source was not deemed a high priority task. > > Fair enough. I just didn't want to duplicate effort. > > The source of the spoofing has been traced. The responsible hosting > provider has kicked off their problem customer, and is exploring the > necessary filtering to prevent a recurrence. > > If anyone sees more of this style of attack please send up a flare so > the community knows to track down the new source. > > Damian One of my clients suffered from such attacks. And you know what the secondary harm is? Typical false flag issue. Even if you have decent DDoS protection setup, it is highly likely that involuntary reflectors administrators will not puzzle what to do with this, they will simply block your subnet/ASN. For example attacker spoof hosting operator subnets, did SYN flood to all credit card processing gateways, and sure legit hosting gets SYN+ACK. And this hosting after suffering to block this SYN+ACK reflection will find an unpleasant thing - not a single credit card processing gateway is available from his subnets. Good example is EAGames, Rockstar, fs.com of those, who just set static ACL From mel at beckman.org Wed Aug 28 13:24:08 2019 From: mel at beckman.org (Mel Beckman) Date: Wed, 28 Aug 2019 13:24:08 +0000 Subject: The Curious Case of 143.95.0.0/16 In-Reply-To: <80277.1566973628@segfault.tristatelogic.com> References: <80277.1566973628@segfault.tristatelogic.com> Message-ID: <2EABC989-00B6-45A1-BD97-A962B9140077@beckman.org> Ronald, I have one question, “of late”, regarding your post: Is it “Antia” or “Anita”? :) -mel > On Aug 27, 2019, at 11:27 PM, Ronald F. Guilmette wrote: > > Fair Warning: Those of you not enamored of my long-winded exposés of > various remarkable oddities of the IPv4 address space may wish to click > on the tiny little wastebasket icons on your mail clients at this > point. For the rest of you, please read on. I think you may find the > following story intriguing. It contains at least a few surprising > twists. > > +_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ > > > Our story today consists of three acts. > > > Act 1 - It is Born > ------------------ > > In mid-February of 1990 a new venture-capital backed company was formed in > Sunnyvale, California. In some ways it was no different than the hundreds > or thousands of hopeful high-tech startups that had been formed in Silicon > Valley, both before and since. It started with a hopeful dream that, in > the end, just didn't work out. > > The founders of this company settled initially on a temporary placeholder > company name, XYZ Corporation: > > https://drive.google.com/file/d/1CkDNKq4M1DQKuTxBBhlYxUNAjU2cvDnY/view > > The mission of the company was to design and manufacture so-called X-Windows > terminals. These would be diskless workstations, complete with CPUs, color > (CRT) displays, graphics, memory, and an ethernet interface. The basic > idea what that such a diskless workstation could run the free X-Windows > client software, and that the system would be cheaper than ordinary PeeCees > due to it not having any hard drives or optical drives. > > By some odd twist of fate, I myself was working in the same geographic area > as a software engineer at around the same time, but I worked for a different > Silicon Valley startup, just down the road from XYZ Corporation. And by a > rather remarkable coincidence, the company I worked for had exactly the > same goal and mission as the XYZ Corporation. The name of this other > X-Windows workstation startup was Network Computing Devices, or just "NCD" > for short. > > Quite obviously, both companies were inherently "network-centric" and thus, > both requested and were granted blocks of IPv4 addresses. That wasn't at > all within my area of responsibility at NCD, so I don't know who actually > issued those blocks. My guess, based on published historical accounts, > was that it was most probably Dr. Jon Postel who assigned the blocks. I'm > sure that someone will correct me if I'm wrong. > > Months passed, and eventually the founders of XYZ Corporation settled on > something they would use as a permanent replacement for their temporary > placeholder corporate name. They decided to call the thing Athenix, Inc. > Once they had settled on that name, they filed papers to update their > records with the California Secretary of State's office: > > https://drive.google.com/file/d/1dUjsvSkzzdzUsIbIZCS7RF0afsI3uU0l/view > > At some point, they also and likewise updated the ARIN WHOIS record for the > /16 block which had been assigned to them, on or about 1990-09-06, as was > appropriate to reflect their new permanent corporate identity: > > https://pastebin.com/raw/YbH6zYrR > > More time passed and eventually it became clear that the entire world was > not in fact breathlessly waiting for -two- companies to bring to market > diskless X-Windows workstations. In fact, as history now shows, market > demand would not support even one such company over the long term. > > Thus it came to pass in the year 1993 that an all-too-familiar end-of-life > ritual played out once again in Silicon Valley. At Athenix, Inc. HQ in > Sunnyvale, the people were all let go, including the founders. The desks, > the chairs, the phones, the computers, and the tools were all sold at > auction, with the proceeds going to the preferred shareholders, i.e. the > poor fools who had put up all of the money for this now-failed venture in > the first place, the venture capitalists. Foremost among those in this > instance, was the venerable Menlo Park venture capital firm Kleiner Perkins. > > I've confirmed this historical account of the rise and fall of the original > 1990-vintage Athenix, Inc. in multiple phone and email exchanges with both > the original CEO of the original Athenix, Mr. Robert ("Bob") Garrow. lately > of Los Altos, California, and also the original CTO of the company, Mr. John > Garman, lately of Reno, Nevada. > > > Act 2 - Rebirth - The Athenix Phoenix > ------------------------------------- > > Fast forward fifteen years. On April 22, 2008 a pair of gentlemen in > the Commonwealth of Massachusetts elected to establish a new corporate > entity within the commonwealth. It's name would be Athenic, Inc.[1] > > https://drive.google.com/file/d/1jYUqtgYprI4iyJkTT91-yRBYJt0c2ufF/view > https://drive.google.com/file/d/1mlVML8z7vzp7aeGmOK-3cWBBJeNBuThn/view > > As you can see in the documents above, a certain Mr. Ofer Inbar and a certain > Mr. Robert Anita, both of the greater Boston area, formed this new corporate > entity in Massachusetts. At its formation, the younger Mr. Inbar was the > President, while the more senior Mr. Antia served as the corporate secretary > and treasurer. > > Various other records, which I shall not include here, suggest that both Mr. > Inbar and Mr. Anita were at some point in the distant past affiliated, in > at least some tangential way, with the well-regarded white-hat Boston area > hacking collective known as L0pht, aka L0pht Heavy Industries. I cannot > say much about this apparent connection, other than to say that the details > I have ferreted out about this connection are sketchy at best. > > I do however have it on reasonably good authority that Mr. Inbar has of late > relocated to the greater Seattle metropolitan area, and that he is or was > working as a network administrator for Google, Inc. in that area. Mr. Antia, > in contrast, is still, when I last checked, a resident of the greater Boston > area, and is a well regarded "graybeard" in the computing community in and > around Boston, having been in the business, one way or another, for decades. > Mr. Anita currently serves as President of the Boston area chapter of the > public/private critical infrastructure cybersecurity defense partnership > known as InfraGuard. > > https://infragard-boston.org/ > > The evidence currently available to me suggests that not long after the > creation of Mr. Inbar's and Mr. Antia's Massachusetts Athenix, Inc., ARIN > elected to delegate responsibility for the reverse DNS for the 143.95.0.0/16 > IPv4 block to a pair of name servers called dns1.athenixinc.com and > dns2.athenixinc.com. That delegation was already in place by 2010-06-24, > which is about the time that Farsight Security Inc., my data source, first > began passively collecting its historical archives of DNS response records. > > Historical records made available to me by Domaintools, LLC indicate that > the athenixinc.com domain name was, at least initially, registered to Mr. > Anita in Lincoln, Massachusetts. > > https://pastebin.com/raw/GNhbFDFz > > Subsequent historical WHOIS data collected by Domaintools in relation to > the athenixinc.com domain name shows that after Mr. Anita, the domain name > registration passed into the hands of at least one other individual, and > eventually, to an entirely different corporate entity. We will come to > that shortly. > > Almost a year ago now, when I was first investigating the 143.95.0.0/16 > block, I attempted to interview Mr. Inbar by phone regarding his and Mr. > Anita's Athenix, Inc. and the unusual history of the 143.95.0.0/16 block. > It did not go well. Mr. Inbar was apparently reluctant to engage with > me by phone on these or any other topics. He and I did have a few brief > and truncated email exchanges after that however, but apparently my > questions regarding how Mr. Inbar and Mr. Anita came to exercise effective > day-to-day control over the 143.95.0.0/16 ARIN legacy block were not ones > that Mr. Inbar felt in any way obliged to answer, and at some point he > simply ceased answering my emails. > > In contrast, Mr. Antia was a veritable fount of information and he and I > had multiple phone conversations as well as multiple email exchanges. From > these exchanges I quickly deduced that Mr. Antia saw absolutely nothing > wrong with, much less anything at all to be shy about with respect to the > history of the 143.95.0.0/16 block -or- his formation, along with Mr. Inbar, > of a new Athenix, Inc. in Massachusetts back in in 2008. Quite the contrary! > Mr. Anita was kind enough for forward me a copy of the following really > rather remarkable lease agreement, in which Mr. Inbar and Mr. Anita together > undertook to lease the 143.95.0.0/16 IPv4 block to a certain Nevada- > incorporated and Colorado-resident limited liability company known as > Media Breakaway, LLC: > > https://drive.google.com/file/d/1ASXrUsiNAIq1IIZO5Lw1BqjD1qucqFmI/view > > As you can see, the term of the lease is 20 years, beginning from the 28th > day of May, 2008. The compensation to be paid to Mr. Inbar's and Mr. Anita's > Massachusetts Athenic, Inc. in return for this 20 year leasehold was to be > $100,000 USD As Mr. Anita related to me, this sum was in fact paid, and Mr. > Inbar and Mr. Anita split it evenly. (But of course, I have no way to > independently verify that.) > > For those unaware, I pause here just long enough to note that the CEO > of Media Breakaway, LLC is none other than Mr. Scott Richter, one-time > "Spam King" and a man who both Wikipedia and the KrebsOnSecurity blog > have asserted is a convicted felon. And of couurse, this is the very same > Scott Richter who figured so prominently in Brian Krebs' report about > pilfered legacy ARIN /16 blocks, published on the Washington Post, way back > in April, 2008. > > Of course, in my phone conversations with Mr. Anita, I acquainted him with > these relevant historical allegations. He confessed at the time that he > had not personally done much at all in the way of due diligence with respect > to either Mr. Richter or his company -- a lapse which I personally found > (and find) quite unfortunate, to say the least, and not least because of > Mr. Anita's position as the President of the Boston Chapter of Infraguard, > the public/private partnership whose mission is the protection of the > nation's critical infrastructure assets from cyber-threats. I would have > hoped that a person in such a position would have been in the general > habit of exercising at least some due diligence with respect to the people > he does business with and, in this specific instance, preferably at some > moment *before* Mr. Anita cashed his $50,000 check. > > > Act 3 - Final Dispensation > -------------------------- > > Now we come to the final remarkable chapter in the already remarkable > history of the 143.95.0.0/16 legacy IPv4 ARIN address block. > > Some months after the formation of the Massachusetts "Athenix, Inc.", on > Sepetember 2nd, 2008 a new corporate entity calling itself "Athenix > Corporation" was incorporated in the State of California. Curiously, this > third Athenix gave both its actual address and its mailing address as 10 > Corporate Drive, Burlington, MA 01813. > > https://drive.google.com/file/d/1GHhwuPGPKdx5n46cYQ2UhTGiMSdxonFu/view > https://drive.google.com/file/d/1ZLtcY2HWoi5vmNFAJleHep8DxIS3igVR/view > > As it happens, that street address is also the headquarters address of the > publicly-traded Endurance International Group, Inc. (EIGI). > > There is substantial evidence indicating that EIGI is effectively in complete > functional control of the 143.95.0.0/16 address block at the present moment. > > The company's primary ASN, AS29873 and also, an AS number belonging to one > of the company's many acquired subsidiaries, A Small Orange LLC, AS62729 > are each routing significant portions of the 143.95.0.0/16 block at the > present time. > > https://bgp.he.net/AS29873#_prefixes > https://bgp.he.net/AS62729#_prefixes > > Additionally, on or about 2017-05-22, EIGI became the registrant of the > athenixinc.com domain, whose associated name servers (dns1 dns2) had > provided revserse DNS service for the entire 143.95.0.0/16 block during > 2011 and 2012. Delegation of the reverse DNS responsibility for the > entire 143.95.0.0/16 block changed on or about 2013-11-28 so that the > new name servers were ones associated with the domain name asonoc.com, > at least according to the relevant historical data provided to me by > Farsight Security, Inc. > > https://pastebin.com/raw/MVmzhirc > > Historically, and as recently as 2018-04-20, the domain name asonoc.com > was and has been registered to the EIGI subsidiary A Small Orange LLC. > > https://pastebin.com/raw/Xy8UHZNw > > Responsibility for the reverse DNS for the entire 143.95.0.0/16 block > remains delegated to the rdns1.asonoc.com and rdns2.asonoc.com name > servers at the present moment. > > EIGI is primarily a web hosting company. It has, over time. exhibited a > tendency to acquire other and smaller web hosting companies which it has > then absorbed into and under its corporate unbrella. Unlike most other > corporate acquirers however, EIGI is somewhat unique in its notable tendency > to not rebrand its acqusitions so that they would be additive to its main > corporate brand, generally electing instead to maintain the pre-acqusition > brand names for its newly acquired web hosting businesses. One such EIGI- > acquired propery that has retained its pre-acqusition brand name is the > aforementioned Texas-based web hosting company called A Small Orange LLC, > aka AS62729. > > (Those who may be interested in more backgound regarding EIGI and past > controversies, specifically with relating to the company's accounting > practices as well as the online activities of its clientele, are encouraged > to consult the footnotes below.[2]) > > The available evidence suggests the clear possibility that EIGI and its > subsidiary, A Small Orange LLC. may be controling and using the 143.95.0.0/16 > block in a manner inconsistant with ordinary business rules of fair dealing > and/or in a manner inconsistant with current ARIN policy, and further, that > the company and/or its various C-suite officers may have arrived at this > current situation not by happentance but rather by some very carefully > considered premeditation. > > I mention specifically EIGI's C-suite officers, because the available > evidence suggests that EIGI's apparent takeover of the 143.95.0.0/16 > block was not purely or only the product of some unsanctioned rogue > activity on the part of lower-level company functionaries. Multiple > publicly available records obtained from the web site of the California > Secretary of State implicate multiple current and former EIGI C-suite > officers as having been, at the very least, directly aware of the formation > of the third "Athenix", even if perhaps not directly or personally > responsible for that rather suspicious company formation. > > https://drive.google.com/file/d/12gm41jG9iFIC9KvIJmfWNjUqCmRtTfxN/view > https://drive.google.com/file/d/1zdhru_hpYVIJfVKi-s5X1MW0znrErJzQ/view > https://drive.google.com/file/d/1dVHDSPKD4Qvur9rzCK9YZDEtOkFA2raS/view > > Plese note that Mr. Hari Ravichandran is the now-former CEO of EIGI. Mr. > David Bryson was and remains EIGI's Chief Legal Officer. Mr. Marc > Montagner was and remains EIGI's Chief Financial Officer. Mr. Jeffrey Fox > is EIGI's current CEO, having succeded Mr. Ravichandran in that post. > > https://www.endurance.com/our-company/our-team > > https://exechange.com/7850/endurance-ceo-hari-ravichandran-leaves-2/7850 > https://www.linkedin.com/in/hari-ravichandran-9b949b8 > https://jumpv.com/meet-the-team/ > > https://www.linkedin.com/in/davidbryson > https://www1.salary.com/David-C-Bryson-Salary-Bonus-Stock-Options-for-ENDURANCE-INTL-GRP-HLDGS-INC.html > > https://www.linkedin.com/in/marc-montagner-b112a1b1 > https://wallmine.com/people/6106/marc-montagner > > https://www.linkedin.com/in/jeff-fox-820a0413 > https://wallmine.com/people/2962/jeffrey-h-fox > > Given that EIGI's rights in and/or legal title to the 143.95.0.0/16 block > appear to be, at best, on somewhat shaky ground, and given that the new > 2008-vintage Athenix Corporation does not obviously possess any other > obvious or apparent assets to speak of, it appears, to this writer at > least, more than a little incongruous to see that EIGI apparently listed > Athenix Corporation as a collateral asset on what, to a layman such as > myself, appears to be a bank collateral statement which was filed, apparently > in 2013, with the United States Securities and Exchange Comission. > > https://www.sec.gov/Archives/edgar/data/1237746/000119312514077774/d635170dex1025.htm > > All I can say about that is that I personally was turned down for a bank > loan, some years ago, when I attempted to use the monthly -liability- of > my recurring water bills as collateral for the loan. But then I have > never been anywhere near as accomplished at high finance as any of the > gentlemen mentioned above surely are. > > > Responses > --------- > > More than 24 hours prior to posting this message, I reached out to the press > contact email address listed on EIGI's web site, press (at) endurance.com, > for comment about the facts elaborated above. No response was received from > the company by press time. > > Prior to posting, I also reached out to John Curran @ ARIN for his response > to the facts set forth above. John was kind enough to provide the following > official on-the-record ARIN response: > > ARIN does not comment on specific registry changes (as number resource > change requests are made in confidence), but we do take matters of > potential number resource fraud quite seriously. I would recommend that > you report potential incidents of registry fraud (if you have not done > so already) via our Internet Number Resource Fraud Reporting process at > https://www.arin.net/resources/fraud/, and we will promptly investigate. > – John Curran, CEO, ARIN > > +_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ > > FULL DISCLOSURE: I hold no postions, either short or long in EIGI or in > any related company. > > +_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ > > Acknowledgements > ---------------- > > My thanks to Farsight Security, Inc. and to Domaintools, LLC for their > kind support of this research. > > > Footnotes: > ======================================================================= > [1] Rather remarkably, the Massachusetts Athenix, Inc. was incorporated > a mere six days before my friend, journalist Brian Krebs, put up a story > on the Washington Post web site, detailing how a pair of legacy ARIN IPv4 > /16 blocks had somewhat inexplicably ended up in the hands of one of the > world's most notorious spammers, Scott Richter. That story, as some of you > will already know, alleged that a rather simple and yet elaborate fraud had > been perpetrated against ARIN, a fraud which amounted to nothing less than > corporate identity theft, with the one and only apparent goal being the > effective take-over of two quite valuable legacy ARIN IPv4 /16 blocks, a > goal which was, it appeared, successfully achieved with only a relatively > minor investment of effort and expense. > > [2] In recent years, all has not gone well for EIGI. In the year 2015, a > somewhat mysterious New York City short seller using the pen name Gotham > City Research published a sequence of four reports detailing his beliefs > that all was not as it should be at EIGI, both with respect to the company's > financial statements and with respect to its clientele and their (allegedly) > questionable online activities. > > 2015-04-28 - Endurance International Group - A Web of Deceit > https://bit.ly/2KZXPLA > > 2015-04-29 - Initial Follow-up To: A Web of Deceit > https://bit.ly/2L5Vv4o > > 2015-05-05 - EIGI’s Adjusted EBITDA is a Meaningless Metric > https://bit.ly/342x4xE > > 2015-08-03 - Endurance International Group: Malicious Activities > https://bit.ly/30Gk4vr > > The value of EIGI stock dropped rather precepitously following the publication > of the Gotham City Research reports and has yet to recover to its earlier > highs. > > https://drive.google.com/file/d/1BaGzFglnrbAca9DsRIqt2eD0m_jnrCMw/view > > The SEC's investigation of EIGI, and the SEC's subsequent enforcement actions > against the company and its officers in 2018 also didn't help matters much > with respect to EIGI and its stock price: > > https://www.sec.gov/enforce/33-10504-s > https://www.bizjournals.com/boston/news/2018/08/22/former-endurance-group-execs-pay-1-4m-to-settle.html > From owen at delong.com Wed Aug 28 15:54:39 2019 From: owen at delong.com (Owen DeLong) Date: Wed, 28 Aug 2019 08:54:39 -0700 Subject: 44/8 In-Reply-To: <46aff4fc-593e-4ef4-b4bd-767dfbd60ab9@bryanfields.net> References: <20190719025758.GB29374@puck.nether.net> <5AF8C324-8AB5-47E8-B903-512083D87CF1@delong.com> <46aff4fc-593e-4ef4-b4bd-767dfbd60ab9@bryanfields.net> Message-ID: > On Aug 27, 2019, at 23:50 , Bryan Fields wrote: > > On 8/27/19 11:52 PM, Owen DeLong wrote: >>> On Jul 26, 2019, at 21:59 , Doug Barton wrote: > > > >>> 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 will say most people ignored them, as TBQH, nothing changes in amateur radio > until people die. ARDC finally allocated space, got reverse DNS working, and > basically did nothing else. It was a technical org doing nothing of any real > value. > > I had brought up the issues of governance numerous times, and said it didn't > look right to have people on the board with conflicts, or even licensed > amateurs. I confess I never saw any of the questions about governance prior to the announcement of the sale. If I had, I might have been spurred to look closer at least. > There were other personnel issues brought up as well and no action > was taken. If was an org doing the bare minimums and we got what we needed > from it, so why rock the boat? Well, there’s also the fact that the people involved in the org that I was aware of were people that I trusted and would not have expected to take radical action absent some outreach and consent of the community. >> However, most of my anger is around the fact that: 1. It never in a million >> years would have occurred to me that these people who I also consider >> friends and also trust explicitly would take this particular action without >> significant prior (and much wider) consultation with the amateur radio >> community. >> >> 2. I believe this was done quietly and carefully orchestrated specifically >> to avoid any risk of successful backlash by the time the community became >> aware of this particular intended action. > > Bingo. > >> If you want to say shame on us for trusting these people and not noticing >> the severe corporate governance problems with ARDC until they took this >> particular action, then I suppose that’s a fair comment. > > Many know these people, and you cannot let that acquaintance cloud your > judgment here. If these were people you did not know and they did this, you'd > call it what it is. If an acquaintance does the same action, is it not the same? An acquaintance is different from a trusted colleague and friend. While I don’t have particularly close relationships with the parties involved, I did consider them trusted colleagues and friends. This doesn’t cloud my judgment about calling this action what it was, but it did cloud my judgment in terms of anticipating this action. When we trust people, we don’t expect them to act outside of certain bounds, as I did not expect that these particular people would act in this particular manner. It is a denial of human nature to claim that we can not allow our trust to cloud our judgment when it comes to expectations of how people will act. > Does it pass the smell test that 44/8 was used, with no benefit to ARDC by > CAIDA? This use held back deployment of 44/8 for years by the amateur users. > Does it smell funny that the majority of the board members of ARDC were CAIDA > board members? It does pass the smell test, actually, when I understand the manner in which it was “used”. CAIDA is not some evil spammer researching ways to infiltrate more networks or hide more snowshoeing. They are a public benefit research organization that has provided a lot of valuable information to the internet over the years. Their “use” of 44/8 was limited to a passive feed of otherwise unroutable packets destined for unregistered addresses within 44/8. Since they were adjacent to the router where this was occurring. I’m not sure how or why you claim that this held back deployment for years. You’ll need to provide more information and/or evidence to support that claim. At the moment, as I understand things, that claim doesn’t pass the smell test. >>> 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? >>> >>> >> All of those are good questions. I don’t have data to answer any of them >> other than that removing a /10 from a /8 is obviously a 25% reduction in >> the total space, so clearly a somewhat larger (though I don’t know by how >> much) reduction in available space since available space is some fraction >> of the remaining 1.5 /9s. > > Based on the way this was handled we suspect it was part of an unsolicited > offer by the buyer. I have no doubt that Amazon (and likely a broker acting on behalf of Amazon) probably approached the ARDC board to initiate the sale, but it’s pretty clear that ARDC took multiple deliberate steps over years that I suspect preceded any such approach that were clearly aimed at making this possible. > If an organization decided to sell off 1/4 of it's assets and start a > charitable giving process, the first thing done would be define the charitable > giving areas and process. Get your house in order, build up a board full of > talented people aligned with this new mission, and then effect the sale, no? > > Considering ARDC is only giving to IRS approved 501c3 organizations, the sale > of the part of the space dedicated to non-US use (44.128.0.0/9) doesn't seem > right. Seems like if you're going to sell space not for use in the US, you > should have a plan to benefit those who it was taken from, no? > > The first inkling of any of this was reverse DNS for 44/8 users was broken. > Mail was rejected, and people started to ask questions. There was no > consultation of anyone with technical clue on this. Had there been, we could > have prevented a 5+ day outage. > > I think we all get that '44.in-addr.arpa. NS $SERVERS' would need to move to > the next byte boundary in configuration. Sure, it's 192 new records that need > to be made at ARIN, and even if they can't script it, it's an hour or two of > typing in the ARIN portal. I would have expected at least one ARDC board member in particular to have significantly more DNS clue than the average DNS administrator. > Based on the absolute secrecy this was done with and the lack of process or > thinking that went into it, I have to think it was an unsolicited bid, and > likely negotiated by ARDC personal lacking real-world business savvy. That would not surprise me. >>> 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? >>> >> Taking another look is not at all out of line. Discarding 25% of it before >> letting the community in question on a broader scale take a look is >> absolutely very far out of line IMHO. > > While I never knew Jon personally, I can't think he would have expected the > value of IPv4 space either. I can only think his allocation policies would > have been much more different. I never actually met Jon personally. However, what I know from other people’s accounts and from reading various documents written by him in the early days of the internet, I think that anyone approaching him with the idea of IPv4 addresses having monetary value would have been viewed as a strange attempt at dark humor. > > >> In actual fact, had the ARDC board approached the broader amateur radio >> community with a plan to sell the space, it’s entirely likely that I would >> have lent my support to the plan. That does not change the fact that I feel >> it was beyond their mandate and out of line for them to take the action >> first and neither consult the community before nor after. > > This has been my position all along. A discussion should have been had. > There was no pressing reason it had to be done right now. Other than the buyer’s fear that they might not get everything they wanted. Likely this resulted in the buyer insisting on secrecy and applying pressure to close the transaction before any risk of publicity. > Based on my personal discussion with Brian Kantor in 2014, he was 100% against > selling, or even leasing it as he stated ARDC merely was the custodian of the > space for amateur use. I can't think what changed, other than his employment > situation. > > "They drove a dump-truck full of money up to my house, I'm not made of stone!" > -- Herschel Krustofsky Sounds about right. Unfortunately, I don’t think the amateur radio community is strong enough to put meaningful pressure on Amazon. I’m not 100% sure I wouldn’t have supported the action in a community consultation, either. I resent that this was done without consultation, I definitely would have insisted on better governance structure for ARDC prior to approving such consultation. At this point, I think we have lost. I think the best we can do is try to adapt the governance structure of ARDC to empower the Amateur Radio community and ensure that there isn’t a repeat of this. Owen From rfg at tristatelogic.com Wed Aug 28 20:40:03 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 28 Aug 2019 13:40:03 -0700 Subject: The Curious Case of 143.95.0.0/16 Message-ID: <83678.1567024803@segfault.tristatelogic.com> Mel Beckman mel at beckman.org wrote: >I have one question, “of late”, regarding your post: Is it “Antia” or “Anita”? Yes. Sorry. There were multiple small typos in what I posted. Not surprising, since I am an utterly awful typist. The link I gave in my post provides enough redundant context to work out the correct answer in this case: https://infragard-boston.org/ The gentleman's name is Robert ("Bob") Antia. Unrelated to that small faux pas on my part, I also would just like to mention that I have only just now been pointed at an additional relevant online document that provides more clarity as regards to who, or what, ended up owning the original Athenix's intangible assets following its demise. https://patents.google.com/patent/US5119494 In the case of this patent, ownership seem to have untimately been assigned to: JACKSON, DAVID HOOK PARTNERS II C/O DAVID J. HOOK KLEINER PERKINS CAUFIELD & BYERS V C/O JAMES LALLY COMDISCO, INC. INSTITUTIONAL VENTURE MANAGEMENT V C/O PETER THOMAS GARROW, ROBERT A. INSTITUTIONAL VENTURE PARTNERS FUND V C/O PETER THOMAS SINGAPORE ECONOMIC DEVELOPMENT BOARD PACVEN INVESTMENT, LTD. C/O LIP-BU TAN Obviously, this is a more complete list of Athenix's heirs and assigns than I had included in my earlier post. Regards, rfg From cscora at apnic.net Fri Aug 30 18:04:17 2019 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 31 Aug 2019 04:04:17 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20190830180417.D106EC34BB@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 31 Aug, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 768323 Prefixes after maximum aggregation (per Origin AS): 295832 Deaggregation factor: 2.60 Unique aggregates announced (without unneeded subnets): 370810 Total ASes present in the Internet Routing Table: 65326 Prefixes per ASN: 11.76 Origin-only ASes present in the Internet Routing Table: 56226 Origin ASes announcing only one prefix: 24072 Transit ASes present in the Internet Routing Table: 9100 Transit-only ASes present in the Internet Routing Table: 269 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 45 Max AS path prepend of ASN ( 27978) 31 Prefixes from unregistered ASNs in the Routing Table: 27 Number of instances of unregistered ASNs: 27 Number of 32-bit ASNs allocated by the RIRs: 28444 Number of 32-bit ASNs visible in the Routing Table: 23268 Prefixes from 32-bit ASNs in the Routing Table: 105688 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: 288 Number of addresses announced to Internet: 2834690304 Equivalent to 168 /8s, 245 /16s and 241 /24s Percentage of available address space announced: 76.6 Percentage of allocated address space announced: 76.6 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: 257215 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 206838 Total APNIC prefixes after maximum aggregation: 61926 APNIC Deaggregation factor: 3.34 Prefixes being announced from the APNIC address blocks: 201585 Unique aggregates announced from the APNIC address blocks: 84621 APNIC Region origin ASes present in the Internet Routing Table: 10000 APNIC Prefixes per ASN: 20.16 APNIC Region origin ASes announcing only one prefix: 2776 APNIC Region transit ASes present in the Internet Routing Table: 1483 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 29 Number of APNIC region 32-bit ASNs visible in the Routing Table: 5015 Number of APNIC addresses announced to Internet: 766769408 Equivalent to 45 /8s, 179 /16s and 249 /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: 226731 Total ARIN prefixes after maximum aggregation: 106033 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 225420 Unique aggregates announced from the ARIN address blocks: 107479 ARIN Region origin ASes present in the Internet Routing Table: 18534 ARIN Prefixes per ASN: 12.16 ARIN Region origin ASes announcing only one prefix: 6858 ARIN Region transit ASes present in the Internet Routing Table: 1891 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2875 Number of ARIN addresses announced to Internet: 1067004160 Equivalent to 63 /8s, 153 /16s and 49 /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: 214997 Total RIPE prefixes after maximum aggregation: 100530 RIPE Deaggregation factor: 2.14 Prefixes being announced from the RIPE address blocks: 211061 Unique aggregates announced from the RIPE address blocks: 124404 RIPE Region origin ASes present in the Internet Routing Table: 26388 RIPE Prefixes per ASN: 8.00 RIPE Region origin ASes announcing only one prefix: 11647 RIPE Region transit ASes present in the Internet Routing Table: 3733 Average RIPE Region AS path length visible: 4.3 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 8422 Number of RIPE addresses announced to Internet: 721204480 Equivalent to 42 /8s, 252 /16s and 181 /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: 98760 Total LACNIC prefixes after maximum aggregation: 22976 LACNIC Deaggregation factor: 4.30 Prefixes being announced from the LACNIC address blocks: 100007 Unique aggregates announced from the LACNIC address blocks: 44406 LACNIC Region origin ASes present in the Internet Routing Table: 8802 LACNIC Prefixes per ASN: 11.36 LACNIC Region origin ASes announcing only one prefix: 2327 LACNIC Region transit ASes present in the Internet Routing Table: 1620 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 45 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 6356 Number of LACNIC addresses announced to Internet: 173565184 Equivalent to 10 /8s, 88 /16s and 101 /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: 20969 Total AfriNIC prefixes after maximum aggregation: 4345 AfriNIC Deaggregation factor: 4.83 Prefixes being announced from the AfriNIC address blocks: 29962 Unique aggregates announced from the AfriNIC address blocks: 9637 AfriNIC Region origin ASes present in the Internet Routing Table: 1317 AfriNIC Prefixes per ASN: 22.75 AfriNIC Region origin ASes announcing only one prefix: 464 AfriNIC Region transit ASes present in the Internet Routing Table: 257 Average AfriNIC Region AS path length visible: 4.4 Max AfriNIC Region AS path length visible: 27 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 600 Number of AfriNIC addresses announced to Internet: 105899264 Equivalent to 6 /8s, 79 /16s and 229 /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 4947 599 579 TPG-INTERNET-AP TPG Telecom Limited, AU 7552 3248 1459 32 VIETEL-AS-AP Viettel Group, VN 45899 3065 1768 114 VNPT-AS-VN VNPT Corp, VN 9829 2736 1494 547 BSNL-NIB National Internet Backbone, IN 9808 2694 9043 63 CMNET-GD Guangdong Mobile Communication 4766 2546 11119 763 KIXS-AS-KR Korea Telecom, KR 7713 2240 680 596 TELKOMNET-AS-AP PT Telekomunikasi Indon 9498 2163 434 209 BBIL-AP BHARTI Airtel Ltd., IN 4755 2153 442 192 TATACOMM-AS TATA Communications formerl 9394 2076 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 4065 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 11492 3652 238 680 CABLEONE - CABLE ONE, INC., US 6327 3477 1324 91 SHAW - Shaw Communications Inc., CA 22773 3454 2973 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 16509 3078 6452 1466 AMAZON-02 - Amazon.com, Inc., US 16625 2736 1438 1973 AKAMAI-AS - Akamai Technologies, Inc., 30036 2187 349 175 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 20115 2145 2762 525 CHARTER-20115 - Charter Communications, 18566 2086 405 105 MEGAPATH5-US - MegaPath Corporation, US 5650 2074 3073 1453 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 5515 1613 143 UNI2-AS, ES 39891 3780 219 19 ALJAWWALSTC-AS, SA 8551 3311 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 2726 497 1927 AKAMAI-ASN1, US 31334 2602 484 13 KABELDEUTSCHLAND-AS, DE 12389 2392 2233 691 ROSTELECOM-AS, RU 34984 2127 346 541 TELLCOM-AS, TR 9121 2019 1692 18 TTNET, TR 9009 1736 187 936 M247, GB 13188 1604 100 47 TRIOLAN, UA Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6254 3360 597 Uninet S.A. de C.V., MX 10620 3365 534 450 Telmex Colombia S.A., CO 11830 2692 370 54 Instituto Costarricense de Electricidad 6503 1611 378 415 Axtel, S.A.B. de C.V., MX 7303 1480 1024 274 Telecom Argentina S.A., AR 28573 1164 2228 203 CLARO S.A., BR 6147 1105 380 35 Telefonica del Peru S.A.A., PE 3816 1051 534 121 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 13999 1000 482 248 Mega Cable, S.A. de C.V., MX 11172 936 110 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 1120 393 23 LINKdotNET-AS, EG 36992 956 1535 73 ETISALAT-MISR, EG 24835 888 590 21 RAYA-AS, EG 36903 843 424 112 MT-MPLS, MA 8452 672 1859 20 TE-AS TE-AS, EG 29571 527 68 11 ORANGE-COTE-IVOIRE, CI 15399 414 45 11 WANANCHI-, KE 37492 372 470 57 ORANGE-, TN 37342 370 32 1 MOVITEL, MZ 15706 362 32 6 Sudatel, SD 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 6254 3360 597 Uninet S.A. de C.V., MX 12479 5515 1613 143 UNI2-AS, ES 7545 4947 599 579 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4065 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3780 219 19 ALJAWWALSTC-AS, SA 11492 3652 238 680 CABLEONE - CABLE ONE, INC., US 6327 3477 1324 91 SHAW - Shaw Communications Inc., CA 22773 3454 2973 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 10620 3365 534 450 Telmex Colombia S.A., CO 8551 3311 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 5515 5372 UNI2-AS, ES 7545 4947 4368 TPG-INTERNET-AP TPG Telecom Limited, AU 7155 4065 4040 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 3780 3761 ALJAWWALSTC-AS, SA 6327 3477 3386 SHAW - Shaw Communications Inc., CA 22773 3454 3298 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8551 3311 3265 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 3248 3216 VIETEL-AS-AP Viettel Group, VN 11492 3652 2972 CABLEONE - CABLE ONE, INC., US 45899 3065 2951 VNPT-AS-VN VNPT Corp, VN 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 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:98 /12:288 /13:573 /14:1142 /15:1915 /16:13259 /17:7983 /18:13735 /19:25575 /20:40168 /21:47329 /22:95972 /23:77628 /24:441773 /25:827 /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 4475 5515 UNI2-AS, ES 6327 3265 3477 SHAW - Shaw Communications Inc., CA 7155 3156 4065 VIASAT-SP-BACKBONE - ViaSat,Inc., US 39891 2946 3780 ALJAWWALSTC-AS, SA 11492 2865 3652 CABLEONE - CABLE ONE, INC., US 8551 2764 3311 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 22773 2684 3454 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 31334 2490 2602 KABELDEUTSCHLAND-AS, DE 11830 2040 2692 Instituto Costarricense de Electricidad y Telec 18566 1981 2086 MEGAPATH5-US - MegaPath Corporation, US Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1744 2:1092 3:6 4:22 5:3026 6:49 7:1 8:1359 9:1 12:1796 13:398 14:2112 15:42 16:7 17:269 18:81 20:56 23:2895 24:2589 25:2 27:2461 31:2711 32:106 35:37 36:906 37:3123 38:1808 39:302 40:121 41:3390 42:820 43:2071 44:173 45:10156 46:3359 47:271 49:1442 50:1103 51:341 52:1041 54:263 55:684 56:6 57:47 58:2054 59:1109 60:580 61:2181 62:1989 63:1848 64:5011 65:2234 66:4816 67:2738 68:1196 69:3573 70:1386 71:670 72:2666 74:2700 75:1291 76:596 77:2524 78:1963 79:2365 80:1816 81:1501 82:1137 83:961 84:1164 85:2356 86:562 87:1562 88:1060 89:2544 90:231 91:6597 92:1444 93:2485 94:2571 95:3639 96:954 97:340 98:951 99:829 100:88 101:944 102:639 103:21930 104:3635 105:281 106:816 107:1790 108:689 109:3751 110:1763 111:2021 112:1536 113:1408 114:1251 115:1722 116:1743 117:1962 118:2214 119:1642 120:1056 121:1039 122:2296 123:1838 124:1529 125:2020 128:1301 129:849 130:536 131:1819 132:747 133:226 134:1079 135:255 136:598 137:794 138:2073 139:939 140:567 141:879 142:773 143:1071 144:893 145:277 146:1334 147:857 148:1785 149:1021 150:820 151:1026 152:1370 153:362 154:4413 155:889 156:2254 157:1050 158:693 159:1934 160:1577 161:950 162:2990 163:827 164:1246 165:1188 166:515 167:1416 168:3467 169:474 170:4186 171:651 172:1711 173:2226 174:1039 175:989 176:2436 177:4043 178:2729 179:1473 180:2146 181:2385 182:2772 183:1115 184:2276 185:15447 186:3720 187:2572 188:3465 189:2068 190:8241 191:1438 192:10105 193:6717 194:5511 195:4193 196:3094 197:1728 198:5938 199:5957 200:7151 201:5173 202:10268 203:10241 204:4532 205:3058 206:3171 207:3231 208:3945 209:4292 210:3893 211:2019 212:3249 213:2955 214:1135 215:54 216:5890 217:2212 218:868 219:599 220:1929 221:972 222:981 223:1364 End of report From patrick at ianai.net Fri Aug 30 19:09:24 2019 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 30 Aug 2019 15:09:24 -0400 Subject: Weekly Routing Table Report In-Reply-To: <20190830180417.D106EC34BB@thyme.apnic.net> References: <20190830180417.D106EC34BB@thyme.apnic.net> Message-ID: <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> A very long time ago, I commented on this report hitting 250,000 prefixes. It was a Big F*#@$&! Deal at the time. A quarter million prefixes in the DFZ? Wow…. Then I did it again at 500,000. People commented that I should have waited for 512,000 - especially since a popular piece of kit was expected to fall over at 512K prefixes. But I said I liked round numbers. This time I waited for 768,000. (Everyone happy now?) To say “the Internet grew more than anyone expected” is beyond cliché these days, but that does not make it any less true. The Internet has transformed from a curiosity into something my son[*] and a good portion of his entire generation cannot conceive of living without. A great many people on this list had a part in making all that happen. Stop and think about that for a second. You had a part in literally changing the world. It is a 3-day weekend in the US. A good time to pause for a few minutes and consider what all of us accomplished together. Pat yourselves on the back, raise a glass or whatever your personal traditions are, and bask in the glory of a job well done. -- TTFN, patrick [*] The fact I can say “my son” is probably even more amazing. But that is a different story. > On Aug 30, 2019, at 2:04 PM, Routing Analysis Role Account wrote: > > 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 31 Aug, 2019 > > Report Website: http://thyme.rand.apnic.net > Detailed Analysis: http://thyme.rand.apnic.net/current/ > > Analysis Summary > ---------------- > > BGP routing table entries examined: 768323 > Prefixes after maximum aggregation (per Origin AS): 295832 > Deaggregation factor: 2.60 > Unique aggregates announced (without unneeded subnets): 370810 > Total ASes present in the Internet Routing Table: 65326 > Prefixes per ASN: 11.76 > Origin-only ASes present in the Internet Routing Table: 56226 > Origin ASes announcing only one prefix: 24072 > Transit ASes present in the Internet Routing Table: 9100 > Transit-only ASes present in the Internet Routing Table: 269 > Average AS path length visible in the Internet Routing Table: 4.3 > Max AS path length visible: 45 > Max AS path prepend of ASN ( 27978) 31 > Prefixes from unregistered ASNs in the Routing Table: 27 > Number of instances of unregistered ASNs: 27 > Number of 32-bit ASNs allocated by the RIRs: 28444 > Number of 32-bit ASNs visible in the Routing Table: 23268 > Prefixes from 32-bit ASNs in the Routing Table: 105688 > 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: 288 > Number of addresses announced to Internet: 2834690304 > Equivalent to 168 /8s, 245 /16s and 241 /24s > Percentage of available address space announced: 76.6 > Percentage of allocated address space announced: 76.6 > 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: 257215 > > APNIC Region Analysis Summary > ----------------------------- > > Prefixes being announced by APNIC Region ASes: 206838 > Total APNIC prefixes after maximum aggregation: 61926 > APNIC Deaggregation factor: 3.34 > Prefixes being announced from the APNIC address blocks: 201585 > Unique aggregates announced from the APNIC address blocks: 84621 > APNIC Region origin ASes present in the Internet Routing Table: 10000 > APNIC Prefixes per ASN: 20.16 > APNIC Region origin ASes announcing only one prefix: 2776 > APNIC Region transit ASes present in the Internet Routing Table: 1483 > Average APNIC Region AS path length visible: 4.4 > Max APNIC Region AS path length visible: 29 > Number of APNIC region 32-bit ASNs visible in the Routing Table: 5015 > Number of APNIC addresses announced to Internet: 766769408 > Equivalent to 45 /8s, 179 /16s and 249 /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: 226731 > Total ARIN prefixes after maximum aggregation: 106033 > ARIN Deaggregation factor: 2.14 > Prefixes being announced from the ARIN address blocks: 225420 > Unique aggregates announced from the ARIN address blocks: 107479 > ARIN Region origin ASes present in the Internet Routing Table: 18534 > ARIN Prefixes per ASN: 12.16 > ARIN Region origin ASes announcing only one prefix: 6858 > ARIN Region transit ASes present in the Internet Routing Table: 1891 > Average ARIN Region AS path length visible: 3.8 > Max ARIN Region AS path length visible: 42 > Number of ARIN region 32-bit ASNs visible in the Routing Table: 2875 > Number of ARIN addresses announced to Internet: 1067004160 > Equivalent to 63 /8s, 153 /16s and 49 /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: 214997 > Total RIPE prefixes after maximum aggregation: 100530 > RIPE Deaggregation factor: 2.14 > Prefixes being announced from the RIPE address blocks: 211061 > Unique aggregates announced from the RIPE address blocks: 124404 > RIPE Region origin ASes present in the Internet Routing Table: 26388 > RIPE Prefixes per ASN: 8.00 > RIPE Region origin ASes announcing only one prefix: 11647 > RIPE Region transit ASes present in the Internet Routing Table: 3733 > Average RIPE Region AS path length visible: 4.3 > Max RIPE Region AS path length visible: 29 > Number of RIPE region 32-bit ASNs visible in the Routing Table: 8422 > Number of RIPE addresses announced to Internet: 721204480 > Equivalent to 42 /8s, 252 /16s and 181 /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: 98760 > Total LACNIC prefixes after maximum aggregation: 22976 > LACNIC Deaggregation factor: 4.30 > Prefixes being announced from the LACNIC address blocks: 100007 > Unique aggregates announced from the LACNIC address blocks: 44406 > LACNIC Region origin ASes present in the Internet Routing Table: 8802 > LACNIC Prefixes per ASN: 11.36 > LACNIC Region origin ASes announcing only one prefix: 2327 > LACNIC Region transit ASes present in the Internet Routing Table: 1620 > Average LACNIC Region AS path length visible: 5.2 > Max LACNIC Region AS path length visible: 45 > Number of LACNIC region 32-bit ASNs visible in the Routing Table: 6356 > Number of LACNIC addresses announced to Internet: 173565184 > Equivalent to 10 /8s, 88 /16s and 101 /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: 20969 > Total AfriNIC prefixes after maximum aggregation: 4345 > AfriNIC Deaggregation factor: 4.83 > Prefixes being announced from the AfriNIC address blocks: 29962 > Unique aggregates announced from the AfriNIC address blocks: 9637 > AfriNIC Region origin ASes present in the Internet Routing Table: 1317 > AfriNIC Prefixes per ASN: 22.75 > AfriNIC Region origin ASes announcing only one prefix: 464 > AfriNIC Region transit ASes present in the Internet Routing Table: 257 > Average AfriNIC Region AS path length visible: 4.4 > Max AfriNIC Region AS path length visible: 27 > Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 600 > Number of AfriNIC addresses announced to Internet: 105899264 > Equivalent to 6 /8s, 79 /16s and 229 /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 4947 599 579 TPG-INTERNET-AP TPG Telecom Limited, AU > 7552 3248 1459 32 VIETEL-AS-AP Viettel Group, VN > 45899 3065 1768 114 VNPT-AS-VN VNPT Corp, VN > 9829 2736 1494 547 BSNL-NIB National Internet Backbone, IN > 9808 2694 9043 63 CMNET-GD Guangdong Mobile Communication > 4766 2546 11119 763 KIXS-AS-KR Korea Telecom, KR > 7713 2240 680 596 TELKOMNET-AS-AP PT Telekomunikasi Indon > 9498 2163 434 209 BBIL-AP BHARTI Airtel Ltd., IN > 4755 2153 442 192 TATACOMM-AS TATA Communications formerl > 9394 2076 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 4065 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US > 11492 3652 238 680 CABLEONE - CABLE ONE, INC., US > 6327 3477 1324 91 SHAW - Shaw Communications Inc., CA > 22773 3454 2973 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi > 16509 3078 6452 1466 AMAZON-02 - Amazon.com, Inc., US > 16625 2736 1438 1973 AKAMAI-AS - Akamai Technologies, Inc., > 30036 2187 349 175 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom > 20115 2145 2762 525 CHARTER-20115 - Charter Communications, > 18566 2086 405 105 MEGAPATH5-US - MegaPath Corporation, US > 5650 2074 3073 1453 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 5515 1613 143 UNI2-AS, ES > 39891 3780 219 19 ALJAWWALSTC-AS, SA > 8551 3311 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne > 20940 2726 497 1927 AKAMAI-ASN1, US > 31334 2602 484 13 KABELDEUTSCHLAND-AS, DE > 12389 2392 2233 691 ROSTELECOM-AS, RU > 34984 2127 346 541 TELLCOM-AS, TR > 9121 2019 1692 18 TTNET, TR > 9009 1736 187 936 M247, GB > 13188 1604 100 47 TRIOLAN, UA > > Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE > > LACNIC Region per AS prefix count summary > ----------------------------------------- > > ASN No of nets /20 equiv MaxAgg Description > 8151 6254 3360 597 Uninet S.A. de C.V., MX > 10620 3365 534 450 Telmex Colombia S.A., CO > 11830 2692 370 54 Instituto Costarricense de Electricidad > 6503 1611 378 415 Axtel, S.A.B. de C.V., MX > 7303 1480 1024 274 Telecom Argentina S.A., AR > 28573 1164 2228 203 CLARO S.A., BR > 6147 1105 380 35 Telefonica del Peru S.A.A., PE > 3816 1051 534 121 COLOMBIA TELECOMUNICACIONES S.A. ESP, C > 13999 1000 482 248 Mega Cable, S.A. de C.V., MX > 11172 936 110 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 1120 393 23 LINKdotNET-AS, EG > 36992 956 1535 73 ETISALAT-MISR, EG > 24835 888 590 21 RAYA-AS, EG > 36903 843 424 112 MT-MPLS, MA > 8452 672 1859 20 TE-AS TE-AS, EG > 29571 527 68 11 ORANGE-COTE-IVOIRE, CI > 15399 414 45 11 WANANCHI-, KE > 37492 372 470 57 ORANGE-, TN > 37342 370 32 1 MOVITEL, MZ > 15706 362 32 6 Sudatel, SD > > 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 6254 3360 597 Uninet S.A. de C.V., MX > 12479 5515 1613 143 UNI2-AS, ES > 7545 4947 599 579 TPG-INTERNET-AP TPG Telecom Limited, AU > 7155 4065 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US > 39891 3780 219 19 ALJAWWALSTC-AS, SA > 11492 3652 238 680 CABLEONE - CABLE ONE, INC., US > 6327 3477 1324 91 SHAW - Shaw Communications Inc., CA > 22773 3454 2973 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi > 10620 3365 534 450 Telmex Colombia S.A., CO > 8551 3311 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 5515 5372 UNI2-AS, ES > 7545 4947 4368 TPG-INTERNET-AP TPG Telecom Limited, AU > 7155 4065 4040 VIASAT-SP-BACKBONE - ViaSat,Inc., US > 39891 3780 3761 ALJAWWALSTC-AS, SA > 6327 3477 3386 SHAW - Shaw Communications Inc., CA > 22773 3454 3298 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications > 8551 3311 3265 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo > 7552 3248 3216 VIETEL-AS-AP Viettel Group, VN > 11492 3652 2972 CABLEONE - CABLE ONE, INC., US > 45899 3065 2951 VNPT-AS-VN VNPT Corp, VN > > 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 > 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:98 /12:288 > /13:573 /14:1142 /15:1915 /16:13259 /17:7983 /18:13735 > /19:25575 /20:40168 /21:47329 /22:95972 /23:77628 /24:441773 > /25:827 /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 4475 5515 UNI2-AS, ES > 6327 3265 3477 SHAW - Shaw Communications Inc., CA > 7155 3156 4065 VIASAT-SP-BACKBONE - ViaSat,Inc., US > 39891 2946 3780 ALJAWWALSTC-AS, SA > 11492 2865 3652 CABLEONE - CABLE ONE, INC., US > 8551 2764 3311 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo > 22773 2684 3454 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications > 31334 2490 2602 KABELDEUTSCHLAND-AS, DE > 11830 2040 2692 Instituto Costarricense de Electricidad y Telec > 18566 1981 2086 MEGAPATH5-US - MegaPath Corporation, US > > Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos > > Number of /24s announced per /8 block (Global) > ---------------------------------------------- > > 1:1744 2:1092 3:6 4:22 5:3026 6:49 > 7:1 8:1359 9:1 12:1796 13:398 14:2112 > 15:42 16:7 17:269 18:81 20:56 23:2895 > 24:2589 25:2 27:2461 31:2711 32:106 35:37 > 36:906 37:3123 38:1808 39:302 40:121 41:3390 > 42:820 43:2071 44:173 45:10156 46:3359 47:271 > 49:1442 50:1103 51:341 52:1041 54:263 55:684 > 56:6 57:47 58:2054 59:1109 60:580 61:2181 > 62:1989 63:1848 64:5011 65:2234 66:4816 67:2738 > 68:1196 69:3573 70:1386 71:670 72:2666 74:2700 > 75:1291 76:596 77:2524 78:1963 79:2365 80:1816 > 81:1501 82:1137 83:961 84:1164 85:2356 86:562 > 87:1562 88:1060 89:2544 90:231 91:6597 92:1444 > 93:2485 94:2571 95:3639 96:954 97:340 98:951 > 99:829 100:88 101:944 102:639 103:21930 104:3635 > 105:281 106:816 107:1790 108:689 109:3751 110:1763 > 111:2021 112:1536 113:1408 114:1251 115:1722 116:1743 > 117:1962 118:2214 119:1642 120:1056 121:1039 122:2296 > 123:1838 124:1529 125:2020 128:1301 129:849 130:536 > 131:1819 132:747 133:226 134:1079 135:255 136:598 > 137:794 138:2073 139:939 140:567 141:879 142:773 > 143:1071 144:893 145:277 146:1334 147:857 148:1785 > 149:1021 150:820 151:1026 152:1370 153:362 154:4413 > 155:889 156:2254 157:1050 158:693 159:1934 160:1577 > 161:950 162:2990 163:827 164:1246 165:1188 166:515 > 167:1416 168:3467 169:474 170:4186 171:651 172:1711 > 173:2226 174:1039 175:989 176:2436 177:4043 178:2729 > 179:1473 180:2146 181:2385 182:2772 183:1115 184:2276 > 185:15447 186:3720 187:2572 188:3465 189:2068 190:8241 > 191:1438 192:10105 193:6717 194:5511 195:4193 196:3094 > 197:1728 198:5938 199:5957 200:7151 201:5173 202:10268 > 203:10241 204:4532 205:3058 206:3171 207:3231 208:3945 > 209:4292 210:3893 211:2019 212:3249 213:2955 214:1135 > 215:54 216:5890 217:2212 218:868 219:599 220:1929 > 221:972 222:981 223:1364 > > End of report From Romeo.Czumbil at tierpoint.com Fri Aug 30 20:33:45 2019 From: Romeo.Czumbil at tierpoint.com (Romeo Czumbil) Date: Fri, 30 Aug 2019 20:33:45 +0000 Subject: Weekly Routing Table Report In-Reply-To: <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> Message-ID: These numbers are nothing. Wait till IPv6 really start taking off. -----Original Message----- From: NANOG On Behalf Of Patrick W. Gilmore Sent: Friday, August 30, 2019 3:09 PM To: North American Operators' Group Subject: Re: Weekly Routing Table Report A very long time ago, I commented on this report hitting 250,000 prefixes. It was a Big F*#@$&! Deal at the time. A quarter million prefixes in the DFZ? Wow…. Then I did it again at 500,000. People commented that I should have waited for 512,000 - especially since a popular piece of kit was expected to fall over at 512K prefixes. But I said I liked round numbers. This time I waited for 768,000. (Everyone happy now?) To say “the Internet grew more than anyone expected” is beyond cliché these days, but that does not make it any less true. The Internet has transformed from a curiosity into something my son[*] and a good portion of his entire generation cannot conceive of living without. A great many people on this list had a part in making all that happen. Stop and think about that for a second. You had a part in literally changing the world. It is a 3-day weekend in the US. A good time to pause for a few minutes and consider what all of us accomplished together. Pat yourselves on the back, raise a glass or whatever your personal traditions are, and bask in the glory of a job well done. -- TTFN, patrick [*] The fact I can say “my son” is probably even more amazing. But that is a different story. > On Aug 30, 2019, at 2:04 PM, Routing Analysis Role Account wrote: > > 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 https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY&e= . > > If you have any comments please contact Philip Smith . > > Routing Table Report 04:00 +10GMT Sat 31 Aug, 2019 > > Report Website: https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY&e= > Detailed Analysis: > https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n > et_current_&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpk > Dj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s= > 1SzKtCXB1OQXt_kKzDwHmtLE8a44hKEkYUtraUzC3gI&e= > > Analysis Summary > ---------------- > > BGP routing table entries examined: 768323 > Prefixes after maximum aggregation (per Origin AS): 295832 > Deaggregation factor: 2.60 > Unique aggregates announced (without unneeded subnets): 370810 > Total ASes present in the Internet Routing Table: 65326 > Prefixes per ASN: 11.76 > Origin-only ASes present in the Internet Routing Table: 56226 > Origin ASes announcing only one prefix: 24072 > Transit ASes present in the Internet Routing Table: 9100 > Transit-only ASes present in the Internet Routing Table: 269 > Average AS path length visible in the Internet Routing Table: 4.3 > Max AS path length visible: 45 > Max AS path prepend of ASN ( 27978) 31 > Prefixes from unregistered ASNs in the Routing Table: 27 > Number of instances of unregistered ASNs: 27 > Number of 32-bit ASNs allocated by the RIRs: 28444 > Number of 32-bit ASNs visible in the Routing Table: 23268 > Prefixes from 32-bit ASNs in the Routing Table: 105688 > 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: 288 > Number of addresses announced to Internet: 2834690304 > Equivalent to 168 /8s, 245 /16s and 241 /24s > Percentage of available address space announced: 76.6 > Percentage of allocated address space announced: 76.6 > 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: 257215 > > APNIC Region Analysis Summary > ----------------------------- > > Prefixes being announced by APNIC Region ASes: 206838 > Total APNIC prefixes after maximum aggregation: 61926 > APNIC Deaggregation factor: 3.34 > Prefixes being announced from the APNIC address blocks: 201585 > Unique aggregates announced from the APNIC address blocks: 84621 > APNIC Region origin ASes present in the Internet Routing Table: 10000 > APNIC Prefixes per ASN: 20.16 > APNIC Region origin ASes announcing only one prefix: 2776 > APNIC Region transit ASes present in the Internet Routing Table: 1483 > Average APNIC Region AS path length visible: 4.4 > Max APNIC Region AS path length visible: 29 > Number of APNIC region 32-bit ASNs visible in the Routing Table: 5015 > Number of APNIC addresses announced to Internet: 766769408 > Equivalent to 45 /8s, 179 /16s and 249 /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: 226731 > Total ARIN prefixes after maximum aggregation: 106033 > ARIN Deaggregation factor: 2.14 > Prefixes being announced from the ARIN address blocks: 225420 > Unique aggregates announced from the ARIN address blocks: 107479 > ARIN Region origin ASes present in the Internet Routing Table: 18534 > ARIN Prefixes per ASN: 12.16 > ARIN Region origin ASes announcing only one prefix: 6858 > ARIN Region transit ASes present in the Internet Routing Table: 1891 > Average ARIN Region AS path length visible: 3.8 > Max ARIN Region AS path length visible: 42 > Number of ARIN region 32-bit ASNs visible in the Routing Table: 2875 > Number of ARIN addresses announced to Internet: 1067004160 > Equivalent to 63 /8s, 153 /16s and 49 /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: 214997 > Total RIPE prefixes after maximum aggregation: 100530 > RIPE Deaggregation factor: 2.14 > Prefixes being announced from the RIPE address blocks: 211061 > Unique aggregates announced from the RIPE address blocks: 124404 > RIPE Region origin ASes present in the Internet Routing Table: 26388 > RIPE Prefixes per ASN: 8.00 > RIPE Region origin ASes announcing only one prefix: 11647 > RIPE Region transit ASes present in the Internet Routing Table: 3733 > Average RIPE Region AS path length visible: 4.3 > Max RIPE Region AS path length visible: 29 > Number of RIPE region 32-bit ASNs visible in the Routing Table: 8422 > Number of RIPE addresses announced to Internet: 721204480 > Equivalent to 42 /8s, 252 /16s and 181 /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: 98760 > Total LACNIC prefixes after maximum aggregation: 22976 > LACNIC Deaggregation factor: 4.30 > Prefixes being announced from the LACNIC address blocks: 100007 > Unique aggregates announced from the LACNIC address blocks: 44406 > LACNIC Region origin ASes present in the Internet Routing Table: 8802 > LACNIC Prefixes per ASN: 11.36 > LACNIC Region origin ASes announcing only one prefix: 2327 > LACNIC Region transit ASes present in the Internet Routing Table: 1620 > Average LACNIC Region AS path length visible: 5.2 > Max LACNIC Region AS path length visible: 45 > Number of LACNIC region 32-bit ASNs visible in the Routing Table: 6356 > Number of LACNIC addresses announced to Internet: 173565184 > Equivalent to 10 /8s, 88 /16s and 101 /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: 20969 > Total AfriNIC prefixes after maximum aggregation: 4345 > AfriNIC Deaggregation factor: 4.83 > Prefixes being announced from the AfriNIC address blocks: 29962 > Unique aggregates announced from the AfriNIC address blocks: 9637 > AfriNIC Region origin ASes present in the Internet Routing Table: 1317 > AfriNIC Prefixes per ASN: 22.75 > AfriNIC Region origin ASes announcing only one prefix: 464 > AfriNIC Region transit ASes present in the Internet Routing Table: 257 > Average AfriNIC Region AS path length visible: 4.4 > Max AfriNIC Region AS path length visible: 27 > Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 600 > Number of AfriNIC addresses announced to Internet: 105899264 > Equivalent to 6 /8s, 79 /16s and 229 /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 4947 599 579 TPG-INTERNET-AP TPG Telecom Limited, AU > 7552 3248 1459 32 VIETEL-AS-AP Viettel Group, VN > 45899 3065 1768 114 VNPT-AS-VN VNPT Corp, VN > 9829 2736 1494 547 BSNL-NIB National Internet Backbone, IN > 9808 2694 9043 63 CMNET-GD Guangdong Mobile Communication > 4766 2546 11119 763 KIXS-AS-KR Korea Telecom, KR > 7713 2240 680 596 TELKOMNET-AS-AP PT Telekomunikasi Indon > 9498 2163 434 209 BBIL-AP BHARTI Airtel Ltd., IN > 4755 2153 442 192 TATACOMM-AS TATA Communications formerl > 9394 2076 4898 24 CTTNET China TieTong Telecommunications > > Complete listing at > https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n > et_current_data-2DASnet-2DAPNIC&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c > 7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSf > vn9V7rEBtxr4BhRDk&s=PbRZ5sxJfmYfAn4HtffRzZaO3u_8OJhRNEDtacBry8U&e= > > ARIN Region per AS prefix count summary > --------------------------------------- > > ASN No of nets /20 equiv MaxAgg Description > 7155 4065 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US > 11492 3652 238 680 CABLEONE - CABLE ONE, INC., US > 6327 3477 1324 91 SHAW - Shaw Communications Inc., CA > 22773 3454 2973 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi > 16509 3078 6452 1466 AMAZON-02 - Amazon.com, Inc., US > 16625 2736 1438 1973 AKAMAI-AS - Akamai Technologies, Inc., > 30036 2187 349 175 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom > 20115 2145 2762 525 CHARTER-20115 - Charter Communications, > 18566 2086 405 105 MEGAPATH5-US - MegaPath Corporation, US > 5650 2074 3073 1453 FRONTIER-FRTR - Frontier Communications > > Complete listing at > https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n > et_current_data-2DASnet-2DARIN&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7 > AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfv > n9V7rEBtxr4BhRDk&s=CIzncYDw8a-DnoxhUAp7DWUjNn2IX6V3M86i77lM_m0&e= > > RIPE Region per AS prefix count summary > --------------------------------------- > > ASN No of nets /20 equiv MaxAgg Description > 12479 5515 1613 143 UNI2-AS, ES > 39891 3780 219 19 ALJAWWALSTC-AS, SA > 8551 3311 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne > 20940 2726 497 1927 AKAMAI-ASN1, US > 31334 2602 484 13 KABELDEUTSCHLAND-AS, DE > 12389 2392 2233 691 ROSTELECOM-AS, RU > 34984 2127 346 541 TELLCOM-AS, TR > 9121 2019 1692 18 TTNET, TR > 9009 1736 187 936 M247, GB > 13188 1604 100 47 TRIOLAN, UA > > Complete listing at > https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n > et_current_data-2DASnet-2DRIPE&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7 > AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfv > n9V7rEBtxr4BhRDk&s=uDvo14UbVZn0YyC6NlsLxcOaOYndnJvTWpBXOzpBVZo&e= > > LACNIC Region per AS prefix count summary > ----------------------------------------- > > ASN No of nets /20 equiv MaxAgg Description > 8151 6254 3360 597 Uninet S.A. de C.V., MX > 10620 3365 534 450 Telmex Colombia S.A., CO > 11830 2692 370 54 Instituto Costarricense de Electricidad > 6503 1611 378 415 Axtel, S.A.B. de C.V., MX > 7303 1480 1024 274 Telecom Argentina S.A., AR > 28573 1164 2228 203 CLARO S.A., BR > 6147 1105 380 35 Telefonica del Peru S.A.A., PE > 3816 1051 534 121 COLOMBIA TELECOMUNICACIONES S.A. ESP, C > 13999 1000 482 248 Mega Cable, S.A. de C.V., MX > 11172 936 110 60 Alestra, S. de R.L. de C.V., MX > > Complete listing at > https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n > et_current_data-2DASnet-2DLACNIC&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7 > c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVS > fvn9V7rEBtxr4BhRDk&s=Ftwh_dibDvvukWgmiQyjKpuLa1D7Bi6uPivsQenVhxg&e= > > AfriNIC Region per AS prefix count summary > ------------------------------------------ > > ASN No of nets /20 equiv MaxAgg Description > 24863 1120 393 23 LINKdotNET-AS, EG > 36992 956 1535 73 ETISALAT-MISR, EG > 24835 888 590 21 RAYA-AS, EG > 36903 843 424 112 MT-MPLS, MA > 8452 672 1859 20 TE-AS TE-AS, EG > 29571 527 68 11 ORANGE-COTE-IVOIRE, CI > 15399 414 45 11 WANANCHI-, KE > 37492 372 470 57 ORANGE-, TN > 37342 370 32 1 MOVITEL, MZ > 15706 362 32 6 Sudatel, SD > > Complete listing at > https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n > et_current_data-2DASnet-2DAFRINIC&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r= > 7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUV > Sfvn9V7rEBtxr4BhRDk&s=MaAFFJRgHsRzNLwOQOsdWeIcWNX2_SXT9wbvje-WYwQ&e= > > Global Per AS prefix count summary > ---------------------------------- > > ASN No of nets /20 equiv MaxAgg Description > 8151 6254 3360 597 Uninet S.A. de C.V., MX > 12479 5515 1613 143 UNI2-AS, ES > 7545 4947 599 579 TPG-INTERNET-AP TPG Telecom Limited, AU > 7155 4065 280 25 VIASAT-SP-BACKBONE - ViaSat,Inc., US > 39891 3780 219 19 ALJAWWALSTC-AS, SA > 11492 3652 238 680 CABLEONE - CABLE ONE, INC., US > 6327 3477 1324 91 SHAW - Shaw Communications Inc., CA > 22773 3454 2973 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi > 10620 3365 534 450 Telmex Colombia S.A., CO > 8551 3311 379 46 BEZEQ-INTERNATIONAL-AS Bezeqint Interne > > Complete listing at > https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n > et_current_data-2DASnet&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVc > wQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEB > txr4BhRDk&s=Ubo-mm8x9JieVKsZ4kCdiBNczmeQv_lE71J_lT6zH7Y&e= > > Global Per AS Maximum Aggr summary > ---------------------------------- > > ASN No of nets Net Savings Description > 12479 5515 5372 UNI2-AS, ES > 7545 4947 4368 TPG-INTERNET-AP TPG Telecom Limited, AU > 7155 4065 4040 VIASAT-SP-BACKBONE - ViaSat,Inc., US > 39891 3780 3761 ALJAWWALSTC-AS, SA > 6327 3477 3386 SHAW - Shaw Communications Inc., CA > 22773 3454 3298 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications > 8551 3311 3265 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo > 7552 3248 3216 VIETEL-AS-AP Viettel Group, VN > 11492 3652 2972 CABLEONE - CABLE ONE, INC., US > 45899 3065 2951 VNPT-AS-VN VNPT Corp, VN > > Complete listing at > https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n > et_current_data-2DCIDRnet&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoU > VcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7r > EBtxr4BhRDk&s=StsK1OcWFCXFDPmtA2zpqpiZK3VJGBvDvHsuCubppso&e= > > 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 > https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n > et_current_data-2DbadAS&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVc > wQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEB > txr4BhRDk&s=TiNvVceST9lHboIdLVqnl8Au2aXTDShRHMdl-Zhrhgg&e= > > 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 > https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n > et_current_data-2Dadd-2DIANA&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7Aj > RoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9 > V7rEBtxr4BhRDk&s=xLoG6gYbxBgRhNQtals5P8X769TNtK4-upYQN-dCIWU&e= > > 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:98 /12:288 > /13:573 /14:1142 /15:1915 /16:13259 /17:7983 /18:13735 > /19:25575 /20:40168 /21:47329 /22:95972 /23:77628 /24:441773 > /25:827 /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 4475 5515 UNI2-AS, ES > 6327 3265 3477 SHAW - Shaw Communications Inc., CA > 7155 3156 4065 VIASAT-SP-BACKBONE - ViaSat,Inc., US > 39891 2946 3780 ALJAWWALSTC-AS, SA > 11492 2865 3652 CABLEONE - CABLE ONE, INC., US > 8551 2764 3311 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo > 22773 2684 3454 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications > 31334 2490 2602 KABELDEUTSCHLAND-AS, DE > 11830 2040 2692 Instituto Costarricense de Electricidad y Telec > 18566 1981 2086 MEGAPATH5-US - MegaPath Corporation, US > > Complete listing at > https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n > et_current_data-2DsXXas-2Dnos&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7A > jRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn > 9V7rEBtxr4BhRDk&s=dIa10iqLN2fMwZSDIx7DJ1Ru6IxNJV2klsC1oDwrEuo&e= > > Number of /24s announced per /8 block (Global) > ---------------------------------------------- > > 1:1744 2:1092 3:6 4:22 5:3026 6:49 > 7:1 8:1359 9:1 12:1796 13:398 14:2112 > 15:42 16:7 17:269 18:81 20:56 23:2895 > 24:2589 25:2 27:2461 31:2711 32:106 35:37 > 36:906 37:3123 38:1808 39:302 40:121 41:3390 > 42:820 43:2071 44:173 45:10156 46:3359 47:271 > 49:1442 50:1103 51:341 52:1041 54:263 55:684 > 56:6 57:47 58:2054 59:1109 60:580 61:2181 > 62:1989 63:1848 64:5011 65:2234 66:4816 67:2738 > 68:1196 69:3573 70:1386 71:670 72:2666 74:2700 > 75:1291 76:596 77:2524 78:1963 79:2365 80:1816 > 81:1501 82:1137 83:961 84:1164 85:2356 86:562 > 87:1562 88:1060 89:2544 90:231 91:6597 92:1444 > 93:2485 94:2571 95:3639 96:954 97:340 98:951 > 99:829 100:88 101:944 102:639 103:21930 104:3635 > 105:281 106:816 107:1790 108:689 109:3751 110:1763 > 111:2021 112:1536 113:1408 114:1251 115:1722 116:1743 > 117:1962 118:2214 119:1642 120:1056 121:1039 122:2296 > 123:1838 124:1529 125:2020 128:1301 129:849 130:536 > 131:1819 132:747 133:226 134:1079 135:255 136:598 > 137:794 138:2073 139:939 140:567 141:879 142:773 > 143:1071 144:893 145:277 146:1334 147:857 148:1785 > 149:1021 150:820 151:1026 152:1370 153:362 154:4413 > 155:889 156:2254 157:1050 158:693 159:1934 160:1577 > 161:950 162:2990 163:827 164:1246 165:1188 166:515 > 167:1416 168:3467 169:474 170:4186 171:651 172:1711 > 173:2226 174:1039 175:989 176:2436 177:4043 178:2729 > 179:1473 180:2146 181:2385 182:2772 183:1115 184:2276 > 185:15447 186:3720 187:2572 188:3465 189:2068 190:8241 > 191:1438 192:10105 193:6717 194:5511 195:4193 196:3094 > 197:1728 198:5938 199:5957 200:7151 201:5173 202:10268 > 203:10241 204:4532 205:3058 206:3171 207:3231 208:3945 > 209:4292 210:3893 211:2019 212:3249 213:2955 214:1135 > 215:54 216:5890 217:2212 218:868 219:599 220:1929 > 221:972 222:981 223:1364 > > End of report From patrick at ianai.net Fri Aug 30 20:40:17 2019 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 30 Aug 2019 16:40:17 -0400 Subject: Weekly Routing Table Report In-Reply-To: References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> Message-ID: <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> The hope is the v6 DFZ will not grow nearly as fast because of far less fragmentation. But who knows? Also, even today TCAM ain’t cheap. Let’s hope it those numbers are not “nothing”. -- TTFN, patrick > On Aug 30, 2019, at 4:33 PM, Romeo Czumbil > wrote: > > These numbers are nothing. Wait till IPv6 really start taking off. > > > -----Original Message----- > From: NANOG > On Behalf Of Patrick W. Gilmore > Sent: Friday, August 30, 2019 3:09 PM > To: North American Operators' Group > > Subject: Re: Weekly Routing Table Report > > A very long time ago, I commented on this report hitting 250,000 prefixes. It was a Big F*#@$&! Deal at the time. A quarter million prefixes in the DFZ? Wow…. > > Then I did it again at 500,000. People commented that I should have waited for 512,000 - especially since a popular piece of kit was expected to fall over at 512K prefixes. But I said I liked round numbers. > > This time I waited for 768,000. (Everyone happy now?) > > To say “the Internet grew more than anyone expected” is beyond cliché these days, but that does not make it any less true. The Internet has transformed from a curiosity into something my son[*] and a good portion of his entire generation cannot conceive of living without. A great many people on this list had a part in making all that happen. > > Stop and think about that for a second. You had a part in literally changing the world. > > It is a 3-day weekend in the US. A good time to pause for a few minutes and consider what all of us accomplished together. Pat yourselves on the back, raise a glass or whatever your personal traditions are, and bask in the glory of a job well done. > > -- > TTFN, > patrick > > [*] The fact I can say “my son” is probably even more amazing. But that is a different story. > > >> On Aug 30, 2019, at 2:04 PM, Routing Analysis Role Account > wrote: >> >> 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 https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY&e= . >> >> If you have any comments please contact Philip Smith >. >> >> Routing Table Report 04:00 +10GMT Sat 31 Aug, 2019 >> >> Report Website: https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY&e= >> Detailed Analysis: >> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n >> et_current_&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpk >> Dj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s= >> 1SzKtCXB1OQXt_kKzDwHmtLE8a44hKEkYUtraUzC3gI&e= >> >> Analysis Summary >> ---------------- >> >> BGP routing table entries examined: 768323 >> Prefixes after maximum aggregation (per Origin AS): 295832 >> Deaggregation factor: 2.60 >> Unique aggregates announced (without unneeded subnets): 370810 >> Total ASes present in the Internet Routing Table: 65326 >> Prefixes per ASN: 11.76 >> Origin-only ASes present in the Internet Routing Table: 56226 >> Origin ASes announcing only one prefix: 24072 >> Transit ASes present in the Internet Routing Table: 9100 >> Transit-only ASes present in the Internet Routing Table: 269 >> Average AS path length visible in the Internet Routing Table: 4.3 >> Max AS path length visible: 45 >> Max AS path prepend of ASN ( 27978) 31 >> Prefixes from unregistered ASNs in the Routing Table: 27 >> Number of instances of unregistered ASNs: 27 >> Number of 32-bit ASNs allocated by the RIRs: 28444 >> Number of 32-bit ASNs visible in the Routing Table: 23268 >> Prefixes from 32-bit ASNs in the Routing Table: 105688 >> 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: 288 >> Number of addresses announced to Internet: 2834690304 >> Equivalent to 168 /8s, 245 /16s and 241 /24s >> Percentage of available address space announced: 76.6 >> Percentage of allocated address space announced: 76.6 >> 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: 257215 >> […] -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfsinoz at gmail.com Fri Aug 30 23:44:16 2019 From: pfsinoz at gmail.com (Philip Smith) Date: Sat, 31 Aug 2019 09:44:16 +1000 Subject: Weekly Routing Table Report In-Reply-To: <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> Message-ID: It doesn't bode well with deaggregation in IPv6 going down to the /48 in places I see it happen. A large chunk of the /48s out there are from /32s. If that carries on, we'll have to be more afraid then I remember us being at 30k IPv4 prefixes, 100k IPv4 prefixes, etc. :-( Actually when I started doing this back in early 1999, it was to supplement with a regional view of what Tony Bates was producing in the CIDR Report. Sloppy code on my part back then as we didn't have "too many prefixes". Didn't think I'd be doing this still, and have had to sort the code many times since too. :-) philip -- Patrick W. Gilmore wrote on 31/8/19 06:40 : > The hope is the v6 DFZ will not grow nearly as fast because of far less > fragmentation. > > But who knows? > > Also, even today TCAM ain’t cheap. Let’s hope it those numbers are not > “nothing”. > > --  > TTFN, > patrick > >> On Aug 30, 2019, at 4:33 PM, Romeo Czumbil >> > wrote: >> >> These numbers are nothing. Wait till IPv6 really start taking off. >> >> >> -----Original Message----- >> From: NANOG > >> On Behalf Of Patrick W. Gilmore >> Sent: Friday, August 30, 2019 3:09 PM >> To: North American Operators' Group > > >> Subject: Re: Weekly Routing Table Report >> >> A very long time ago, I commented on this report hitting 250,000 >> prefixes. It was a Big F*#@$&! Deal at the time. A quarter million >> prefixes in the DFZ? Wow…. >> >> Then I did it again at 500,000. People commented that I should have >> waited for 512,000 - especially since a popular piece of kit was >> expected to fall over at 512K prefixes. But I said I liked round numbers. >> >> This time I waited for 768,000. (Everyone happy now?) >> >> To say “the Internet grew more than anyone expected” is beyond cliché >> these days, but that does not make it any less true. The Internet has >> transformed from a curiosity into something my son[*] and a good >> portion of his entire generation cannot conceive of living without. A >> great many people on this list had a part in making all that happen. >> >> Stop and think about that for a second. You had a part in literally >> changing the world. >> >> It is a 3-day weekend in the US. A good time to pause for a few >> minutes and consider what all of us accomplished together. Pat >> yourselves on the back, raise a glass or whatever your personal >> traditions are, and bask in the glory of a job well done. >> >> -- >> TTFN, >> patrick >> >> [*] The fact I can say “my son” is probably even more amazing. But >> that is a different story. >> >> >>> On Aug 30, 2019, at 2:04 PM, Routing Analysis Role Account >>> > wrote: >>> >>> 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 https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY&e= . >>> >>> If you have any comments please contact Philip Smith >>> >. >>> >>> Routing Table Report   04:00 +10GMT Sat 31 Aug, 2019 >>> >>> Report Website: >>>     https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY&e=  >>> Detailed Analysis:   >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n >>> et_current_&d=DwIFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpk >>> Dj0XZUiEY9edXj7_CVNLE&m=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk&s= >>> 1SzKtCXB1OQXt_kKzDwHmtLE8a44hKEkYUtraUzC3gI&e= >>> >>> Analysis Summary >>> ---------------- >>> >>> BGP routing table entries examined:                              768323 >>>   Prefixes after maximum aggregation (per Origin AS):          295832 >>>   Deaggregation factor:                                          2.60 >>>   Unique aggregates announced (without unneeded subnets):      370810 >>> Total ASes present in the Internet Routing Table:                 65326 >>>   Prefixes per ASN:                                             11.76 >>> Origin-only ASes present in the Internet Routing Table:           56226 >>> Origin ASes announcing only one prefix:                           24072 >>> Transit ASes present in the Internet Routing Table:                9100 >>> Transit-only ASes present in the Internet Routing Table:            269 >>> Average AS path length visible in the Internet Routing Table:       4.3 >>>   Max AS path length visible:                                      45 >>>   Max AS path prepend of ASN ( 27978)                              31 >>> Prefixes from unregistered ASNs in the Routing Table:                27 >>>   Number of instances of unregistered ASNs:                        27 >>> Number of 32-bit ASNs allocated by the RIRs:                      28444 >>> Number of 32-bit ASNs visible in the Routing Table:               23268 >>> Prefixes from 32-bit ASNs in the Routing Table:                  105688 >>> 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:            288 >>> Number of addresses announced to Internet:                   2834690304 >>>   Equivalent to 168 /8s, 245 /16s and 241 /24s >>>   Percentage of available address space announced:               76.6 >>>   Percentage of allocated address space announced:               76.6 >>>   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:      257215 >>> > […] > From web at typo.org Sat Aug 31 00:40:18 2019 From: web at typo.org (Wayne Bouchard) Date: Fri, 30 Aug 2019 17:40:18 -0700 Subject: Weekly Routing Table Report In-Reply-To: <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> Message-ID: <20190831004018.GA14431@spider.typo.org> On Fri, Aug 30, 2019 at 03:09:24PM -0400, Patrick W. Gilmore wrote: > A very long time ago, I commented on this report hitting 250,000 prefixes. It was a Big F*#@$&! Deal at the time. A quarter million prefixes in the DFZ? Wow???. > > Then I did it again at 500,000. People commented that I should have waited for 512,000 - especially since a popular piece of kit was expected to fall over at 512K prefixes. But I said I liked round numbers. > > This time I waited for 768,000. (Everyone happy now?) No, actually! I came on board when there were about 32,000 prefixes and we were panicked about that. "CIDRize or die", I think Sean Doran said. I remember well the memory and cam struggles to keep up with growth. Its phenomenal, yes, but also, "WTF, PEOPLE??? CAN'T ANYONE AGGREGATE ANYMORE???" :) -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From surfer at mauigateway.com Sat Aug 31 02:15:17 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 30 Aug 2019 19:15:17 -0700 Subject: Weekly Routing Table Report Message-ID: <20190830191517.3E6999FA@m0117566.ppops.net> --- web at typo.org wrote: "WTF, PEOPLE??? CAN'T ANYONE AGGREGATE ANYMORE???" --------------------------------------- Is that like the NANOG version of "get off my lawn"? :) scott bgp since ~50k From list-nanog2 at dragon.net Sat Aug 31 02:27:10 2019 From: list-nanog2 at dragon.net (Paul Ebersman) Date: Fri, 30 Aug 2019 20:27:10 -0600 Subject: Weekly Routing Table Report In-Reply-To: <20190830191517.3E6999FA@m0117566.ppops.net> References: <20190830191517.3E6999FA@m0117566.ppops.net> Message-ID: <20190831022710.8324316F1AA3@fafnir.remote.dragon.net> web> "WTF, PEOPLE??? CAN'T ANYONE AGGREGATE ANYMORE???" surfer> Is that like the NANOG version of "get off my lawn"? :) Lawns? You had lawns? :) BGP when under 2k-ish and CLNP for sins in past lives... From web at typo.org Sat Aug 31 02:38:31 2019 From: web at typo.org (Wayne Bouchard) Date: Fri, 30 Aug 2019 19:38:31 -0700 Subject: Weekly Routing Table Report In-Reply-To: <20190830191517.3E6999FA@m0117566.ppops.net> References: <20190830191517.3E6999FA@m0117566.ppops.net> Message-ID: <20190831023831.GA15024@spider.typo.org> On Fri, Aug 30, 2019 at 07:15:17PM -0700, Scott Weeks wrote: > > > --- web at typo.org wrote: > > "WTF, PEOPLE??? CAN'T ANYONE AGGREGATE ANYMORE???" > --------------------------------------- > > > Is that like the NANOG version of "get off my lawn"? :) > > scott > bgp since ~50k Hah! "The internet woulda been perfect, if not for those meddling kids!" --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From valdis.kletnieks at vt.edu Sat Aug 31 02:50:04 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Fri, 30 Aug 2019 22:50:04 -0400 Subject: Weekly Routing Table Report In-Reply-To: <20190831022710.8324316F1AA3@fafnir.remote.dragon.net> References: <20190830191517.3E6999FA@m0117566.ppops.net> <20190831022710.8324316F1AA3@fafnir.remote.dragon.net> Message-ID: <274415.1567219804@turing-police> On Fri, 30 Aug 2019 20:27:10 -0600, Paul Ebersman said: > BGP when under 2k-ish and CLNP for sins in past lives... CLNP? Now there's a name I've not heard in a long time... (Go ahead, admit it, you read that in Alec Guiness's voice :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From bzs at theworld.com Sat Aug 31 04:40:00 2019 From: bzs at theworld.com (bzs at theworld.com) Date: Sat, 31 Aug 2019 00:40:00 -0400 Subject: Weekly Routing Table Report In-Reply-To: <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> Message-ID: <23913.64032.404654.526802@gargle.gargle.HOWL> On August 30, 2019 at 15:09 patrick at ianai.net (Patrick W. Gilmore) wrote: > > Stop and think about that for a second. You had a part in literally changing the world. Some of us had a part in literally creating TheWorld(.com) :-) -- -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 mohta at necom830.hpcl.titech.ac.jp Sat Aug 31 03:04:43 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 31 Aug 2019 12:04:43 +0900 Subject: Weekly Routing Table Report In-Reply-To: <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> Message-ID: <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> Patrick W. Gilmore wrote: > The hope is the v6 DFZ will not grow nearly as fast because of far > less fragmentation. As the problem is caused by multihomed sites (including ISPs), there is no such hope. With the current way of multihoming to compute available routes to multihomed sites by global routing system, the load, including routing table size, to the global routing system increases at least linearly to the number of multihomed sites. Some people was aware of the problem when the size was 50,000. With the current routing practice, the number will increase to 14M with IPv4 and a lot more than that with IPv6. The solution is: https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03 but IETF is working on stupid things like LISP only to increase load to the global routing system. > Also, even today TCAM ain’t cheap. Let’s hope it those numbers are > not "nothing". The problem is serious especially because Moore's law is ending. Masataka Ohta From owen at delong.com Sat Aug 31 09:05:27 2019 From: owen at delong.com (Owen DeLong) Date: Sat, 31 Aug 2019 02:05:27 -0700 Subject: Weekly Routing Table Report In-Reply-To: <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> Message-ID: <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> > On Aug 30, 2019, at 20:04 , Masataka Ohta wrote: > > Patrick W. Gilmore wrote: > >> The hope is the v6 DFZ will not grow nearly as fast because of far >> less fragmentation. > > As the problem is caused by multihomed sites (including ISPs), there > is no such hope. Part of the problem is caused by multi homed sites. Much more of the problem is actually caused by organizations needing multiple prefixes acquired over time through IPv4 slow start and other similar rationing mechanisms deployed to try and create a fair allocation strategy in light of IPv4 scarcity. Consider, for example AS7922 which originates the following 124 prefixes according to route-views: 23.7.80.0/20 23.24.0.0/15 23.30.0.0/15 23.33.186.0/24 23.40.176.0/20 23.41.0.0/20 23.49.56.0/24 23.58.92.0/24 23.67.49.0/24 23.68.0.0/14 23.194.116.0/22 23.213.134.0/23 23.217.129.0/24 24.0.0.0/12 24.16.0.0/13 24.30.0.0/17 24.34.0.0/16 24.40.0.0/18 24.40.64.0/20 24.60.0.0/14 24.91.0.0/16 24.98.0.0/15 24.104.0.0/17 24.104.128.0/19 24.118.0.0/16 24.124.128.0/17 24.125.0.0/16 24.126.0.0/15 24.128.0.0/16 24.129.0.0/17 24.130.0.0/15 24.147.0.0/16 24.153.64.0/19 24.218.0.0/16 24.245.0.0/18 50.73.0.0/16 50.76.0.0/14 50.128.0.0/9 50.227.16.0/22 50.227.20.0/22 64.56.32.0/19 64.139.64.0/19 65.34.128.0/17 65.96.0.0/16 66.30.0.0/15 66.41.0.0/16 66.56.0.0/18 66.176.0.0/15 66.208.192.0/18 66.229.0.0/16 66.240.0.0/18 67.160.0.0/11 68.32.0.0/11 68.80.0.0/13 68.86.80.0/20 69.136.0.0/13 69.180.0.0/15 69.240.0.0/12 70.88.0.0/14 71.24.0.0/14 71.56.0.0/13 71.192.0.0/12 71.224.0.0/12 72.55.0.0/17 72.247.190.0/24 74.16.0.0/12 74.92.0.0/14 74.144.0.0/12 75.64.0.0/13 75.72.0.0/15 75.74.0.0/16 75.75.0.0/17 75.75.128.0/18 75.144.0.0/13 76.16.0.0/12 76.96.0.0/11 76.128.0.0/11 96.6.80.0/20 96.17.145.0/24 96.17.164.0/24 96.17.165.0/24 96.17.166.0/24 96.64.0.0/11 96.96.0.0/12 96.112.0.0/13 96.120.0.0/14 96.124.0.0/16 96.128.0.0/10 96.192.0.0/11 98.32.0.0/11 98.192.0.0/10 104.69.216.0/22 104.69.220.0/23 104.70.48.0/20 104.70.64.0/20 104.70.178.0/24 104.77.121.0/24 104.77.150.0/24 104.109.53.0/24 107.0.0.0/14 107.4.0.0/15 162.148.0.0/14 173.8.0.0/13 173.160.0.0/13 173.222.176.0/22 174.48.0.0/12 174.160.0.0/11 184.25.157.0/24 184.28.64.0/23 184.28.68.0/23 184.28.117.0/24 184.51.52.0/22 184.51.207.0/24 184.86.251.0/24 184.108.0.0/14 184.112.0.0/12 198.0.0.0/16 198.137.252.0/23 198.178.8.0/21 204.11.116.0/22 208.39.128.0/18 209.23.192.0/22 209.23.192.0/18 216.45.128.0/17 A quick scan didn’t reveal significant overlap or even a lot of adjacent prefixes. As such, I don’t think you can blame multihoming or TE for this, but, rather organic customer growth and RIR applications over time. That’s the kind of prefix growth we should be able to mostly avoid in IPv6 that is rather rampant in IPv4. > With the current way of multihoming to compute available routes to > multihomed sites by global routing system, the load, including routing > table size, to the global routing system increases at least linearly > to the number of multihomed sites. Sure, but the number of multi homed sites is way _WAY_ less than the IPv4 routing table size. > Some people was aware of the problem when the size was 50,000. When the size was 50,000, that was the primary source of the problem. Today, long prefixes issued due to scarcity constitute a much larger fraction of the problem than multi homed sites originating single prefixes. > With the current routing practice, the number will increase to 14M > with IPv4 and a lot more than that with IPv6. I’m curious as to why you think that the number is bounded at 14M for IPv4 and why you think there will be so many more multi homed sites in IPv6? > The solution is: > > https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03 > > but IETF is working on stupid things like LISP only to increase > load to the global routing system. Not that you’d be prejudiced in favor of your own draft or anything. >> Also, even today TCAM ain’t cheap. Let’s hope it those numbers are >> not "nothing". > > The problem is serious especially because Moore's law is ending. People have been claiming that Moore’s law is at an end longer than we have been pushing for IPv6 deployment. TCAM ain’t cheap, but it’s also not the only solution to the problem and solutions are getting cheaper (per prefix) over time. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamv0025 at netconsultings.com Sat Aug 31 09:33:00 2019 From: adamv0025 at netconsultings.com (adamv0025 at netconsultings.com) Date: Sat, 31 Aug 2019 10:33:00 +0100 Subject: Weekly Routing Table Report In-Reply-To: <274415.1567219804@turing-police> References: <20190830191517.3E6999FA@m0117566.ppops.net> <20190831022710.8324316F1AA3@fafnir.remote.dragon.net> <274415.1567219804@turing-police> Message-ID: <017201d55fdf$14f56570$3ee03050$@netconsultings.com> > Sent: Saturday, August 31, 2019 3:50 AM > To: Paul Ebersman > > On Fri, 30 Aug 2019 20:27:10 -0600, Paul Ebersman said: > > > BGP when under 2k-ish and CLNP for sins in past lives... > > CLNP? Now there's a name I've not heard in a long time... > > (Go ahead, admit it, you read that in Alec Guiness's voice :) Ha, since reminiscing, anybody remembers the good old SNA or god forbid SDLC to mainframes and then rocking it over DLSW? Oh or here's another one Token-Ring routing anybody? We came quite a long way from these to current EVPN and SR-TE... But still I can't shake the feeling that back in the days architects were somewhat more ingenious coming up with these extraordinary designs to work around resource or protocol limitations. Now it's just down to simple slap more cpu/ram/tcam at the problem and you're done I feel. Nowadays boxes can easily take 5x the current 768 in tcam and in control-plane -only sky is the limit, so for example there's no need for any clever RR infrastructure designs anymore to hold all the routes in your AS control-plane. adam From mohta at necom830.hpcl.titech.ac.jp Sat Aug 31 09:51:16 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 31 Aug 2019 18:51:16 +0900 Subject: Weekly Routing Table Report In-Reply-To: <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> Message-ID: Owen DeLong wrote: > Consider, for example AS7922 COMCAST is not a good example. > but, rather organic customer growth and RIR applications over time. No, if you know theory and practice of how additional address ranges are allocated as a result of growth, you could have noticed that the large number of prefixes of COMCAST should mostly be a result of mergers, where merged parts won't renumber their hosts. > That’s the kind of prefix growth we should be able to mostly avoid in > IPv6 that is rather rampant in IPv4. Without automatic renumbering, IPv6 is of no help against mergers. > Sure, but the number of multi homed sites is way _WAY_ less than the > IPv4 routing table size. The following page by Geoff Huston is better than your delusion. http://www.potaroo.net/ispcolumn/2001-03-bgp.html What is driving this recent change to exponential growth of the routing table? In a word, multi-homing. >> With the current routing practice, the number will increase to 14M >> with IPv4 and a lot more than that with IPv6. > > I’m curious as to why you think that the number is bounded at 14M for > IPv4 and why you think there will be so many more multi homed sites > in IPv6? I don't think I must explain the current routing practice here. >> The problem is serious especially because Moore's law is ending. > > People have been claiming that Moore's law is at an end longer than > we have been pushing for IPv6 deployment. I'm afraid you are not very familiar with semiconductor technology trend. Masataka Ohta From nick at foobar.org Sat Aug 31 10:20:48 2019 From: nick at foobar.org (Nick Hilliard) Date: Sat, 31 Aug 2019 11:20:48 +0100 Subject: Weekly Routing Table Report In-Reply-To: <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> Message-ID: <25f66de1-456d-1721-a313-caf31f69ca61@foobar.org> Masataka Ohta wrote on 31/08/2019 04:04: > The solution is: > > https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03 > > but IETF is working on stupid things like LISP only to increase > load to the global routing system. nothing comes for free. Pushing the complexity down to the host level is not a "solution", just a workaround with its own set of problems. Nick From valdis.kletnieks at vt.edu Sat Aug 31 10:24:47 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Sat, 31 Aug 2019 06:24:47 -0400 Subject: Weekly Routing Table Report In-Reply-To: References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> Message-ID: <295201.1567247087@turing-police> On Sat, 31 Aug 2019 18:51:16 +0900, Masataka Ohta said: > Owen DeLong wrote: > >> With the current routing practice, the number will increase to 14M > >> with IPv4 and a lot more than that with IPv6. > > > > I$B!G(Bm curious as to why you think that the number is bounded at 14M fo r > > IPv4 and why you think there will be so many more multi homed sites > > in IPv6? > > I don't think I must explain the current routing practice here. Actually, maybe you *should* explain how it will grow to 14M IPv4 routes. Are there 13 million /24s still out there to be allocated? Where will these routes come from? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From mohta at necom830.hpcl.titech.ac.jp Sat Aug 31 10:35:39 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 31 Aug 2019 19:35:39 +0900 Subject: Weekly Routing Table Report In-Reply-To: <25f66de1-456d-1721-a313-caf31f69ca61@foobar.org> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <25f66de1-456d-1721-a313-caf31f69ca61@foobar.org> Message-ID: <3e8b8a52-38cb-eab5-5c57-e0b6cd6d3c11@necom830.hpcl.titech.ac.jp> Nick Hilliard wrote: >> The solution is: >> >> https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03 >> >> but IETF is working on stupid things like LISP only to increase >> load to the global routing system. > > nothing comes for free. Pushing the complexity down to the host > level is not a "solution", just a workaround with its own set of > problems. If you can't accept the following principle of the End to End argument: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. validity of which is demonstrated by the Internet, and insist that something complete and correct is not a solution but a workaround, feel free to keep using POTS not smart phones. Masataka Ohta From nick at foobar.org Sat Aug 31 10:46:42 2019 From: nick at foobar.org (Nick Hilliard) Date: Sat, 31 Aug 2019 11:46:42 +0100 Subject: Weekly Routing Table Report In-Reply-To: <3e8b8a52-38cb-eab5-5c57-e0b6cd6d3c11@necom830.hpcl.titech.ac.jp> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <25f66de1-456d-1721-a313-caf31f69ca61@foobar.org> <3e8b8a52-38cb-eab5-5c57-e0b6cd6d3c11@necom830.hpcl.titech.ac.jp> Message-ID: Masataka Ohta wrote on 31/08/2019 11:35: > If you can't accept the following principle of the End to End > argument: > >     The function in question can completely and correctly be >     implemented only with the knowledge and help of the >     application standing at the end points of the >     communication system. this is a straw man argument. E2E works regardless of the current network-based multihoming mechanism or the proposals in draft-ohta-e2e-multihoming. > validity of which is demonstrated by the Internet, and insist > that something complete and correct is not a solution > but a workaround Your proposal is almost a text-book case of RFC1925, section 6: > (6) It is easier to move a problem around (for example, by moving > the problem to a different part of the overall network > architecture) than it is to solve it. I.e. instead of having network level complexity, you're proposing to shift the problem to maintaining both state and network into the host level. No doubt it has some benefits, but this comes at the cost of bringing dfz complexity down to the host and all the consequent support, scaling and management headaches associated with that. I.e. the problem space shifts, but is not solved. > feel free to keep using POTS not smart phones. Thank you, I certainly will. Conversely, please feel free to use arguments instead of rhetoric. Nick From mohta at necom830.hpcl.titech.ac.jp Sat Aug 31 11:14:01 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 31 Aug 2019 20:14:01 +0900 Subject: Weekly Routing Table Report In-Reply-To: References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <25f66de1-456d-1721-a313-caf31f69ca61@foobar.org> <3e8b8a52-38cb-eab5-5c57-e0b6cd6d3c11@necom830.hpcl.titech.ac.jp> Message-ID: <3104aa51-0ae4-ec16-db87-f4f0eb9efbf5@necom830.hpcl.titech.ac.jp> Nick Hilliard wrote: >> If you can't accept the following principle of the End to End >> argument: >> >>      The function in question can completely and correctly be >>      implemented only with the knowledge and help of the >>      application standing at the end points of the >>      communication system. > > this is a straw man argument. The text is in the original paper on the principle: End-To-End Arguments in System Design J. H. SALTZER, D. P. REED, and D. D. CLARK http://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf > E2E works regardless of the current > network-based multihoming mechanism or the proposals in > draft-ohta-e2e-multihoming. As the next sentence of the paper is: Therefore, providing that questioned function as a feature of the communication system itself is not possible which means: Therefore, providing multihoming as a feature of the communication system itself is not possible you are wrong. > Your proposal is almost a text-book case of RFC1925, section 6: FYI, the rfc was published on 1 April. > I.e. instead of having network level complexity, you're proposing to > shift the problem to maintaining both state and network into the host > level. No doubt it has some benefits, but this comes at the cost of > bringing dfz complexity down to the host and all the consequent support, > scaling and management headaches associated with that. I.e. the problem > space shifts, but is not solved. So, you are joking, aren't you? > > feel free to keep using POTS not smart phones. > > Thank you, I certainly will. Conversely, please feel free to use > arguments instead of rhetoric. Instead of rhetoric, I argue by quoting from papers, hopefully not published on 1 April, validity of which is well recognized. Masataka Ohta From owen at delong.com Sat Aug 31 11:18:55 2019 From: owen at delong.com (Owen DeLong) Date: Sat, 31 Aug 2019 04:18:55 -0700 Subject: Weekly Routing Table Report In-Reply-To: References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> Message-ID: > On Aug 31, 2019, at 02:51 , Masataka Ohta wrote: > > Owen DeLong wrote: > >> Consider, for example AS7922 > > COMCAST is not a good example. It seemed as good as any… Also, note that many of the Comcast mergers ended up in other Comcast ASNs, possibly not changing ASNs either? However, since you don’t like Comcast, let’s try another one that has few (if any) mergers involved: AS6939 — 125 prefixes... 5.152.177.0/24 5.152.179.0/24 5.152.181.0/24 5.152.182.0/24 5.152.183.0/24 12.177.5.0/24 12.192.16.0/24 12.192.17.0/24 23.142.192.0/24 23.164.160.0/24 23.175.160.0/24 27.50.32.0/21 38.72.144.0/20 38.87.144.0/23 45.33.128.0/22 45.33.132.0/22 45.33.136.0/22 45.33.140.0/24 45.33.140.0/22 45.40.118.0/23 52.129.12.0/23 64.62.128.0/18 64.62.128.0/17 64.71.128.0/18 64.209.56.0/21 64.209.68.0/22 64.214.184.0/21 65.19.128.0/18 65.49.0.0/17 65.49.2.0/24 65.49.14.0/24 65.49.68.0/24 65.49.108.0/22 66.97.177.0/24 66.119.119.0/24 66.160.128.0/18 66.160.192.0/20 66.178.176.0/20 66.207.160.0/20 66.220.0.0/19 67.43.48.0/20 72.14.64.0/24 72.14.65.0/24 72.14.66.0/24 72.14.67.0/24 72.14.89.0/24 72.52.64.0/18 72.52.71.0/24 72.52.92.0/24 74.82.0.0/18 74.82.22.0/23 74.82.46.0/24 74.82.48.0/22 74.116.112.0/22 74.121.104.0/22 74.122.152.0/21 103.6.216.0/22 103.96.214.0/24 103.100.138.0/24 103.193.186.0/23 104.36.120.0/22 104.194.216.0/23 104.247.128.0/22 104.247.132.0/23 104.254.152.0/21 104.255.240.0/21 107.178.32.0/24 107.178.33.0/24 107.178.34.0/23 107.178.36.0/22 107.178.40.0/21 124.252.248.0/21 139.56.8.0/24 139.60.15.0/24 141.193.188.0/23 148.51.0.0/17 161.129.140.0/22 162.213.130.0/24 162.247.12.0/22 162.247.75.0/24 162.249.152.0/23 162.249.154.0/23 167.136.239.0/24 168.245.149.0/24 170.199.208.0/23 173.242.48.0/20 184.75.240.0/21 184.104.0.0/17 184.104.0.0/15 184.104.200.0/21 184.104.208.0/20 184.105.7.0/24 184.105.16.0/20 184.105.32.0/20 184.105.48.0/20 184.105.62.0/24 184.105.88.0/21 184.105.100.0/22 184.105.248.0/21 185.101.97.0/24 185.101.98.0/24 185.114.36.0/24 185.149.69.0/24 185.242.47.0/24 199.164.248.0/23 199.192.144.0/22 204.13.226.0/23 207.126.64.0/19 208.64.56.0/21 208.75.96.0/21 208.79.140.0/22 209.51.160.0/19 209.130.152.0/22 209.135.0.0/19 209.150.160.0/19 216.66.0.0/19 216.66.32.0/19 216.66.64.0/19 216.66.72.0/21 216.66.80.0/20 216.99.220.0/23 216.218.128.0/17 216.224.64.0/21 216.224.64.0/19 216.229.96.0/20 Admittedly some of this appears to be TE routes, but compare with: 2001::/32 2001:470::/32 2001:470:1A::/48 2001:DF2:7900::/48 2001:49E8::/32 2002::/16 2400:7A00::/32 2600:7000::/24 2602:FECA::/36 2602:FF06:725::/48 2604:A100:100::/48 2604:C800:FFFF::/48 2605:4C0::/32 2620:0:50C0::/48 2620:64:6000::/48 2620:138:C001::/48 2620:138:C002::/48 2A03:B2C0::/29 2A06:1C80::/32 2A09:2580::/29 2A09:2780::/29 2A09:3880::/29 2A09:3B80::/29 2A09:3D80::/29 2A09:E500::/29 2A09:F480::/29 2A09:FA80::/29 27 prefixes with most of them being obvious TE or customer carve-outs. In fact, the first prefix appears to be a bogon from the IANA reserve, so I’m not sure why HE is originating a route for that. If you still think this isn’t a good example, then pick a decent sized transit AS of your choosing and I’ll run their statistics. > >> but, rather organic customer growth and RIR applications over time. > > No, if you know theory and practice of how additional address ranges > are allocated as a result of growth, you could have noticed that the > large number of prefixes of COMCAST should mostly be a result of > mergers, where merged parts won't renumber their hosts. > >> That’s the kind of prefix growth we should be able to mostly avoid in >> IPv6 that is rather rampant in IPv4. > > Without automatic renumbering, IPv6 is of no help against mergers. Merging 10 organizations each of whom have 27 IPv6 prefixes = 270 prefixes. Merging 10 organizations each of whom have 125 IPv4 prefixes = 1250 prefixes. IPv6 is of some help even in the case of mergers… > >> Sure, but the number of multi homed sites is way _WAY_ less than the >> IPv4 routing table size. > > The following page by Geoff Huston is better than your delusion. > > http://www.potaroo.net/ispcolumn/2001-03-bgp.html > What is driving this recent change to exponential growth > of the routing table? > In a word, multi-homing. Yeah, not quite the whole story in that one word… Let’s look at what is driving that increase in “multihoming”… While it’s true that cost reduction for circuits has made multihoming more practical, it’s also true that IPv4 scarcity is driving a lot of this as ISPs are less and less willing to provide free addresses to customers driving the economics for smaller and smaller customers to get tiny fractions of space from the remaining limited pools at various RIRs (e.g. ARIN NRPM 4.10 set-aside for v6 transition, APNIC last /8 policy, RIPE last /8 policy, etc.). Once you’re getting to the point of BYOA with your ISP, it’s really not much of a farther step to get an ASN to go with that and turn on BGP. Geoff’s not entirely wrong about the economics he describes, but he does, IMHO, leave some things out. For example, he seems to completely ignore (doesn’t even mention) the fact that this latest exponential expansion also coincides with the rise of the IPv4 transfer markets and the fragmentation of previously solid large blocks (e.g. MIT’s /8, AMPR selling off a /10 from 44/8, lots of /16s being sold for /24 pieces, etc.). > >>> With the current routing practice, the number will increase to 14Mwith IPv4 and a lot more than that with IPv6. >> I’m curious as to why you think that the number is bounded at 14M for >> IPv4 and why you think there will be so many more multi homed sites >> in IPv6? > > I don't think I must explain the current routing practice here. You don’t need to explain the current routing practice, but if you want to be taken seriously, simply assuming that every possible /24 in IPv4 and/or every possible /48 in IPv6 will be eventually advertised is a case of reductio ad absurdum. I was trying to give you a chance to provide a better argument for your position. > >>> The problem is serious especially because Moore's law is ending. >> People have been claiming that Moore's law is at an end longer than >> we have been pushing for IPv6 deployment. > > I'm afraid you are not very familiar with semiconductor technology > trend. While I appreciate that you enjoy speaking to people in condescending tones, looking at the history and current trends shows that we are in a period where Moore’s law is leveling off. We’ve had such periods before and then someone eventually develops something new that leads to a resumption of the curve. Past examples have included sub micron technology, the shift from 5v0 to 3v3 and then later 1v8 core logic, etc. I stand by my statement. I have no idea what the next breakthrough will be, but I doubt that we have seen the last breakthrough in computing efficiency. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Sat Aug 31 11:19:32 2019 From: nick at foobar.org (Nick Hilliard) Date: Sat, 31 Aug 2019 12:19:32 +0100 Subject: Weekly Routing Table Report In-Reply-To: <3104aa51-0ae4-ec16-db87-f4f0eb9efbf5@necom830.hpcl.titech.ac.jp> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <25f66de1-456d-1721-a313-caf31f69ca61@foobar.org> <3e8b8a52-38cb-eab5-5c57-e0b6cd6d3c11@necom830.hpcl.titech.ac.jp> <3104aa51-0ae4-ec16-db87-f4f0eb9efbf5@necom830.hpcl.titech.ac.jp> Message-ID: <97ea229d-b263-a614-b951-195df95d59f8@foobar.org> Masataka Ohta wrote on 31/08/2019 12:14: >> Your proposal is almost a text-book case of RFC1925, section 6: > > FYI, the rfc was published on 1 April. I'm aware of the date that rfc1925 was published and the significance of the date, and also that rfc1925 was intended to take a humorous approach towards some very fundamental, recurrent themes which continue to present themselves in networking theory and practice. No-one is compelled to pay attention to anything rfc1925 for this reason, but anyone dismissing it will do so to their own disadvantage. >> I.e. instead of having network level complexity, you're proposing to >> shift the problem to maintaining both state and network into the host >> level. No doubt it has some benefits, but this comes at the cost of >> bringing dfz complexity down to the host and all the consequent >> support, scaling and management headaches associated with that. I.e. >> the problem space shifts, but is not solved. > > So, you are joking, aren't you? We need agree to disagree then. I wish you well. Nick From mohta at necom830.hpcl.titech.ac.jp Sat Aug 31 11:44:02 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 31 Aug 2019 20:44:02 +0900 Subject: Weekly Routing Table Report In-Reply-To: <97ea229d-b263-a614-b951-195df95d59f8@foobar.org> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <25f66de1-456d-1721-a313-caf31f69ca61@foobar.org> <3e8b8a52-38cb-eab5-5c57-e0b6cd6d3c11@necom830.hpcl.titech.ac.jp> <3104aa51-0ae4-ec16-db87-f4f0eb9efbf5@necom830.hpcl.titech.ac.jp> <97ea229d-b263-a614-b951-195df95d59f8@foobar.org> Message-ID: <1496016b-fbe0-cd4e-1c1c-7703830eebc3@necom830.hpcl.titech.ac.jp> Nick Hilliard wrote: >>> Your proposal is almost a text-book case of RFC1925, section 6: >> >> FYI, the rfc was published on 1 April. > > I'm aware of the date that rfc1925 was published and the significance > of the date, and also that rfc1925 was intended to take a humorous > approach towards some very fundamental, recurrent themes which > continue to present themselves in networking theory and practice. Thank you for your rhetoric. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Sat Aug 31 12:04:00 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 31 Aug 2019 21:04:00 +0900 Subject: Weekly Routing Table Report In-Reply-To: References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> Message-ID: <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> Owen DeLong wrote: > However, since you don’t like Comcast, let’s try another one that has > few (if any) mergers involved: I don't think so. > AS6939 — 125 prefixes... Are you spamming? > Admittedly some of this appears to be TE routes, but compare with: > > 2001::/32 2001:470::/32 2001:470:1A::/48 2001:DF2:7900::/48 If you are saying some merger happened before v6 transition, which explains why there are less v6 prefix than v4, I can agree with you. But, so what? >> Without automatic renumbering, IPv6 is of no help against mergers. > > Merging 10 organizations each of whom have 27 IPv6 prefixes = 270 > prefixes. Merging 10 organizations each of whom have 125 IPv4 > prefixes = 1250 prefixes. The number of prefixes by swamp is recognized to be not a problem even when we were discussing it in 1998 when there was only less than 50000 prefixes. >>> Sure, but the number of multi homed sites is way _WAY_ less than >>> the IPv4 routing table size. > Yeah, not quite the whole story in that one word… Let's look at what > is driving that increase in "multihoming"… OK. You admit that the problem is caused by multihoming. OK. >> I don't think I must explain the current routing practice here. > > You don’t need to explain the current routing practice, but if you > want to be taken seriously, simply assuming that every possible /24 > in IPv4 and/or every possible /48 in IPv6 will be eventually > advertised is a case of reductio ad absurdum. I was trying to give > you a chance to provide a better argument for your position. I don't think I need such chance as my argument is already good enough. > While I appreciate that you enjoy speaking to people in condescending > tones, looking at the history and current trends shows that we are in > a period where Moore's law is leveling off. I'm afraid you are not very familiar with semiconductor technology trend. Masataka Ohta From dougb at dougbarton.us Sat Aug 31 16:23:41 2019 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 31 Aug 2019 09:23:41 -0700 Subject: 44/8 In-Reply-To: <5AF8C324-8AB5-47E8-B903-512083D87CF1@delong.com> References: <20190719025758.GB29374@puck.nether.net> <5AF8C324-8AB5-47E8-B903-512083D87CF1@delong.com> Message-ID: On 8/27/19 8:52 PM, Owen DeLong wrote: > > >> On Jul 26, 2019, at 21:59 , Doug Barton > > wrote: >> >> 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? >> > > Certainly part of my anger is that I did not know some of them were > happening. Fair enough. > However, most of my anger is around the fact that: > 1.It never in a million years would have occurred to me that these > people who I also consider friends and also trust explicitly > would take this particular action without significant prior (and much > wider) consultation with the amateur radio community. > > 2.I believe this was done quietly and carefully orchestrated > specifically to avoid any risk of successful backlash by the time > the community became aware of this particular intended action. I have actually been in this exact same position, of knowing that a thing is the right thing to do, but also knowing that doing it would create a poop-storm. I don't know if your analysis is right or not, but if I had been in their shoes I probably would have done the same thing. > If you want to say shame on us for trusting these people and not > noticing the severe corporate governance problems with ARDC until > they took this particular action, then I suppose that’s a fair comment. No, I am not attempting to shame anyone (although I admit my message was a bit testy). My point is simply that all of this after-the-fact griping, in the absence of any proven harm, is probably not as much about the thing as it is about self-culpability in what lead up to the thing. But as humans it's hard to direct that anger towards ourselves, so it gets directed outwardly. So, no shame, as it's a very human reaction. But a little more self-awareness would not be out of place. >> 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? >> > All of those are good questions. I don’t have data to answer any of them So shouldn't actually looking at the space to determine if any real harm was done be the next step? Doug From ross at tajvar.io Sat Aug 31 20:17:21 2019 From: ross at tajvar.io (Ross Tajvar) Date: Sat, 31 Aug 2019 16:17:21 -0400 Subject: Weekly Routing Table Report In-Reply-To: <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> <1A6D71BB-0CF1-400C-B70D-265CA23BE855@delong.com> <53fd9402-ac22-ad1f-5966-4971cd9cb9ac@necom830.hpcl.titech.ac.jp> Message-ID: > I don't think I need such chance as my argument is already good enough. I'm curious if you're able to convince anyone that your thoughts are valid and correct with such an attitude. -------------- next part -------------- An HTML attachment was scrubbed... URL: From surfer at mauigateway.com Sat Aug 31 22:08:21 2019 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 31 Aug 2019 15:08:21 -0700 Subject: Weekly Routing Table Report Message-ID: <20190831150821.3E698C75@m0117566.ppops.net> From: Masataka Ohta If you can't accept the following principle of the End to End argument: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. ------------------------------------------------------- I have been reading your posts on IETF and here regarding the above and I'm curious as to your thoughts on John Day's RINA. It tosses all this on its head. scott From mohta at necom830.hpcl.titech.ac.jp Sat Aug 31 23:08:04 2019 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 1 Sep 2019 08:08:04 +0900 Subject: Weekly Routing Table Report In-Reply-To: <20190831150821.3E698C75@m0117566.ppops.net> References: <20190831150821.3E698C75@m0117566.ppops.net> Message-ID: <3a1f22b4-68e5-2bb6-9f9e-c2b0d1af9d16@necom830.hpcl.titech.ac.jp> Scott Weeks wrote: > I have been reading your posts on IETF and here regarding the > above and I'm curious as to your thoughts on John Day's RINA. As you give no reference, let's rely on wikipedia https://en.wikipedia.org/wiki/Recursive_Internetwork_Architecture and restrict scope only for multihoming. Then, it is true that: > 1972. Multi-homing not supported by the ARPANET. which means current specifications do not support multihoming very well. but, the statement > The solution was obvious: as in operating systems, a logical address > space naming the nodes (hosts and routers) was required on top of the > physical interface address space. is wrong, because it is enough to let transport layer identify connections based on a set of physical interface addresses of all the interfaces, which is what draft-ohta-e2e-multihoming-* proposes. That is, he misunderstand restrictions by the current specification something inevitably required by layering. > It tosses all this on its head. If you have some text of RINA denying the E2E argument, quote it with URLs please. Masataka Ohta From valdis.kletnieks at vt.edu Sat Aug 31 23:34:22 2019 From: valdis.kletnieks at vt.edu (Valdis Kl=?utf-8?Q?=c4=93?=tnieks) Date: Sat, 31 Aug 2019 19:34:22 -0400 Subject: Weekly Routing Table Report In-Reply-To: <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> References: <20190830180417.D106EC34BB@thyme.apnic.net> <47564EF6-B7AD-4E22-BB74-FB15C2C828E2@ianai.net> <6444C7AC-05E5-4AC8-A51B-DDC01C039801@ianai.net> <9a17eadf-058b-c509-161d-d2d82aacccf2@necom830.hpcl.titech.ac.jp> Message-ID: <328481.1567294462@turing-police> On Sat, 31 Aug 2019 12:04:43 +0900, Masataka Ohta said: > The solution is: > > https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03 All I see there is some handwaving about separating something from something else, without even a description of why it was better than what was available when you wrote the draft. I don't see anything about how it's supposed to work - for example, if my cell phone had an IP address via DHCP from my home wireless router but also has an IPv6 from cellular connection, how *exactly* does it *securely* fall back to cellular if a thunderstorn knocks out Comcast's gear in the area? It's little details like that which were why your IETF draft wasn't taken seriously, and your commentary today isn't doing any better. Try attaching an actual protocol specification - preferably one that you've actually got at least somewhat-working software to implement it. I guarantee that you'll learn a few things in the process... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 832 bytes Desc: not available URL: