Re: A letter from the CEO

[Mel Beckman]

Apparently, Ben didn’t use “safe and secure” fiber lines for his emails :)

 -mel

> On Nov 20, 2020, at 4:46 PM, Grant Taylor via NANOG  wrote:
> 
> On 11/20/20 4:41 PM, Matt Erculiani wrote:
>> Ben is fairly regular on this list and I can't imagine she did this on 
>> purpose.
> 
> How does one /accidentally/ harvest email addresses and /accidentally/ add 
> them to a Mailchimp list and /accidentally/ send emails with full header 
> personalization?
> 
> This *REALLY* seems like a blatant scrape of -- now I have a good idea -- the 
> NANOG mailing list.
> 
> I for one have black listed 6x7 on all email servers that I have 
> administrative control over.
> 
>> I'm sure she'll see this thread and fix it. Relax...
> 
> I don't know.  I think it was far more intentional than accidental.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 

Re: A letter from the CEO

[Chris Adams]

Once upon a time, Matt Erculiani  said:
> All mass-mail systems I'm aware of offer to scrape your own contacts when
> you first sign up.

Really?  Mailchimp scrapes your contacts to spam as "opt-in"?  If you
can show that's true, then Mailchimp needs to be blocked as spammers.

My experience with Mailchimp though requires you to submit addresses for
a list, so spam like this is purely intentional.
-- 
Chris Adams 

Re: Neteng field laptop/tablet

[Neil Hanlon]

I think the Galago Pro from System 76 probably fits the bill. It's a 14",
but has everything else you wanted, I believe.

They do have their own open (not sure of license) boot... Firmware? Called
core boot... So no bios (uefi or otherwise). Plus side is its all open
(free) drivers and firmware and such, I guess.

I was considering getting one as my next work laptop but went with a dell
because I needed more compute in a smaller package than System 76 has
(had).

Link: https://system76.com/laptops/galago#specs

-Neil

On Fri, Nov 20, 2020, 20:45 Brandon Martin  wrote:

> Sorry if this is perhaps a bit OT...
>
> Can anyone recommend a smallish (10-13" display), relatively lightweight
> tablet or laptop (or convertible) with a native PCIe multi-gig Ethernet
> port, ideally both 10GBASE-T + 2.5GBASE-T (and 5GBASE-T perhaps).  I'm not
> seeing a lot out there, and it's hard to search for multi-gig in a laptop
> at this point.
>
> Failing that, I'm sure someone has a recommendation for a similar device
> with native PCIe 1000BASE-T + a thunderbolt or similar port I can hang a
> dongle off of?
>
> Ruggedness is useful but not essential.  6-8 hour practical battery life
> is important but almost implied these days.  Must be able to nicely run
> Linux (distro is unimportant).
> --
> Brandon Martin
>

Re: Cable Company Hotspots

[Jay Hennigan]

On 11/20/20 15:26, Rod Beck wrote:

Hey Gang,

How do the cable companies generally deliver this service? A friend 
insists it piggybacks off the WIFI radios of existing cable company 
subscribers. In other words, the cable company WIFI router in a flat is 
providing both a private link for the flat's subscriber, but also a 
public hotspot service.


That's pretty much it. The cable provider typically provides a 
multi-function box that's a cable modem, NAT router, analog telephone 
adapter, and wi-fi hotspot. In addition to the SSID for individual 
customer use they by default have a generic SSID that is used by any 
roaming Comcast customer within range. This has a nasty habit of landing 
on the same channel as other devices and causing interference. The user 
interface doesn't show this or have any way of disabling it.


They provided one of these for my sister and of course their box wasn't 
exactly in the best place in the house for radio. I put in a proper 
access point and it took several phone calls to tech support to get them 
to turn off the radio in their box completely including the default 
roaming SSID. I was this >< close to opening the thing up to figure out 
which trace to cut when I finally got someone with enough clue to turn 
it off.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Neteng field laptop/tablet

[Brandon Martin]

Sorry if this is perhaps a bit OT...

Can anyone recommend a smallish (10-13" display), relatively lightweight tablet 
or laptop (or convertible) with a native PCIe multi-gig Ethernet port, ideally 
both 10GBASE-T + 2.5GBASE-T (and 5GBASE-T perhaps).  I'm not seeing a lot out 
there, and it's hard to search for multi-gig in a laptop at this point.

Failing that, I'm sure someone has a recommendation for a similar device with 
native PCIe 1000BASE-T + a thunderbolt or similar port I can hang a dongle off 
of?

Ruggedness is useful but not essential.  6-8 hour practical battery life is 
important but almost implied these days.  Must be able to nicely run Linux 
(distro is unimportant).
-- 
Brandon Martin

Re: A letter from the CEO

[Matt Erculiani]

> How does one /accidentally/ harvest email addresses and /accidentally/
> add them to a Mailchimp list and /accidentally/ send emails with full
> header personalization?

All mass-mail systems I'm aware of offer to scrape your own contacts when
you first sign up. Anyone who has ever started or replied to a Nanog thread
is in everyone else's contact list, including the list address itself.

I don't think the list was scraped, Ben's contacts were. One implies
malice, the other, a lack of foresight.

Ben is active enough here to know one would be crucified and/or humiliated
for scraping the list, both were the case here.

-Matt



On Fri, Nov 20, 2020 at 5:44 PM Grant Taylor via NANOG 
wrote:

> On 11/20/20 4:41 PM, Matt Erculiani wrote:
> > Ben is fairly regular on this list and I can't imagine she did this on
> > purpose.
>
> How does one /accidentally/ harvest email addresses and /accidentally/
> add them to a Mailchimp list and /accidentally/ send emails with full
> header personalization?
>
> This *REALLY* seems like a blatant scrape of -- now I have a good idea
> -- the NANOG mailing list.
>
> I for one have black listed 6x7 on all email servers that I have
> administrative control over.
>
> > I'm sure she'll see this thread and fix it. Relax...
>
> I don't know.  I think it was far more intentional than accidental.
>
>
>
> --
> Grant. . . .
> unix || die
>
>

-- 
Matt Erculiani
ERCUL-ARIN

Re: A letter from the CEO

[Dan Hollis]

On Fri, 20 Nov 2020, Grant Taylor via NANOG wrote:

On 11/20/20 4:41 PM, Matt Erculiani wrote:
Ben is fairly regular on this list and I can't imagine she did this on 
purpose.
How does one /accidentally/ harvest email addresses and /accidentally/ add 
them to a Mailchimp list and /accidentally/ send emails with full header 
personalization?


accidentally on purpose.

-Dan

Re: A letter from the CEO

[Mike Lyon]

It was also spammed to other lists as well...

-Mike

> On Nov 20, 2020, at 16:45, Grant Taylor via NANOG  wrote:
> 
> On 11/20/20 4:41 PM, Matt Erculiani wrote:
>> Ben is fairly regular on this list and I can't imagine she did this on 
>> purpose.
> 
> How does one /accidentally/ harvest email addresses and /accidentally/ add 
> them to a Mailchimp list and /accidentally/ send emails with full header 
> personalization?
> 
> This *REALLY* seems like a blatant scrape of -- now I have a good idea -- the 
> NANOG mailing list.
> 
> I for one have black listed 6x7 on all email servers that I have 
> administrative control over.
> 
>> I'm sure she'll see this thread and fix it. Relax...
> 
> I don't know.  I think it was far more intentional than accidental.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 

Re: Disney+ Geolocation (again)

[Josh Luthman]

Yes.  In the event I or someone has this problem, what is a network
operator supposed to do?

Question is directed at someone who can speak on behalf of Disney+ support.

On Fri, Nov 20, 2020, 7:21 PM Daniel Sterling 
wrote:

> On Fri, Nov 20, 2020 at 6:55 PM Josh Luthman 
> wrote:
>
>> OK so an email address that isn't supposed to be used but works or a
>> phone call that should be used and is pointless for the purposes of this
>> issue?
>>
>
> Are you just asking to confirm this is disney’s position?  it appears
> so!
>
> As an outsider who lurks and normally sees these issues resolved swiftly
> off list I find this all fascinating and hilarious.
>
> Who is a manager or high level engineer in charge at Disney streaming? I
> would like to make fun of them
>
> — Dan
>
>>

Re: A letter from the CEO

[Grant Taylor via NANOG]

On 11/20/20 4:41 PM, Matt Erculiani wrote:
Ben is fairly regular on this list and I can't imagine she did this on 
purpose.


How does one /accidentally/ harvest email addresses and /accidentally/ 
add them to a Mailchimp list and /accidentally/ send emails with full 
header personalization?


This *REALLY* seems like a blatant scrape of -- now I have a good idea 
-- the NANOG mailing list.


I for one have black listed 6x7 on all email servers that I have 
administrative control over.



I'm sure she'll see this thread and fix it.     Relax...


I don't know.  I think it was far more intentional than accidental.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Cable Company Hotspots

[Harry McGregor]

Hi,

Cable Cos do this in several ways.

Enabled hot spot on the cable provider cpe with separate ssid, sometimes the 
same channel sometimes dedicated radio and channel (I prefer the same channel 
as many areas have way too much noise).  This hotspot service is using it's own 
docsis channels and generally a tunnel.

Also many are installing wire or poll mounted access points for outdoor 
coverage.  These are not using anything at a customer location.

Harry

On November 20, 2020 4:26:33 PM MST, Rod Beck  
wrote:
>Hey Gang,
>
>How do the cable companies generally deliver this service? A friend
>insists it piggybacks off the WIFI radios of existing cable company
>subscribers. In other words, the cable company WIFI router in a flat is
>providing both a private link for the flat's subscriber, but also a
>public hotspot service.
>
>I concede it is possible, but I am skeptical that the high quality of
>hotspot service we get here in Budapest could be achieved that way.
>
>
>
>
>Roderick Beck
>
>VP of Business Development
>
>United Cable Company
>
>www.unitedcablecompany.com
>
>New York City & Budapest
>
>rod.b...@unitedcablecompany.com
>
>Budapest: 36-70-605-5144
>
>NJ: 908-452-8183
>
>
>[1467221477350_image005.png]

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Disney+ Geolocation (again)

[Daniel Sterling]

On Fri, Nov 20, 2020 at 6:55 PM Josh Luthman 
wrote:

> OK so an email address that isn't supposed to be used but works or a phone
> call that should be used and is pointless for the purposes of this issue?
>

Are you just asking to confirm this is disney’s position?  it appears
so!

As an outsider who lurks and normally sees these issues resolved swiftly
off list I find this all fascinating and hilarious.

Who is a manager or high level engineer in charge at Disney streaming? I
would like to make fun of them

— Dan

>

Re: Disney+ Geolocation (again)

[Josh Luthman]

OK so an email address that isn't supposed to be used but works or a phone
call that should be used and is pointless for the purposes of this issue?

Josh Luthman
24/7 Help Desk: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Fri, Nov 20, 2020 at 6:49 PM Seth Mattinen  wrote:

> On 11/20/20 3:29 PM, Jeff Mansukhani wrote:
> > Yes, per the support team, ISP and end-users would go throuh the same
> > initial point of contact to report issue so they may properly track and
> > redirect as appropriate.  Thank you.
>
>
> When I called the service rep had no idea what to do with an ISP calling
> in. Said they can't help without a subscriber account, nor escalate or
> open a ticket.
>
> ~Seth
>

Re: Disney+ Geolocation (again)

[Seth Mattinen]

On 11/20/20 3:29 PM, Jeff Mansukhani wrote:
Yes, per the support team, ISP and end-users would go throuh the same 
initial point of contact to report issue so they may properly track and 
redirect as appropriate.  Thank you.



When I called the service rep had no idea what to do with an ISP calling 
in. Said they can't help without a subscriber account, nor escalate or 
open a ticket.


~Seth

Re: Cable Company Hotspots

[Luke Guillory]

I believe they use a separate GRE tunnel back into their network to keep it 
separate from the local customers traffic.

They also do this for other ISPs that they have agreements with, Coz customers 
can use the Comcast hotspots vice versa.



Sent from my iPhone

On Nov 20, 2020, at 5:38 PM, Brandon Svec  wrote:

 *External Email: Use Caution*
Comcast does exactly that in the US.  Some people turn it off though.  I can't 
recall if just the guest hotspot can be disabled on it's own or you have to 
just turn off wireless completely and use your own kit.
Probably depends on the provided gear.

Slightly off topic, but the cellular providers here also sell femtocells to 
customers that want better cellular service in their home or office.  They 
basically offload (and charge) their customers to expand the coverage over the 
customer's own internet service.
Brandon Svec
15106862204 voice|sms
teamonesolutions.com


On Fri, Nov 20, 2020 at 3:28 PM Rod Beck 
mailto:rod.b...@unitedcablecompany.com>> wrote:
Hey Gang,

How do the cable companies generally deliver this service? A friend insists it 
piggybacks off the WIFI radios of existing cable company subscribers. In other 
words, the cable company WIFI router in a flat is providing both a private link 
for the flat's subscriber, but also a public hotspot service.

I concede it is possible, but I am skeptical that the high quality of hotspot 
service we get here in Budapest could be achieved that way.




Roderick Beck

VP of Business Development

United Cable Company

https://link.edgepilot.com/s/5ea8ed14/sFrYHVe990GXCR1yAfigNg?u=http://www.unitedcablecompany.com/

New York City & Budapest

rod.b...@unitedcablecompany.com

Budapest: 36-70-605-5144

NJ: 908-452-8183


[1467221477350_image005.png]


Links contained in this email have been replaced. If you click on a link in the 
email above, the link will be analyzed for known threats. If a known threat is 
found, you will not be able to proceed to the destination. If suspicious 
content is detected, you will see a warning.

Re: A letter from the CEO

[Matt Erculiani]

All,

Ben is fairly regular on this list and I can't imagine she did this on
purpose.

I'm sure she'll see this thread and fix it. Relax...

-Matt

On Fri, Nov 20, 2020 at 4:34 PM Peter Kristolaitis 
wrote:

> On 2020-11-20 6:06 p.m., Aaron C. de Bruyn via NANOG wrote:
>
> > high speed, safe, secure global fiber connectivity
>
> More importantly, can someone tell me what 'safe global fiber
> connectivity' is?  As opposed to 'unsafe global fiber connectivity'?
>
> Do these guys have the market cornered on not string fiber optic cable at
> throat-level across roads or something?
>
> Freaking marketing droids.
>
> -A
>
> Other providers don't account for the effects of photonic friction and the
> resulting generation of heat in their fiber lines.  This has resulted in at
> least one documented case of spontaneous combustion resulting in damage to
> fiber lines[1].
>
> 6x7 controls for photonic friction by utilizing its proprietary SPAM
> (Specified Photonic Agitation Moderation) technology.
>
> [1]  Uncle Cletus (1993)  Mind control, spontaneous combustion and other
> extraterrestrial phenoma.  *Lecture at Billy-Sue's house.*
>


-- 
Matt Erculiani
ERCUL-ARIN

Re: Cable Company Hotspots

[Brandon Svec]

Comcast does exactly that in the US.  Some people turn it off though.  I
can't recall if just the guest hotspot can be disabled on it's own or you
have to just turn off wireless completely and use your own kit.
Probably depends on the provided gear.

Slightly off topic, but the cellular providers here also sell femtocells to
customers that want better cellular service in their home or office.  They
basically offload (and charge) their customers to expand the coverage over
the customer's own internet service.
*Brandon Svec*

*15106862204 <15106862204> voice|sms**teamonesolutions.com
*


On Fri, Nov 20, 2020 at 3:28 PM Rod Beck 
wrote:

> Hey Gang,
>
> How do the cable companies generally deliver this service? A friend
> insists it piggybacks off the WIFI radios of existing cable company
> subscribers. In other words, the cable company WIFI router in a flat is
> providing both a private link for the flat's subscriber, but also a public
> hotspot service.
>
> I concede it is possible, but I am skeptical that the high quality of
> hotspot service we get here in Budapest could be achieved that way.
>
>
>
> Roderick Beck
> VP of Business Development
>
> United Cable Company
>
> www.unitedcablecompany.com
>
> New York City & Budapest
>
> rod.b...@unitedcablecompany.com
>
> Budapest: 36-70-605-5144
>
> NJ: 908-452-8183
>
>
> [image: 1467221477350_image005.png]
>

Re: A letter from the CEO

[Peter Kristolaitis]

On 2020-11-20 6:06 p.m., Aaron C. de Bruyn via NANOG wrote:

> high speed, safe, secure global fiber connectivity

More importantly, can someone tell me what 'safe global fiber 
connectivity' is?  As opposed to 'unsafe global fiber connectivity'?


Do these guys have the market cornered on not string fiber optic cable 
at throat-level across roads or something?


Freaking marketing droids.

-A


Other providers don't account for the effects of photonic friction and 
the resulting generation of heat in their fiber lines.  This has 
resulted in at least one documented case of spontaneous combustion 
resulting in damage to fiber lines[1].


6x7 controls for photonic friction by utilizing its proprietary SPAM 
(Specified Photonic Agitation Moderation) technology.


[1]  Uncle Cletus (1993)  Mind control, spontaneous combustion and other 
extraterrestrial phenoma. /Lecture at Billy-Sue's house./

Re[6]: Disney+ Geolocation (again)

[Jeff Mansukhani]

Yes, per the support team, ISP and end-users would go throuh the same initial 
point of contact to report issue so they may properly track and redirect as 
appropriate.  Thank you.

-- Original Message --
From: "Brian Turnbow" mailto:b.turn...@twt.it>>
To: "Jeff Mansukhani" mailto:j...@mansukhani.net>>; "Mike 
Hammett" mailto:na...@ics-il.net>>; 
"j...@imaginenetworksllc.com" 
mailto:j...@imaginenetworksllc.com>>
Cc: "nanog@nanog.org" 
mailto:nanog@nanog.org>>
Sent: 11/20/2020 11:32:45 AM
Subject: Re: Re[4]: Disney+ Geolocation (again)

Hi Jeff
That seems to be oriented twords end users, not isps.
Are you suggesting that isps call/chat customer service?
So there Is no noc to noc services available?

When I opened a chat saying that i was writing from an ISP the response was 
 What Is an ISP?

Thanks
Brian


Brian Turnbow

Da: Jeff Mansukhani mailto:j...@mansukhani.net>>
Inviato: venerdì 20 novembre 2020 20:17
A: Brian Turnbow; Mike Hammett; 
j...@imaginenetworksllc.com
Cc: nanog@nanog.org
Oggetto: Re[4]: Disney+ Geolocation (again)

HI all,

Sorry there is a misunderstanding.  Requests for Disney+ should go via 
https://help.disneyplus.com/csp instead.  Please kindly remove from your 
documentation and do not email  thse two @disneystreaming.com email addresses.

Thank you

J

-- Original Message --
From: "Brian Turnbow via NANOG" mailto:nanog@nanog.org>>
To: "Mike Hammett" mailto:na...@ics-il.net>>
Cc: "nanog@nanog.org" 
mailto:nanog@nanog.org>>
Sent: 11/16/2020 8:12:29 AM
Subject: RE: Re[2]: Disney+ Geolocation (again)

Hi Mike,

You may want to add
technical operations services team 
techops-servi...@disneystreaming.com

We wrote to the  distribution address and they replied forwarding it to services

Brian

From: NANOG 
mailto:nanog-bounces+b.turnbow=twt...@nanog.org>>
 On Behalf Of Mike Hammett
Sent: Friday, November 13, 2020 7:25 PM
To: Jeff Mansukhani mailto:j...@mansukhani.net>>
Cc: Nanog@nanog.org
Subject: Re: Re[2]: Disney+ Geolocation (again)

I updated our page.  :-)


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


From: "Jeff Mansukhani" mailto:j...@mansukhani.net>>
To: "Seth Mattinen" mailto:se...@rollernet.us>>, 
Nanog@nanog.org
Sent: Thursday, November 12, 2020 5:49:40 PM
Subject: Re[2]: Disney+ Geolocation (again)

Specifically for Network Operators, you may email
techops-distribut...@disneystreaming.com
 for technical issues relating
to Disney+.  Hope this helps.

Thanks

J

Cable Company Hotspots

[Rod Beck]

Hey Gang,

How do the cable companies generally deliver this service? A friend insists it 
piggybacks off the WIFI radios of existing cable company subscribers. In other 
words, the cable company WIFI router in a flat is providing both a private link 
for the flat's subscriber, but also a public hotspot service.

I concede it is possible, but I am skeptical that the high quality of hotspot 
service we get here in Budapest could be achieved that way.




Roderick Beck

VP of Business Development

United Cable Company

www.unitedcablecompany.com

New York City & Budapest

rod.b...@unitedcablecompany.com

Budapest: 36-70-605-5144

NJ: 908-452-8183


[1467221477350_image005.png]

Re: A letter from the CEO

[TJ Trout]

When I saw the 'lady ben cannon' I thought we were about to be the lucky
recipient of a large sum of money left by a prince, I'm fairly disappointed
now.

On Fri, Nov 20, 2020 at 3:09 PM Aaron C. de Bruyn via NANOG 
wrote:

> > high speed, safe, secure global fiber connectivity
>
> More importantly, can someone tell me what 'safe global fiber
> connectivity' is?  As opposed to 'unsafe global fiber connectivity'?
>
> Do these guys have the market cornered on not string fiber optic cable at
> throat-level across roads or something?
>
> Freaking marketing droids.
>
> -A
>
> On Fri, Nov 20, 2020 at 2:25 PM Josh Luthman 
> wrote:
>
>> Got this message to me directly as well as through the list.
>>
>> @6x7 this list is *NOT* to be scrapped for email addresses for your
>> marketing purposes.  This is complete garbage.  I'll be sending a message
>> directly to k...@6by7.net as well.
>>
>> Josh Luthman
>> 24/7 Help Desk: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> Suite 1337
>> Troy, OH 45373
>>
>>
>> On Fri, Nov 20, 2020 at 5:19 PM 6x7 Networks - Lady Benjamin, CEO <
>> b...@6by7.net> wrote:
>>
>>>
>>>
>>> *A letter from the CEO of 6x7: 6x7 Networks and Communications Authority
>>> of Kenya announce type approval to import 8tbps/second internet routers.*
>>>
>>> Hi, Lady Benjamin from 6x7 here, and I'm proud to share with you an
>>> update on me and the company.
>>>
>>> Through our adjunct division, 6x7 just received type approval from the
>>> Kenyan government to import core routers capable of over 8tbps (8 terrabits
>>> per second).  This will enable us to enter the Kenyan IP transit and
>>> transport markets, and service both datacenter and soon office buildings
>>> and eventually residences with high speed, safe, secure global fiber
>>> connectivity.   The market in Kenya is severely impacted now due to limited
>>> fiber availability, and 6x7 will leverage it's undersea connections to
>>> bring more wholesale bandwidth into the area, creating the economy by which
>>> we expect to grow.
>>> Thanks for reading, I'll be doing a regular set of these newsletters,
>>> and if you like them or want to reach out, please contact us at
>>> k...@6by7.net!
>>> -LB
>>> Ms. Lady Benjamin Cannon, ASCE.
>>> Find Out More
>>> 
>>> [image: Facebook]
>>> 
>>> [image: Twitter]
>>> 
>>> [image: Link]
>>> 
>>> [image: Website]
>>> 
>>> *Copyright © 2020 6x7 Networks, LLC, All rights reserved.*
>>> You are receiving this email because you opted in via our website.
>>>
>>> *Our mailing address is:*
>>> 6x7 Networks, LLC
>>> 44 montgomery st
>>> suite 2310
>>> San Francisco, CA 94104
>>>
>>> Add us to your address book
>>> 
>>>
>>>
>>> Want to change how you receive these emails?
>>> You can update your preferences
>>> 
>>> or unsubscribe from this list
>>> .
>>>
>>>
>>> [image: Email Marketing Powered by Mailchimp]
>>> 
>>>
>>

Re: A letter from the CEO

[Mel Beckman]

I’m sure the implication that “safe, secure” refers to less susceptibility to 
eavesdropping. But of course fiber can still be tapped trivially with 
angle-of-incidence intercept taps.

 -mel

On Nov 20, 2020, at 3:09 PM, Aaron C. de Bruyn via NANOG  
wrote:


> high speed, safe, secure global fiber connectivity

More importantly, can someone tell me what 'safe global fiber connectivity' is? 
 As opposed to 'unsafe global fiber connectivity'?

Do these guys have the market cornered on not string fiber optic cable at 
throat-level across roads or something?

Freaking marketing droids.

-A

On Fri, Nov 20, 2020 at 2:25 PM Josh Luthman 
mailto:j...@imaginenetworksllc.com>> wrote:
Got this message to me directly as well as through the list.

@6x7 this list is *NOT* to be scrapped for email addresses for your marketing 
purposes.  This is complete garbage.  I'll be sending a message directly to 
k...@6by7.net as well.

Josh Luthman
24/7 Help Desk: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Fri, Nov 20, 2020 at 5:19 PM 6x7 Networks - Lady Benjamin, CEO 
mailto:b...@6by7.net>> wrote:
[X]
A letter from the CEO of 6x7:

6x7 Networks and Communications Authority of Kenya announce type approval to 
import 8tbps/second internet routers.
[X]

Hi, Lady Benjamin from 6x7 here, and I'm proud to share with you an update on 
me and the company.

Through our adjunct division, 6x7 just received type approval from the Kenyan 
government to import core routers capable of over 8tbps (8 terrabits per 
second).  This will enable us to enter the Kenyan IP transit and transport 
markets, and service both datacenter and soon office buildings and eventually 
residences with high speed, safe, secure global fiber connectivity.   The 
market in Kenya is severely impacted now due to limited fiber availability, and 
6x7 will leverage it's undersea connections to bring more wholesale bandwidth 
into the area, creating the economy by which we expect to grow.

Thanks for reading, I'll be doing a regular set of these newsletters, and if 
you like them or want to reach out, please contact us at 
k...@6by7.net!

-LB
Ms. Lady Benjamin Cannon, ASCE.
Find Out 
More
[Facebook]
[Twitter]
[Link]
[Website]
Copyright © 2020 6x7 Networks, LLC, All rights reserved.
You are receiving this email because you opted in via our website.

Our mailing address is:
6x7 Networks, LLC
44 montgomery st
suite 2310
San Francisco, CA 94104

Add us to your address 
book


Want to change how you receive these emails?
You can update your 
preferences
 or unsubscribe from this 
list.

[Email Marketing Powered by 
Mailchimp]

Re: A letter from the CEO

[Aaron C. de Bruyn via NANOG]

> high speed, safe, secure global fiber connectivity

More importantly, can someone tell me what 'safe global fiber connectivity'
is?  As opposed to 'unsafe global fiber connectivity'?

Do these guys have the market cornered on not string fiber optic cable at
throat-level across roads or something?

Freaking marketing droids.

-A

On Fri, Nov 20, 2020 at 2:25 PM Josh Luthman 
wrote:

> Got this message to me directly as well as through the list.
>
> @6x7 this list is *NOT* to be scrapped for email addresses for your
> marketing purposes.  This is complete garbage.  I'll be sending a message
> directly to k...@6by7.net as well.
>
> Josh Luthman
> 24/7 Help Desk: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
> On Fri, Nov 20, 2020 at 5:19 PM 6x7 Networks - Lady Benjamin, CEO <
> b...@6by7.net> wrote:
>
>>
>>
>> *A letter from the CEO of 6x7: 6x7 Networks and Communications Authority
>> of Kenya announce type approval to import 8tbps/second internet routers.*
>>
>> Hi, Lady Benjamin from 6x7 here, and I'm proud to share with you an
>> update on me and the company.
>>
>> Through our adjunct division, 6x7 just received type approval from the
>> Kenyan government to import core routers capable of over 8tbps (8 terrabits
>> per second).  This will enable us to enter the Kenyan IP transit and
>> transport markets, and service both datacenter and soon office buildings
>> and eventually residences with high speed, safe, secure global fiber
>> connectivity.   The market in Kenya is severely impacted now due to limited
>> fiber availability, and 6x7 will leverage it's undersea connections to
>> bring more wholesale bandwidth into the area, creating the economy by which
>> we expect to grow.
>> Thanks for reading, I'll be doing a regular set of these newsletters, and
>> if you like them or want to reach out, please contact us at k...@6by7.net!
>> -LB
>> Ms. Lady Benjamin Cannon, ASCE.
>> Find Out More
>> 
>> [image: Facebook]
>> 
>> [image: Twitter]
>> 
>> [image: Link]
>> 
>> [image: Website]
>> 
>> *Copyright © 2020 6x7 Networks, LLC, All rights reserved.*
>> You are receiving this email because you opted in via our website.
>>
>> *Our mailing address is:*
>> 6x7 Networks, LLC
>> 44 montgomery st
>> suite 2310
>> San Francisco, CA 94104
>>
>> Add us to your address book
>> 
>>
>>
>> Want to change how you receive these emails?
>> You can update your preferences
>> 
>> or unsubscribe from this list
>> .
>>
>>
>> [image: Email Marketing Powered by Mailchimp]
>> 
>>
>

Re: inspecting RPKI data: console.rpki-client.org

[Job Snijders]

On Fri, Nov 20, 2020 at 12:02:04PM -0500, Tom Beecher wrote:
> In before snark of "OMG "http" links to RPKI info HURF BLURF!"

But Tom, that is exactly the whole point of the RPKI :-)

It's funny, but true! You really can safely use the RPKI data from the
console website in your own production environment, even after it has
been transported via mere HTTP - provided you have the TAL files to
build the chain of trust.

This applies also applies to the console's HTML itself: if you have the
TAL files + rpki-client + rsync + the openssl cli utility + ksh + perl;
you can generate any of the pages yourself and thus confirm their
authenticity and integrity.

Of course I don't expect anyone to jump through those hoops, but the
source code is here: https://github.com/job/console.rpki-client.org

I'll concede HTTPS does provide some privacy while looking at these
gorgeous ASN.1 data structures ;-)

Kind regards,

Job

Re: A letter from the CEO

[Josh Luthman]

Got this message to me directly as well as through the list.

@6x7 this list is *NOT* to be scrapped for email addresses for your
marketing purposes.  This is complete garbage.  I'll be sending a message
directly to k...@6by7.net as well.

Josh Luthman
24/7 Help Desk: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Fri, Nov 20, 2020 at 5:19 PM 6x7 Networks - Lady Benjamin, CEO <
b...@6by7.net> wrote:

>
>
> *A letter from the CEO of 6x7: 6x7 Networks and Communications Authority
> of Kenya announce type approval to import 8tbps/second internet routers.*
>
> Hi, Lady Benjamin from 6x7 here, and I'm proud to share with you an update
> on me and the company.
>
> Through our adjunct division, 6x7 just received type approval from the
> Kenyan government to import core routers capable of over 8tbps (8 terrabits
> per second).  This will enable us to enter the Kenyan IP transit and
> transport markets, and service both datacenter and soon office buildings
> and eventually residences with high speed, safe, secure global fiber
> connectivity.   The market in Kenya is severely impacted now due to limited
> fiber availability, and 6x7 will leverage it's undersea connections to
> bring more wholesale bandwidth into the area, creating the economy by which
> we expect to grow.
> Thanks for reading, I'll be doing a regular set of these newsletters, and
> if you like them or want to reach out, please contact us at k...@6by7.net!
> -LB
> Ms. Lady Benjamin Cannon, ASCE.
> Find Out More
> 
> [image: Facebook]
> 
> [image: Twitter]
> 
> [image: Link]
> 
> [image: Website]
> 
> *Copyright © 2020 6x7 Networks, LLC, All rights reserved.*
> You are receiving this email because you opted in via our website.
>
> *Our mailing address is:*
> 6x7 Networks, LLC
> 44 montgomery st
> suite 2310
> San Francisco, CA 94104
>
> Add us to your address book
> 
>
>
> Want to change how you receive these emails?
> You can update your preferences
> 
> or unsubscribe from this list
> .
>
>
> [image: Email Marketing Powered by Mailchimp]
> 
>

A letter from the CEO

[6x7 Networks - Lady Benjamin , CEO]

** A letter from the CEO of 6x7:

6x7 Networks and Communications Authority of Kenya announce type approval to 
import 8tbps/second internet routers.


Hi, Lady Benjamin from 6x7 here, and I'm proud to share with you an update on 
me and the company.

Through our adjunct division, 6x7 just received type approval from the Kenyan 
government to import core routers capable of over 8tbps (8 terrabits per 
second).  This will enable us to enter the Kenyan IP transit and transport 
markets, and service both datacenter and soon office buildings and eventually 
residences with high speed, safe, secure global fiber connectivity.   The 
market in Kenya is severely impacted now due to limited fiber availability, and 
6x7 will leverage it's undersea connections to bring more wholesale bandwidth 
into the area, creating the economy by which we expect to grow.


** Thanks for reading, I'll be doing a regular set of these newsletters, and if 
you like them or want to reach out, please contact us at k...@6by7.net!

-LB
Ms. Lady Benjamin Cannon, ASCE.
Find Out More 
(https://www.issuewire.com/6x7-networks-and-communications-authority-of-kenya-announce-type-approval-to-import-8tbpssecond-internet-routers-1683913778710913)


** Facebook (http://www.facebook.com)
** Twitter (http://www.twitter.com/)
** Link (http://www.instagram.com/)
** Website (http://mailchimp.com)
Copyright © 2020 6x7 Networks, LLC, All rights reserved.
 You are receiving this email because you opted in via our website.

Our mailing address is:
6x7 Networks, LLC
44 montgomery st
suite 2310
San Francisco, CA 94104
USA
Want to change how you receive these emails?
You can ** update your preferences 
(https://6x7networks.us19.list-manage.com/profile?u=6fbc79e84e5db9abf437b9601=4c3cb64e29=f2fa5478c3)
or ** unsubscribe from this list 
(https://6x7networks.us19.list-manage.com/unsubscribe?u=6fbc79e84e5db9abf437b9601=4c3cb64e29=f2fa5478c3=e143c275a6)
.
 Email Marketing Powered by Mailchimp
http://www.mailchimp.com/email-referral/?utm_source=freemium_newsletter_medium=email_campaign=referral_marketing=6fbc79e84e5db9abf437b9601=1

Re: Ingress filtering on transits, peers, and IX ports

[Brian Knight via NANOG]

As a final update to this thread, we started blocking spoofed and 
invalid traffic as of early Thursday morning Nov 19th.  So far, knock on 
wood, no reports of issues from our customer base.


In addition, I've been able to verify with the security research team's 
test tool that we are no longer responding to the spoofed DNS requests.


The ACL was implemented as follows:

Ingress

* Deny to and from bogon networks, where bogon is either source or dest
* Deny invalid TCP and UDP ports (currently only port 0) [log]
* Permit to and from transit / peer / IX connected subnets
* For IPv6, also permit link-local IPs (fe80::/10)
* Deny to and from multicast ranges 224.0.0.0/4 and ff00::/8
* Permit ICMP / traceroute over UDP to infrastructure
* Deny all other traffic to infrastructure [log]
* Permit from customer PI / PA space
* Deny from originated aggregate space [log]
* Permit all traffic to customer PI / PA space
* Permit all traffic to aggregate space
* Deny any any [log]

Egress

* Deny to and from bogon networks
* Deny invalid ports [log]
* Permit to and from transit / peer / IX connected subnets
* For IPv6, also permit link-local IPs
* Deny to and from multicast range
* Permit all traffic from any source to customer PI / PA space
* Permit all traffic from customer PI / PA space
* Permit all traffic from aggregate space
* Deny any any [log]

Below I've included the specific $VENDOR_C config I implemented for the 
filtering, sans specifics on our IP blocks.  I hope folks find this 
useful as a guide to their own efforts, and constructive criticism is 
always welcome.


Future work includes:

* Tightening the rules permitting access to/from the transit / peer / IX 
connected subnets, while keeping the ACL general enough for use on all 
Internet-facing interfaces
* Automation of updates to aggregate and customer IP blocks (looking at 
using the irrpt project for this)


Once more, to those who provided valuable input, thank you very much 
indeed!


-Brian


!-

! Static ACLs for Service Provider BCP 84 Compliance
! IOS XR config

! IPv4

object-group network ipv4 IPV4-BOGON
  description Invalid IPV4 networks
  0.0.0.0/8
  10.0.0.0/8
  100.64.0.0/10
  127.0.0.0/8
  169.254.0.0/16
  172.16.0.0/12
  192.0.0.0/24
  192.0.2.0/24
  192.168.0.0/16
  198.18.0.0/15
  198.51.100.0/24
  203.0.113.0/24
  240.0.0.0/4
exit

object-group network ipv4 IPV4-TRAN-WAN
  description Transit WAN PtP subnets
  [Point to point /30's go here]
exit

object-group network ipv4 IPV4-IX
  description IX subnets
  [IX /24 and /23 subnets here]
exit

object-group network ipv4 IPV4-PEER-WAN
  description Direct peer WAN PtP subnets
  [Direct peer WAN IPs go here]
exit

object-group network ipv4 IPV4-BGP-AGG
  description ARIN IPV4 Aggregate Blocks
  [Aggregated IP blocks go here]
exit

object-group network ipv4 IPV4-INFRA
  description Infrastructure subnets to be protected
  [List of loopback blocks and backbone / core PtP /30's here]
exit

object-group network ipv4 IPV4-BACKDOOR-HOSTS
  description Hosts observed to be sending valid traffic via Internet
  [One-off hosts, active TCP or UDP traffic was observed during data 
collection]

exit

object-group network ipv4 IPV4-CUST
  [full list of all customer IP blocks]
  [Includes customer PI blocks, disaggregated PA from other providers,]
  [and PA assigned from your aggregate space]
exit

object-group port TCPUDP-BLOCKED
  eq 0
  [additional ports to be generally blocked, list here]
exit

ipv4 access-list IPV4-INET-IN
  10 remark BCP 84 for transits, IX, and peering
  101 remark *** Block bogon networks as src or dest ***
  110 deny ipv4 net-group IPV4-BOGON any
  111 deny ipv4 any net-group IPV4-BOGON
  201 remark *** Blocked protocols ***
  210 deny udp any port-group TCPUDP-BLOCKED any log
  211 deny udp any any port-group TCPUDP-BLOCKED log
  212 deny tcp any port-group TCPUDP-BLOCKED any log
  213 deny tcp any any port-group TCPUDP-BLOCKED log
  301 remark *** Transit, IX, peer connected networks ***
  310 permit ipv4 net-group IPV4-PEER-WAN any
  311 permit ipv4 any net-group IPV4-PEER-WAN
  312 permit ipv4 net-group IPV4-TRAN-WAN any
  313 permit ipv4 any net-group IPV4-TRAN-WAN
  314 permit ipv4 net-group IPV4-IX any
  315 permit ipv4 any net-group IPV4-IX
  401 remark *** Block multicast ***
  410 deny ipv4 224.0.0.0/4 any
  411 deny ipv4 any 224.0.0.0/4
  501 remark *** Protect infrastructure subnets ***
  510 deny icmp any net-group IPV4-INFRA fragments log
  511 permit icmp any net-group IPV4-INFRA
  512 permit udp any range 1024 65535 net-group IPV4-INFRA range 33435 
33535
  513 permit udp any range 33435 33535 net-group IPV4-INFRA range 1024 
65535

  515 deny ipv4 any net-group IPV4-INFRA
  601 remark *** Customer Inet BGP Announced Prefixes ***
  620 permit ipv4 net-group IPV4-CUST any
  640 permit ipv4 net-group IPV4-BACKDOOR-HOSTS any
  701 remark *** Block originated networks ***
  710 deny ipv4 net-group IPV4-BGP-AGG any log
  801 remark *** Permit 

Re: Disney+ Geolocation (again)

[Seth Mattinen]

On 11/20/20 11:41 AM, Andy Ringsmuth wrote:

In other words: “oops, I shouldn’t have given out the secret e-mail addresses that 
actually work."





I did try calling, and it's just an end user dead end.

~Seth

Re: Disney+ Geolocation (again)

[Andy Ringsmuth]

In other words: “oops, I shouldn’t have given out the secret e-mail addresses 
that actually work."




Andy Ringsmuth
5609 Harding Drive
Lincoln, NE 68521-5831
(402) 304-0083
a...@andyring.com

“Better even die free, than to live slaves.” - Frederick Douglas, 1863

> On Nov 20, 2020, at 1:18 PM, Jeff Mansukhani  wrote:
> 
> HI all,
> 
> Sorry there is a misunderstanding.  Requests for Disney+ should go via 
> https://help.disneyplus.com/csp instead.  Please kindly remove from your 
> documentation and do not email  thse two @disneystreaming.com email addresses.
> 
> Thank you
> 
> J
> 
> -- Original Message --
> From: "Brian Turnbow via NANOG" 
> To: "Mike Hammett" 
> Cc: "nanog@nanog.org" 
> Sent: 11/16/2020 8:12:29 AM
> Subject: RE: Re[2]: Disney+ Geolocation (again)
> 
>> Hi Mike,
>>  
>> You may want to add   
>> technical operations services team techops-servi...@disneystreaming.com
>>  
>> We wrote to the  distribution address and they replied forwarding it to 
>> services
>>  
>> Brian
>>  
>> From: NANOG  On Behalf Of Mike 
>> Hammett
>> Sent: Friday, November 13, 2020 7:25 PM
>> To: Jeff Mansukhani 
>> Cc: Nanog@nanog.org
>> Subject: Re: Re[2]: Disney+ Geolocation (again)
>>  
>> I updated our page.  :-)
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> 
>> Midwest-IX
>> http://www.midwest-ix.com
>>  
>> From: "Jeff Mansukhani" 
>> To: "Seth Mattinen" , Nanog@nanog.org
>> Sent: Thursday, November 12, 2020 5:49:40 PM
>> Subject: Re[2]: Disney+ Geolocation (again)
>> 
>> Specifically for Network Operators, you may email 
>> techops-distribut...@disneystreaming.com for technical issues relating 
>> to Disney+.  Hope this helps.
>> 
>> Thanks
>> 
>> J

Re: Re[4]: Disney+ Geolocation (again)

[Brian Turnbow via NANOG]

Hi Jeff
That seems to be oriented twords end users, not isps.
Are you suggesting that isps call/chat customer service?
So there Is no noc to noc services available?

When I opened a chat saying that i was writing from an ISP the response was 
 What Is an ISP?

Thanks
Brian


Brian Turnbow

Da: Jeff Mansukhani 
Inviato: venerdì 20 novembre 2020 20:17
A: Brian Turnbow; Mike Hammett; j...@imaginenetworksllc.com
Cc: nanog@nanog.org
Oggetto: Re[4]: Disney+ Geolocation (again)

HI all,

Sorry there is a misunderstanding.  Requests for Disney+ should go via 
https://help.disneyplus.com/csp instead.  Please kindly remove from your 
documentation and do not email  thse two @disneystreaming.com email addresses.

Thank you

J

-- Original Message --
From: "Brian Turnbow via NANOG" mailto:nanog@nanog.org>>
To: "Mike Hammett" mailto:na...@ics-il.net>>
Cc: "nanog@nanog.org" 
mailto:nanog@nanog.org>>
Sent: 11/16/2020 8:12:29 AM
Subject: RE: Re[2]: Disney+ Geolocation (again)

Hi Mike,

You may want to add
technical operations services team 
techops-servi...@disneystreaming.com

We wrote to the  distribution address and they replied forwarding it to services

Brian

From: NANOG 
mailto:nanog-bounces+b.turnbow=twt...@nanog.org>>
 On Behalf Of Mike Hammett
Sent: Friday, November 13, 2020 7:25 PM
To: Jeff Mansukhani mailto:j...@mansukhani.net>>
Cc: Nanog@nanog.org
Subject: Re: Re[2]: Disney+ Geolocation (again)

I updated our page.  :-)


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


From: "Jeff Mansukhani" mailto:j...@mansukhani.net>>
To: "Seth Mattinen" mailto:se...@rollernet.us>>, 
Nanog@nanog.org
Sent: Thursday, November 12, 2020 5:49:40 PM
Subject: Re[2]: Disney+ Geolocation (again)

Specifically for Network Operators, you may email
techops-distribut...@disneystreaming.com
 for technical issues relating
to Disney+.  Hope this helps.

Thanks

J

Re[4]: Disney+ Geolocation (again)

[Jeff Mansukhani]

HI all,

Sorry there is a misunderstanding.  Requests for Disney+ should go via 
https://help.disneyplus.com/csp instead.  Please kindly remove from your 
documentation and do not email  thse two @disneystreaming.com email addresses.

Thank you

J

-- Original Message --
From: "Brian Turnbow via NANOG" mailto:nanog@nanog.org>>
To: "Mike Hammett" mailto:na...@ics-il.net>>
Cc: "nanog@nanog.org" 
mailto:nanog@nanog.org>>
Sent: 11/16/2020 8:12:29 AM
Subject: RE: Re[2]: Disney+ Geolocation (again)

Hi Mike,

You may want to add
technical operations services team 
techops-servi...@disneystreaming.com

We wrote to the  distribution address and they replied forwarding it to services

Brian

From: NANOG 
mailto:nanog-bounces+b.turnbow=twt...@nanog.org>>
 On Behalf Of Mike Hammett
Sent: Friday, November 13, 2020 7:25 PM
To: Jeff Mansukhani mailto:j...@mansukhani.net>>
Cc: Nanog@nanog.org
Subject: Re: Re[2]: Disney+ Geolocation (again)

I updated our page.  :-)


-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com


From: "Jeff Mansukhani" mailto:j...@mansukhani.net>>
To: "Seth Mattinen" mailto:se...@rollernet.us>>, 
Nanog@nanog.org
Sent: Thursday, November 12, 2020 5:49:40 PM
Subject: Re[2]: Disney+ Geolocation (again)

Specifically for Network Operators, you may email
techops-distribut...@disneystreaming.com
 for technical issues relating
to Disney+.  Hope this helps.

Thanks

J

Weekly Routing Table Report

[Routing Analysis Role Account]

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-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 21 Nov, 2020

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  835774
Prefixes after maximum aggregation (per Origin AS):  319021
Deaggregation factor:  2.62
Unique aggregates announced (without unneeded subnets):  398314
Total ASes present in the Internet Routing Table: 69979
Prefixes per ASN: 11.94
Origin-only ASes present in the Internet Routing Table:   60139
Origin ASes announcing only one prefix:   24893
Transit ASes present in the Internet Routing Table:9840
Transit-only ASes present in the Internet Routing Table:299
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  35
Max AS path prepend of ASN ( 45582)  27
Prefixes from unregistered ASNs in the Routing Table:   935
Number of instances of unregistered ASNs:   936
Number of 32-bit ASNs allocated by the RIRs:  34200
Number of 32-bit ASNs visible in the Routing Table:   28331
Prefixes from 32-bit ASNs in the Routing Table:  129951
Number of bogon 32-bit ASNs visible in the Routing Table:15
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:462
Number of addresses announced to Internet:   2865990144
Equivalent to 170 /8s, 211 /16s and 138 /24s
Percentage of available address space announced:   77.4
Percentage of allocated address space announced:   77.4
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  284118

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   217658
Total APNIC prefixes after maximum aggregation:   63654
APNIC Deaggregation factor:3.42
Prefixes being announced from the APNIC address blocks:  213242
Unique aggregates announced from the APNIC address blocks:87121
APNIC Region origin ASes present in the Internet Routing Table:   11033
APNIC Prefixes per ASN:   19.33
APNIC Region origin ASes announcing only one prefix:   3128
APNIC Region transit ASes present in the Internet Routing Table:   1609
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 31
Number of APNIC region 32-bit ASNs visible in the Routing Table:   6156
Number of APNIC addresses announced to Internet:  779023744
Equivalent to 46 /8s, 110 /16s and 245 /24s
APNIC AS Blocks4608-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-143673
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:242531
Total ARIN prefixes after maximum aggregation:   111606
ARIN Deaggregation factor: 2.17
Prefixes being announced from the ARIN address blocks:   240572
Unique aggregates announced from the ARIN address blocks:115191
ARIN Region origin ASes present in the Internet Routing Table:18691
ARIN Prefixes per ASN:12.87
ARIN 

RE: Akamai TE Contacts

[Robert Mercier]

I am having a very similar issue with reaching their NOC for Geolocation and TE 
issues.  Getting circular routing between various departments and groups within 
their organization, and have given up on emailing them now.

Anyone listening from Akamai, please reach out to me as well.

Thanks,

Rob



Robert Mercier | Senior Network Services Lead
rmerc...@nextdimensioninc.com
Tel: 1-800-461-0585 ext 421
www.nextdimensioninc.com


Follow us on:
[http://www.nextdimensioninc.com/static/facebook-icon.jpg]
  [http://www.nextdimensioninc.com/static/twitter-icon.jpg] 
   
[http://www.nextdimensioninc.com/static/linkedin-icon.jpg] 



[http://www.nextdimensioninc.com/static/banner.jpg]




From: NANOG  On Behalf 
Of Robert Carstens
Sent: November 20, 2020 11:48 AM
To: nanog@nanog.org
Subject: Akamai TE Contacts

Does anyone have a contact for someone at Akamai besides the standard 
Netsupport and tix emails? Or if anyone from Akamai is on the list, can you 
please contact me off list?

We are in need of assistance with TE for Akamai sourced traffic since standard 
methods are not doable with their CDN. Their NOG presentations usually say to 
contact them if you need assistance with adjusting traffic flows, but I cannot 
get a response. We have been contacting them for over a month now with no 
acknowledgement.

Robert

Re: inspecting RPKI data: console.rpki-client.org

[Tom Beecher]

In before snark of "OMG "http" links to RPKI info HURF BLURF!"

( Just add the 's' yourself kids, Job is a good boy and does have this
properly TLS'd. :) )

Thank you Job, excellent tool!

On Fri, Nov 20, 2020 at 9:08 AM Job Snijders  wrote:

> Dear all,
>
> I'd like to introduce another tool to inspect RPKI data... the
> rpki-client console! Comes with an authentic 90s look & feel :-)
>
> The Frontpage - http://console.rpki-client.org/
> ---
> On the front page you can see stdout + stderr of the most recent
> rpki-client run. The log shows which publication points were contacted
> and prints any issues encountered with specific RPKI files.
>
> Those of us publishing RPKI data should keep an eye out not to show up
> in this type of log with warnings or errors. For example:
>
> rpki-client: cc.rg.net/rpki/RGnet-cc/1opByAd8x8R2F-SzstgaYzVXK8Q.mft:
> mft expired on Oct 12 17:58:45 2020 GMT
>
> However, the above line might be the result of some kind of experiment
> someone is conducting :-)
>
> The RPKI distributed database currently is more than 120,000 (!)
> certificate/roa/manifest files, and only a handful of files have some
> kind of completeness or expiration date issue. Good job everyone! :-)
>
> The ASN specific pages - http://console.rpki-client.org/AS2914.html
> ---
> You can substitute the 'AS2914' portion in the URL for any ASN to see
> which .roa files reference the given ASN. Another example, here one can
> see all ROAs which authorize AS 8283 as origin:
> https://console.rpki-client.org/AS8283.html
> If you encounter a HTTP 404 error, no ROAs reference the ASN.
>
> On the 'per ASN page' you can search click the .roa files on the left
> side to inspect the ROA. Each object in the RPKI has a unique Subject
> Key Identifier (SKI). An example of a SKI is this hexadecimal identifier
> '06:96:B3:F7:CC:AD:55:45:A5:3A:64:32:31:2B:7F:E1:2B:7A:15:22' which
> maps to a filename like '
> rpki.apnic.net/member_repository/A91A4C60/B526FF74D84111E9A4521413C4F9AE02/12F0D72E7BC111EA8503D815C4F9AE02.roa
> '
>
> Yeah... compared to DNS names mapping to IPv6 addresses, in the RPKI
> neither the path name nor the SKI are easy to remember :-)
>
> The console can show that .roa file in human readable format, just
> append .html:
> http://console.rpki-client.org/rpki.apnic.net/member_repository/A91A4C60/B526FF74D84111E9A4521413C4F9AE02/12F0D72E7BC111EA8503D815C4F9AE02.roa.html
>
> Every object in the RPKI is subordinate to another object (all objects
> are signed by a parent certificate, except the Trust Anchors). The
> parent is identified by the Authority Key Identifier (AKI). So one
> object's AKI is another object's SKI! If you click the AKI, the console
> brings you to the parent object, from where you can continue to explore
> other objects related to parent.
>
> Certificates point to Manifests, and .mft files contain the 'directory
> indexes' of the RPKI:
> http://console.rpki-client.org/rpki.apnic.net/member_repository/A91A4C60/B526FF74D84111E9A4521413C4F9AE02/nvnkN242ZTJ1x5Y1mNa0W3CvgJk.mft.html
> From the manifest overview you can jump to the parent, click the
> referenced .roa, .cer or .crl files.
>
> All directories on the webserver are 'open', except the root. This
> allows you to explore this RPKI cache by browsing through the filesystem
> directly, example:
> http://console.rpki-client.org/rpki.apnic.net/member_repository/
>
> Final notes
> ---
> The rpki-client console provides a view on *validated* RPKI data. First
> rpki-client runs and prunes bad files, then all HTML is generated. The
> console provides a view on the data as used in production Internet
> routers. Please note: the console's rendering is delayed by a bit over
> an hour compared to the real thing.
>
> Another entry point, you can use your browser's 'find on page' function
> to search for anything in all of it on this humongous page:
> http://console.rpki-client.org/roas.html
>
> The RPKI is very intricate collection of references, I hope this console
> offers another useful perspective on the tree-like structures. Enjoy!
>
> Kind regards,
>
> Job
>

Akamai TE Contacts

[Robert Carstens]

Does anyone have a contact for someone at Akamai besides the standard
Netsupport and tix emails? Or if anyone from Akamai is on the list, can you
please contact me off list?

We are in need of assistance with TE for Akamai sourced traffic since
standard methods are not doable with their CDN. Their NOG presentations
usually say to contact them if you need assistance with adjusting traffic
flows, but I cannot get a response. We have been contacting them for over a
month now with no acknowledgement.

Robert

Re: inspecting RPKI data: console.rpki-client.org

[Paschal Masha]

Thank You!



*Paschal Masha*
Lead Network Engineer
6x7 Networks | +254735071089
Time Zone:GMT+3


On Fri, Nov 20, 2020 at 5:09 PM Job Snijders  wrote:

> Dear all,
>
> I'd like to introduce another tool to inspect RPKI data... the
> rpki-client console! Comes with an authentic 90s look & feel :-)
>
> The Frontpage - http://console.rpki-client.org/
> ---
> On the front page you can see stdout + stderr of the most recent
> rpki-client run. The log shows which publication points were contacted
> and prints any issues encountered with specific RPKI files.
>
> Those of us publishing RPKI data should keep an eye out not to show up
> in this type of log with warnings or errors. For example:
>
> rpki-client: cc.rg.net/rpki/RGnet-cc/1opByAd8x8R2F-SzstgaYzVXK8Q.mft:
> mft expired on Oct 12 17:58:45 2020 GMT
>
> However, the above line might be the result of some kind of experiment
> someone is conducting :-)
>
> The RPKI distributed database currently is more than 120,000 (!)
> certificate/roa/manifest files, and only a handful of files have some
> kind of completeness or expiration date issue. Good job everyone! :-)
>
> The ASN specific pages - http://console.rpki-client.org/AS2914.html
> ---
> You can substitute the 'AS2914' portion in the URL for any ASN to see
> which .roa files reference the given ASN. Another example, here one can
> see all ROAs which authorize AS 8283 as origin:
> https://console.rpki-client.org/AS8283.html
> If you encounter a HTTP 404 error, no ROAs reference the ASN.
>
> On the 'per ASN page' you can search click the .roa files on the left
> side to inspect the ROA. Each object in the RPKI has a unique Subject
> Key Identifier (SKI). An example of a SKI is this hexadecimal identifier
> '06:96:B3:F7:CC:AD:55:45:A5:3A:64:32:31:2B:7F:E1:2B:7A:15:22' which
> maps to a filename like '
> rpki.apnic.net/member_repository/A91A4C60/B526FF74D84111E9A4521413C4F9AE02/12F0D72E7BC111EA8503D815C4F9AE02.roa
> '
>
> Yeah... compared to DNS names mapping to IPv6 addresses, in the RPKI
> neither the path name nor the SKI are easy to remember :-)
>
> The console can show that .roa file in human readable format, just
> append .html:
> http://console.rpki-client.org/rpki.apnic.net/member_repository/A91A4C60/B526FF74D84111E9A4521413C4F9AE02/12F0D72E7BC111EA8503D815C4F9AE02.roa.html
>
> Every object in the RPKI is subordinate to another object (all objects
> are signed by a parent certificate, except the Trust Anchors). The
> parent is identified by the Authority Key Identifier (AKI). So one
> object's AKI is another object's SKI! If you click the AKI, the console
> brings you to the parent object, from where you can continue to explore
> other objects related to parent.
>
> Certificates point to Manifests, and .mft files contain the 'directory
> indexes' of the RPKI:
> http://console.rpki-client.org/rpki.apnic.net/member_repository/A91A4C60/B526FF74D84111E9A4521413C4F9AE02/nvnkN242ZTJ1x5Y1mNa0W3CvgJk.mft.html
> From the manifest overview you can jump to the parent, click the
> referenced .roa, .cer or .crl files.
>
> All directories on the webserver are 'open', except the root. This
> allows you to explore this RPKI cache by browsing through the filesystem
> directly, example:
> http://console.rpki-client.org/rpki.apnic.net/member_repository/
>
> Final notes
> ---
> The rpki-client console provides a view on *validated* RPKI data. First
> rpki-client runs and prunes bad files, then all HTML is generated. The
> console provides a view on the data as used in production Internet
> routers. Please note: the console's rendering is delayed by a bit over
> an hour compared to the real thing.
>
> Another entry point, you can use your browser's 'find on page' function
> to search for anything in all of it on this humongous page:
> http://console.rpki-client.org/roas.html
>
> The RPKI is very intricate collection of references, I hope this console
> offers another useful perspective on the tree-like structures. Enjoy!
>
> Kind regards,
>
> Job
>

Re: ARIN hosted RPKI key rotation

[Ca By]

On Fri, Nov 20, 2020 at 8:12 AM Christopher Morrow 
wrote:

> On Fri, Nov 20, 2020 at 10:59 AM TJ Trout  wrote:
> >
> > I believe it's manual, ten years and you need to update the roa.
> >
>
> I don't think 10yrs is correct... I do think you'd be responsible for
> re-publishing your content periodically though.


Can anyone point me to a procedure on how this can be done safely using
arin machinery ?


> Looking at, quite a handy tool, job's console.rpki-client.org for a
> set of things that concern me, this one in particular:
>   (one particular ROA)
>   <
> http://console.rpki-client.org/rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/f60c9f32-a87c-4339-a2f3-6299a3b02e29/5e9328a9-e1d2-45d8-bdb5-eefe152994f9/c130a86a-6524-3fd7-9dbf-338bc9d5a0a7.roa.html
> >
>
> Validity
> Not Before: Aug 18 04:00:00 2020 GMT
> Not After : Nov 20 05:00:00 2022 GMT
>
> Oh, I do see that the parent cert here is:
>   <
> http://console.rpki-client.org/rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/f60c9f32-a87c-4339-a2f3-6299a3b02e29/5e9328a9-e1d2-45d8-bdb5-eefe152994f9.cer.html
> >
>
> which has:
>Validity
> Not Before: Oct  1 11:28:43 2019 GMT
> Not After : Oct  1 11:28:43 2029 GMT
>
> This is, I think, actually controlled by ARIN, it has the subordinate
> resources from ARIN -> this-org
> in it... so at least the content of this file is generated/maintained
> by the parent (RIR in this case).
>
> > On Fri, Nov 20, 2020, 6:55 AM Ca By  wrote:
> >>
> >> Hello folks,
> >>
> >> I use ARIN hosted RPKI to publish ROAs
> >>
> >> The ROAs have an expire date
> >>
> >> How do i rotate the cert to push out the expiration date?  Does ARIN do
> this for me?
> >>
> >> Thanks!
>

Re: ARIN hosted RPKI key rotation

[Christopher Morrow]

On Fri, Nov 20, 2020 at 10:59 AM TJ Trout  wrote:
>
> I believe it's manual, ten years and you need to update the roa.
>

I don't think 10yrs is correct... I do think you'd be responsible for
re-publishing your content periodically though.
Looking at, quite a handy tool, job's console.rpki-client.org for a
set of things that concern me, this one in particular:
  (one particular ROA)
  


Validity
Not Before: Aug 18 04:00:00 2020 GMT
Not After : Nov 20 05:00:00 2022 GMT

Oh, I do see that the parent cert here is:
  


which has:
   Validity
Not Before: Oct  1 11:28:43 2019 GMT
Not After : Oct  1 11:28:43 2029 GMT

This is, I think, actually controlled by ARIN, it has the subordinate
resources from ARIN -> this-org
in it... so at least the content of this file is generated/maintained
by the parent (RIR in this case).

> On Fri, Nov 20, 2020, 6:55 AM Ca By  wrote:
>>
>> Hello folks,
>>
>> I use ARIN hosted RPKI to publish ROAs
>>
>> The ROAs have an expire date
>>
>> How do i rotate the cert to push out the expiration date?  Does ARIN do this 
>> for me?
>>
>> Thanks!

Re: ARIN hosted RPKI key rotation

[TJ Trout]

I believe it's manual, ten years and you need to update the roa.

On Fri, Nov 20, 2020, 6:55 AM Ca By  wrote:

> Hello folks,
>
> I use ARIN hosted RPKI to publish ROAs
>
> The ROAs have an expire date
>
> How do i rotate the cert to push out the expiration date?  Does ARIN do
> this for me?
>
> Thanks!
>

ARIN hosted RPKI key rotation

[Ca By]

Hello folks,

I use ARIN hosted RPKI to publish ROAs

The ROAs have an expire date

How do i rotate the cert to push out the expiration date?  Does ARIN do
this for me?

Thanks!

inspecting RPKI data: console.rpki-client.org

[Job Snijders]

Dear all,

I'd like to introduce another tool to inspect RPKI data... the
rpki-client console! Comes with an authentic 90s look & feel :-)

The Frontpage - http://console.rpki-client.org/
---
On the front page you can see stdout + stderr of the most recent
rpki-client run. The log shows which publication points were contacted
and prints any issues encountered with specific RPKI files.

Those of us publishing RPKI data should keep an eye out not to show up
in this type of log with warnings or errors. For example:

rpki-client: cc.rg.net/rpki/RGnet-cc/1opByAd8x8R2F-SzstgaYzVXK8Q.mft: mft 
expired on Oct 12 17:58:45 2020 GMT

However, the above line might be the result of some kind of experiment someone 
is conducting :-)

The RPKI distributed database currently is more than 120,000 (!)
certificate/roa/manifest files, and only a handful of files have some
kind of completeness or expiration date issue. Good job everyone! :-)

The ASN specific pages - http://console.rpki-client.org/AS2914.html
---
You can substitute the 'AS2914' portion in the URL for any ASN to see
which .roa files reference the given ASN. Another example, here one can
see all ROAs which authorize AS 8283 as origin: 
https://console.rpki-client.org/AS8283.html
If you encounter a HTTP 404 error, no ROAs reference the ASN. 

On the 'per ASN page' you can search click the .roa files on the left
side to inspect the ROA. Each object in the RPKI has a unique Subject
Key Identifier (SKI). An example of a SKI is this hexadecimal identifier
'06:96:B3:F7:CC:AD:55:45:A5:3A:64:32:31:2B:7F:E1:2B:7A:15:22' which
maps to a filename like 
'rpki.apnic.net/member_repository/A91A4C60/B526FF74D84111E9A4521413C4F9AE02/12F0D72E7BC111EA8503D815C4F9AE02.roa'

Yeah... compared to DNS names mapping to IPv6 addresses, in the RPKI
neither the path name nor the SKI are easy to remember :-)

The console can show that .roa file in human readable format, just
append .html: 
http://console.rpki-client.org/rpki.apnic.net/member_repository/A91A4C60/B526FF74D84111E9A4521413C4F9AE02/12F0D72E7BC111EA8503D815C4F9AE02.roa.html

Every object in the RPKI is subordinate to another object (all objects
are signed by a parent certificate, except the Trust Anchors). The
parent is identified by the Authority Key Identifier (AKI). So one
object's AKI is another object's SKI! If you click the AKI, the console
brings you to the parent object, from where you can continue to explore
other objects related to parent.

Certificates point to Manifests, and .mft files contain the 'directory
indexes' of the RPKI: 
http://console.rpki-client.org/rpki.apnic.net/member_repository/A91A4C60/B526FF74D84111E9A4521413C4F9AE02/nvnkN242ZTJ1x5Y1mNa0W3CvgJk.mft.html
>From the manifest overview you can jump to the parent, click the
referenced .roa, .cer or .crl files.

All directories on the webserver are 'open', except the root. This
allows you to explore this RPKI cache by browsing through the filesystem
directly, example: 
http://console.rpki-client.org/rpki.apnic.net/member_repository/

Final notes
---
The rpki-client console provides a view on *validated* RPKI data. First
rpki-client runs and prunes bad files, then all HTML is generated. The
console provides a view on the data as used in production Internet
routers. Please note: the console's rendering is delayed by a bit over
an hour compared to the real thing.

Another entry point, you can use your browser's 'find on page' function
to search for anything in all of it on this humongous page:
http://console.rpki-client.org/roas.html

The RPKI is very intricate collection of references, I hope this console
offers another useful perspective on the tree-like structures. Enjoy!

Kind regards,

Job