Re: Networks ignoring prepends?

[Patrick W. Gilmore]

> The Internet is lying to itself, and that’s not a situation that can persist 
> forever.

I am not sure I agree.

First, prepends are a suggestion. Perhaps a request. It has never (or at least 
not for the 3 decades I’ve been doing this) been a guarantee. In the situation 
below, perhaps the 5K mile backup path is through a provider who pays 
Centurylink (Lumen?). Standard practice is to localpref your customers up, 
which makes prepends irrelevant. Why would anyone expect different behavior?

As for hiding hops, that is not lying. What happens inside my network is my 
business. If I give the world some info, say with in-addrs on hops, that’s 
fine. If I do not, I am not “lying”. This is perfectly sustainable, nothing 
will break (IMHO). In fact, I would argue without tools like MPLS, the Internet 
would have broken a long time ago.

-- 
TTFN,
patrick

> On Jan 22, 2024, at 08:13, Mel Beckman  wrote:
> 
> Prepend contraction is becoming more common. You can’t really stop providers 
> from doing it, and it reduces BGP table size, which I’ve heard as a secondary 
> rationale. I’d love to see the statistics on that though.
> 
> BGP Communities seem to be the only alternative, and that limits your 
> engineering reach to mostly immediate peers.
> 
> Another problem is providers that hide multiple router hops inside MPLS, 
> which appears as a single ip hop in traceroutes, making it impossible to know 
> the truth path geographically. 
> 
> The Internet is lying to itself, and that’s not a situation that can persist 
> forever.
> 
> -mel via cell
> 
>> On Jan 22, 2024, at 4:52 AM, William Herrin  wrote:
>> 
>> Howdy,
>> 
>> Does anyone have suggestions for dealing with networks who ignore my
>> BGP route prepends?
>> 
>> I have a primary ingress with no prepends and then several distant
>> backups with multiple prepends of my own AS number. My intention, of
>> course, is that folks take the short path to me whenever it's
>> reachable.
>> 
>> A few years ago, Comcast decided it would prefer the 5000 mile,
>> five-prepend loop to the short 10 mile path. I was able to cure that
>> with a community telling my ISP along that path to not advertise my
>> route to Comcast. Today it's Centurylink. Same story; they'd rather
>> send the packets 5000 miles to the other coast and back than 10 miles
>> across town. I know they have the correct route because when I
>> withdraw the distant ones entirely, they see and use it. But this time
>> it's not just one path; they prefer any other path except the one I
>> want them to use. And Centurylink is not a peer of those ISPs, so
>> there doesn't appear to be any community I can use to tell them not to
>> use the route.
>> 
>> I hate to litter the table with a batch of more-specifics that only
>> originate from the short, preferred link but I'm at a loss as to what
>> else to do.
>> 
>> Advice would be most welcome.
>> 
>> Regards,
>> Bill Herrin
>> 
>> --
>> William Herrin
>> b...@herrin.us
>> https://bill.herrin.us/

Re: cogent spamming directly from ARIN records?

[Patrick W. Gilmore]

Has anyone replied?

If this is a peering request, not sure that is a bad use of the AS contact info.

If it is a sales pitch, then yeah, that’s a problem.

-- 
TTFN,
patrick

> On Oct 2, 2023, at 14:58, Tim Burke  wrote:
> 
> Hurricane has been doing the same thing lately... but their schtick is to say 
> that "we are seeing a significant amount of hops in your AS path and wanted 
> to know if you are open to resolve this issue".
> 
> complia...@arin.net is about all that can be done, other than public shaming! 
> 
> Other outfits have been spamming using the nanog attendees list, but I guess 
> that’s not as bad as the continued scraping of ARIN records, so I won't call 
> them out... yet, at least. 
> 
> -Original Message-
> From: NANOG  On Behalf Of Mel Beckman
> Sent: Monday, October 2, 2023 10:28 AM
> To: nanog list 
> Subject: cogent spamming directly from ARIN records?
> 
> This morning I received an email from someone at Cogent asking about an ASN I 
> administer. They didn’t give any details, but I assumed it might be related 
> to some kind of network transport issue. I replied cordially, asking them 
> what they needed. The person then replied with a blatant spam, advertising 
> Cogent IP services, in violation of the U.S. CAN-SPAM Act’s prohibition 
> against deceptive UCE.
> 
> I believe they got the contact information from ARIN, because the ARIN 
> technical POC is the only place where my name and the ASN are connected. I 
> believe this is a violation of Cogent’s contract with ARIN. Does anybody know 
> how I can effectively report this to ARIN? If we can’t even police 
> infrastructure providers for spamming, LIOAWKI.
> 
> -mel beckman

Re: Network visibility

[Patrick W. Gilmore]

> But I will capitalize Internet in all relevant uses.
> 
> This is an *engineering definition*, it matters that you name the right
> object, and I am one of the people who will, in fact, die on this hill.

You are not alone.


> The associated press can bite me.

While I respect and appreciate the AP (ap?) in general, in this particular 
instance, I am with you.

-- 
TTFN,
patrick


> On Oct 22, 2021, at 01:21, Jay R. Ashworth  wrote:
> - Original Message -
>> From: "Miles Fidelman" 
> 
>> Guys,
>> 
>> You guys were in grade school, some of us were there at the beginning
>> (well, in my case, 2 years after the beginning).  I can assure you that
>> folks made a big deal about what was and wasn't the Internet, and the
>> distinction between "an internet" and "the (capital I) Internet."
>> Opinions varied then, and opinions vary now.
>> 
>> But... by and large, as I understand the general zeitgeist:
>> 
>> - you're either on the Internet, or you're not - the key question is
>> whether you can send & receive IP packets from the public address space
>> (i.e., the classified segments are internets, but not part of THE
>> Internet).  There are also disagreements on where the Internet ends - at
>> the demarc, or at the IP stack in your machine (I argue the latter, but
>> that's debatable)
> 
> Seth Breidbart has the last word on this point, I think:
> 
> The Internet is "the largest equivalence class in the reflexive, transitive, 
> symmetric closure of the relationship 'can be reached by an IP packet from'."
> 
> The associated press has, in the last year or two, disparaged the 
> capitalization
> of the word Internet, proving they do not understand there's a difference.
> 
> If they won't capitalize "my" name, I won't capitalize theirs.
> 
> But I will capitalize Internet in all relevant uses.
> 
> This is an *engineering definition*, it matters that you name the right
> object, and I am one of the people who will, in fact, die on this hill.
> 
> The associated press can bite me.
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Internet history

[Patrick W. Gilmore]

On Oct 21, 2021, at 2:37 PM, Michael Thomas  wrote:
> 
> [changed to a more appropriate subject]
> 
> On 10/20/21 3:52 PM, Grant Taylor via NANOG wrote:
>> On 10/20/21 3:26 PM, Michael Thomas wrote:
>>> Just as an interesting aside if you're interested in the history of 
>>> networking, When Wizards Stayed Up Late is quite elucidating.
>> 
>> +10 to Where Wizards Stay Up Late.
>> 
>> I recently re-acquired (multiple copies of) it.  (Multiple because I wanted 
>> the same edition that I couldn't locate after multiple moves.)
>> 
>> 
> One of the things about the book was that it finally confirmed for me what I 
> had heard but thought might be apocryphal which was that one of my co-workers 
> at Cisco (Charlie Klein) was the first one to receive a packet on ARPAnet. I 
> guess it sent an "l" and then immediately crashed. They fixed the problem and 
> the next time they got "login:". It also casts shade on another early well 
> known person which gives me some amount of schadenfreude.

It was “LO”, and Mr. Kline sent the packets, but you got it essentially right.

Source: https://uclaconnectionlab.org/internet-museum/

The last picture confirms Mr. Kline sent the LO and crashed the WHOLE INTERENT 
(FSVO “Internet”) just a couple seconds after it started. I wonder if he will 
ever live it down. :-) Apparently at the time it was not that big a deal. He 
did the test at 10:30 PM. He did not call and wake anyone up, everyone had to 
read about it in the notes the next day.

My understanding is that really is IMP No. 1. Someone found it in the “to be 
scrapped” pile & rescued it, then they closed off room 3420 & made it a 
micro-museum. I believe the teletype is not the original, but is a real ASR-33. 
The Sigma 7 is a prop, I believe.

Anyone can visit it for free (other than parking, which is expensive near 
UCLA!). If you are near UClA, you should stop by. To be honest, it is both 
overwhelming and underwhelming. Overwhelming because of what it was and 
represents. Underwhelming because it is a tiny classroom with a half-glass 
locked door and a plaque in the basement of the mathematics department at a 
public university that looks like it was built in the 40s. I went to UCLA for 
mathematics, and spent quite a bit of time in that hallway without even 
realizing what that room was. (It was not a museum at the time.)

-- 
TTFN,
patrick

Re: abha

[Patrick W. Gilmore]

On Oct 20, 2021, at 1:45 PM, Brett Watson  wrote:
> On Oct 20, 2021, at 10:41, Randy Bush  wrote:
>> 
>> abha died 20 years ago today
> 
> Still miss her, she was a ray of sunshine.

I can still hear her laugh, see her smile. Which makes me happy and sad at the 
same time.

We all owe her. NANOG would not be what it is today without her efforts.

-- 
TTFN,
patrick

Re: Facebook post-mortems...

[Patrick W. Gilmore]

Update about the October 4th outage

https://engineering.fb.com/2021/10/04/networking-traffic/outage/

-- 
TTFN,
patrick

> On Oct 4, 2021, at 9:25 PM, Mel Beckman  wrote:
> 
> The CF post mortem looks sensible, and a good summary of what we all saw from 
> the outside with BGP routes being withdrawn. 
> 
> Given the fragility of BGP, this could still end up being a malicious attack. 
> 
> -mel via cell
> 
>> On Oct 4, 2021, at 6:19 PM, Jay Hennigan  wrote:
>> 
>> On 10/4/21 17:58, jcur...@istaff.org wrote:
>>> Fairly abstract - Facebook Engineering - 
>>> https://m.facebook.com/nt/screen/?params=%7B%22note_id%22%3A10158791436142200%7D=%2Fnotes%2Fnote%2F&_rdr
>>>  
>>> 
>> 
>> I believe that the above link refers to a previous outage. The duration of 
>> the outage doesn't match today's, the technical explanation doesn't align 
>> very well, and many of the comments reference earlier dates.
>> 
>>> Also, Cloudflare’s take on the outage - 
>>> https://blog.cloudflare.com/october-2021-facebook-outage/ 
>>> 
>> 
>> This appears to indeed reference today's event.
>> 
>> -- 
>> Jay Hennigan - j...@west.net
>> Network Engineering - CCIE #7880
>> 503 897-8550 - WB6RDV

Re: facebook outage

[Patrick W. Gilmore]

On Oct 4, 2021, at 5:30 PM, Bill Woodcock  wrote:
> On Oct 4, 2021, at 11:21 PM, Bill Woodcock  wrote:
>> On Oct 4, 2021, at 11:10 PM, Bill Woodcock  wrote:
>>> 
>>> They’re starting to pick themselves back up off the floor in the last two 
>>> or three minutes.  A few answers getting out.  I imagine it’ll take a while 
>>> before things stabilize, though.
>> 
>> nd we’re back:
>> 
>> WoodyNet-2:.ssh woody$ dig www.facebook.com @9.9.9.9
> 
> So that was, what…  15:50 UTC to 21:05 UTC, more or less…  five hours and 
> fifteen minutes.
> 
> That’s a lot of hair burnt all the way to the scalp, and some third-degree 
> burns beyond that.
> 
> Maybe they’ll get one or two independent secondary authoritatives, so this 
> doesn’t happen again.  :-)

If by “independent” you mean “3rd party” (e.g. DynDNS), not sure what an 
external secondary would have done here. While their BGP was misbehaving, the 
app would not work even if you had a static DNS entry.

And while using external / 3rd party secondaries is likely a good idea for many 
companies, almost none of the largest do this. These companies view it as a 
control issue. Giving someone outside your own employees the ability to change 
a DNS name is, frankly, giving another company the ability to take you down.

Taking a sample of FB, cisco, Amazon, NF, Dell, Akamai, Google, MS, CF, only 2 
use 3rd party resolvers.
* NF uses only awsdns, so same problem, just moved to another company they do 
not control.
* Amazon uses Ultra & Dyn. (Anyone else amused amazon.com has no authorities on 
Route 53? At least not from my vantage point.)

That said, plenty of what people may call “big” companies do use 3rd parties, 
e.g. IBM, PayPal, Juniper.

You want to use a 3rd party DNS, go for it. There are lots of reasons to do it. 
But it is not a panacea, and there are reasons not to.

-- 
TTFN,
patrick

Re: FYI: NANOG and ICANN

[Patrick W. Gilmore]

NANOG’s version: 
https://www.nanog.org/stories/nanog-signs-a-memorandum-of-understanding-with-internet-society-icann/

-- 
TTFN,
patrick


> On Oct 4, 2021, at 4:42 AM, Hank Nussbacher  wrote:
> 
> https://www.icann.org/en/announcements/details/icann-signs-a-memorandum-of-understanding-with-nanog-27-9-2021-en
> 
> Regards,
> Hank

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Patrick W. Gilmore]

> Of course! Including headers to show authenticity. I was very amused by the 
> explanation of the "chicken and egg" problem. Who's creating that? The 
> networks
> who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't 
> recognize ASNs that are not peering with anyone because nobody wants to peer 
> with them because they are not registered in peeringdb because nobody wants to
> peer with them? You get the idea.

First, most networks do not require a PDB record to peer. (Silly of them, I 
know, but still true.)

Second, you do not need to have a PDB record to get a link to an IXP. Even 
membership in a free IXP is sufficient for an account in PDB, as Grizz points 
out below.

Third, if you have an agreement, even just an email, saying a network will peer 
with you once you have a record, that may well suffice. Have you asked any 
network to peer? Private peering (because you are not on an IXP) is usually 
reserved for networks with more than a modicum of traffic. If your network is 
large enough to qualify for private peering, I have trouble believing you 
cannot get another network to agree to peer so you can get a record.

I guess you are right, the _Peering_DB does not register “certain” networks. 
Those networks would be ones that do not peer. Which seems pretty obvious to me 
- it is literally in the name.

-- 
TTFN,
patrick

> On Aug 18, 2021, at 5:50 PM, Sabri Berisha  wrote:
> 
> ----- On Aug 18, 2021, at 2:21 PM, Patrick W. Gilmore patr...@ianai.net 
> <mailto:patr...@ianai.net> wrote:
> 
> Hi,
> 
>> On Aug 18, 2021, at 5:00 PM, Matthew Walster  wrote:
>>> On Wed, 18 Aug 2021, 21:37 Sabri Berisha,  wrote:
>>> - On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote:
>>> 
>>> Hi,
>>> 
>>>>> We always use PeeringDB data and refuse to peer with networks not in 
>>>>> PeeingDB
>>>> 
>>>> You are aware that PeerinDB refuses to register certain networks, right? 
>>>> It is
>>>> most certainly not a single source of truth.
>>>> 
>>> Would you care to expand on this?
>> 
>> I am extremely interested in hearing about this as well.
>> 
>> Specific examples would be useful.
> 
> Of course! Including headers to show authenticity. I was very amused by the 
> explanation of the "chicken and egg" problem. Who's creating that? The 
> networks
> who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't 
> recognize ASNs that are not peering with anyone because nobody wants to peer 
> with them because they are not registered in peeringdb because nobody wants to
> peer with them? You get the idea.
> 
> Thanks,
> 
> Sabri
> AS31064
> 
> 
> Return-Path: gr...@peeringdb.com <mailto:gr...@peeringdb.com>
> Received: from mail.cluecentral.net <http://mail.cluecentral.net/> (LHLO 
> mail.cluecentral.net <http://mail.cluecentral.net/>)
> (195.16.84.32) by mail.cluecentral.net <http://mail.cluecentral.net/> with 
> LMTP; Fri, 9 Oct 2015 01:47:22
> -0700 (PDT)
> Received: from localhost (localhost [127.0.0.1])
>   by mail.cluecentral.net <http://mail.cluecentral.net/> (Postfix) with 
> ESMTP id 4CED64001EF
>   for mailto:sa...@cluecentral.net>>; Fri,  9 Oct 
> 2015 01:47:22 -0700 (PDT)
> Received: from mail.cluecentral.net <http://mail.cluecentral.net/> 
> ([127.0.0.1])
>   by localhost (mail.cluecentral.net <http://mail.cluecentral.net/> 
> [127.0.0.1]) (amavisd-new, port 10024)
>   with ESMTP id 3TLvVaNdjHGA for  <mailto:sa...@cluecentral.net>>;
>   Fri,  9 Oct 2015 01:47:21 -0700 (PDT)
> Received: from ubersmith.peeringdb.com <http://ubersmith.peeringdb.com/> 
> (ubersmith.peeringdb.com <http://ubersmith.peeringdb.com/> [107.6.74.106])
>   by mail.cluecentral.net <http://mail.cluecentral.net/> (Postfix) with 
> ESMTP id C5B164001A9
>   for mailto:sa...@cluecentral.net>>; Fri,  9 Oct 
> 2015 01:47:01 -0700 (PDT)
> Received: by ubersmith.peeringdb.com <http://ubersmith.peeringdb.com/> 
> (Postfix, from userid 48)
>   id D8AF377C1A; Fri,  9 Oct 2015 04:46:29 -0400 (EDT)
> Date: Fri, 9 Oct 2015 04:46:29 -0400
> To: Sabri Berisha mailto:sa...@cluecentral.net>>
> From: supp...@peeringdb.com <mailto:supp...@peeringdb.com>
> Reply-To: supp...@peeringdb.com <mailto:supp...@peeringdb.com>
> Subject: Re: [#9192] [PeeringDB] User (sabri) Requesting Access (New Company 
> - Cluecentral Inc)
> Message-ID: <1bac170d74e5d3702d3a28b237c87...@ubersmith.peeringdb.com 
> <mailto:1bac170d74e5d3702d3a28b237c87...@ubersmith.peeringdb.com>>
> 
> Dear

PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Patrick W. Gilmore]

On Aug 18, 2021, at 5:00 PM, Matthew Walster  wrote:
> On Wed, 18 Aug 2021, 21:37 Sabri Berisha,  wrote:
> - On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote:
> 
> Hi,
> 
>> > We always use PeeringDB data and refuse to peer with networks not in 
>> > PeeingDB
>> 
>> You are aware that PeerinDB refuses to register certain networks, right? It 
>> is most certainly not a single source of truth.
>> 
> Would you care to expand on this?

I am extremely interested in hearing about this as well.

Specific examples would be useful.

-- 
TTFN,
patrick

Re: FCC fines for unauthorized carrier changes and consumer billing

[Patrick W. Gilmore]

On Apr 23, 2021, at 12:47 PM, Sean Donelan  wrote:
> On Fri, 23 Apr 2021, Dan Hollis wrote:
>> On Fri, 23 Apr 2021, Eric Kuhnke wrote:
>>> Did the FCC ever collect its $50 million from "Sandwich Isles
>>> Telecommunications" for blatant fraud?  At this scale I wonder how or why
>>> certain people are not in federal prison.
>> 
>> FCC is not law enforcement. The FTC can send people to prison. The FCC can 
>> only send press releases.
> 
> Neither FCC nor FTC can send people to prison. Only the Department of Justice 
> can criminally prosecute people (or corporations, i.e. WORLDCOM, ENRON, etc) 
> in the U.S. Federal system.  States and other countries vary.
> 
> FCC can deny future licenses and make things difficult for long-term 
> carriers. Most scammers declare bankruptcy or just never pay.
> 
> 
> https://www.politico.com/story/2015/11/fcc-fine-enforcement-scrutiny-216121
> FCC proposes millions in fines, collects $0
> November 23, 2015

It just got harder for the FTC to fine people: 
https://www.morningbrew.com/daily/stories/2021/04/22/supreme-court-limits-ftcs-ability-recoup-illgotten-gains

-- 
TTFN,
patrick

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Patrick W. Gilmore]

On Apr 22, 2021, at 7:58 PM, nanoguser100 via NANOG  wrote:
> 
> I see a lot of replies about the legality.  As mentioned I have legitimate 
> reasons for doing this.  I plan on serving customers in country.

Your “legitimate” reason is to avoid someone else’s restrictions on the content 
they own. You are intentionally falsifying data to keep the owner of something 
from controlling that thing the way they want to control it.

You and I have different definitions of “legitimate”.


> My questions really are:
> 
> * Is most geo data simply derived from self reporting?

No comment.


> * Do these vendors have verification mechanisms?

Yes.


> * Going to the Estonia\Germany example would a traceroute "terminating" in 
> Germany before being handed off to my network 1ms away be a tell-tale sign 
> the servers are in Germany.

Yes.

BTW: Adding artificial latency to mimic a trip back to Estonia is a bad idea, 
IMHO.


> * Is the concept of creating "pseudoPOPs" where it's not cost effective to 
> start a POP in the region a 'common practice'?

No, but it is not unheard-of.


> * Do I run the risk of being blacklisted for this practice?

Risk? Blacklisted where?

The risk of another ISP filtering your traffic for this is very low, almost 
certainly to the right of the decimal, but not mathematically zero to infinite 
decimal places. As I mentioned before, the risk of geo-loc providers ignoring 
any of your manual updates in the future is higher, but still low. Most of 
those things are automated.

-- 
TTFN,
patrick



> 
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, April 21, 2021 9:00 AM, nanoguser100 via NANOG 
>  wrote:
> 
>> I wanted to get the communities' opinion on this.
>> 
>> I am an admin for a quasi-ISP providing cloud hosted desktop solutions for 
>> end users.  We have POPs all around the world, own our own ASN, and 
>> advertise /24s or /23s at each of our POPs fro our large aggregate.  As an 
>> ISP we submit our blocks to popular geolocation vendors such as Google, 
>> Maxmind, IP2, etc and put the proper geolocations in our RIR records (RADB, 
>> ARIN, etc).
>> 
>> Increasingly I have run into 'niche needs' where a client has a few users in 
>> a country we don't have a POP, say Estonia.  This is 'mainly' for 
>> localization but also in some cases for compliance (some sites REQUIRE an 
>> Estonian IP).  With that being said is it common practice to 'fake' 
>> Geolocations?  In this case the user legitimately lives in Estonia, they 
>> just happen to be using our cloud service in Germany.  I do want to operate 
>> in compliance with all the ToS as I don't want to risk our ranges getting 
>> blacklisted or the geo vendors stop accepting our data.  I would think it's 
>> pretty easy to tell given a traceroute would end in Germany even though 
>> you're claiming the IP is in Estonia.  How common of a practice is it to 
>> 'fake' the geos?  Is it an acceptable practice? 
>> 
>> 
>> Sent with ProtonMail Secure Email.
>> 
> 

Re: Submitting Fake Geolocation for blocks to Data Brokers and RIRs

[Patrick W. Gilmore]

On Apr 22, 2021, at 10:23 AM, Matthew Petach  wrote:
> On Thu, Apr 22, 2021 at 7:12 AM nanoguser100 via NANOG  
> wrote:
>> William,
>> 
>> The plan is to carve out a /24 for "Estonia" and have special servers on it. 
>>  This would be the same /24 I'd have to use if I were to put a legitimate 
>> POP there.  This also means I don't conflict with the real Germany.
>> 
>> I am just worried about violating the 'rules' of these providers and getting 
>> myself blacklisted from submitting corrections.  Afterall the traceroute 
>> will still show us hitting a router in Germany before it hits my network.  
>> Traceroutes aren't the end all be all but it's a tell-tale sign.
>> 
>> I guess this is all ISP-reported info so it's not "illegal" or a violation 
>> in any way.
>> 
>> -Nanoguser100

Love the fact you try to anonymize the question - after giving details like 
“server is in German, we want it to appear in Estonia”.

Anyway



> I think it's safe to say that before anyone could be 
> held accountable for geolocation data, there would 
> have to *first* be a requirement that the data be able 
> to be reliably updated to be *correct*.

Matt: I find it amusing you think rationality and logic have anything to do 
with government activity. You are not usually this naïve.


> As we have not yet achieved a way of ensuring that 
> legitimate holders of IP resources can reliably update 
> the geolocation data, I think you can rest assured, 
> nobody will be holding you accountable for whatever 
> the geolocation data might show for a particular block 
> of addresses.

I am not at all certain of this. At the very least, the maintainer of the 
information may hold it against you if they find out you have intentionally 
falsified the data. Remember, the people offering IP address <> Geo-location 
databases for money are not beholden to you. They are beholden to the people 
paying them money. If $CONTENT_OWNER wants to ensure only devices in Estonia 
get certain content, and you go out of your way to allow devices in German get 
the content, this could present a problem.

Will they sue you? I cannot see that happening. Will they ignore any future 
updates you give them? Would not surprise me.

BTW: I know VPN providers advertise this precise ability. However, at least the 
VPN end point is where they say it is.


> Now, if, as an industry, we had a consistent, reliable 
> way in which geolocation records could be updated 
> with a means to audit and ensure the updates are 
> being made only by the legitimate holders of the 
> number resources...*then* you might have reason 
> to be concerned.

Wait, I thought we did. At least I see it in every movie….


> But as of now, as evidenced by the number of 
> "how do I get my geolocation data updated" 
> emails sent to NANOG, which result in a flurry 
> of "meetoo" followups, no reasonable court 
> would ever give any legal credence to the 
> current data in the various geolocation 
> databases.

I find a difference between “we tried to keep the data straight, but there are 
mistakes” and “this data was intentionally misrepresented”. My guess is the law 
might as well.

As stated above, I seriously doubt anyone will someone sue you over it. Will 
you go to jail? Yeah, again, I cannot see that happening. Doesn’t mean you 
should do it.


> You can sleep soundly at night, whichever 
> road you may choose to take.

What is this “sleep” you mention?

-- 
TTFN,
patrick

Re: Zayo or HE for IP transit

[Patrick W. Gilmore]

Hurricane has probably the most peering of any large network on the  planet. 
They also carry more v6 traffic than anyone. But they have a famous problem 
with v6 - you cannot get to Cogent (174) from HE. Since you have Cogent, that 
should not be a problem. Private, smart people, customer service is excellent, 
generally good network. One minor thing to keep in mind: They do not have as 
many weird “features” as some of the other big networks. If you are looking for 
something very specific (as opposed to vanilla transit), you should check to 
see if they support it. Not saying they won’t, just saying I would check. 
Which, frankly, is good advice for any network.

I have not used Zayo in many years, so cannot comment on them.

-- 
TTFN,
patrick

> On Apr 19, 2021, at 5:30 PM, James Lumby  wrote:
> 
> What is the current experience with Zayo or HE?  I’m looking at possibly 
> adding one of them into a mix of cogent and a mix from my datacenter.  Would 
> be using BGP full routes.  Any experiences would be appreciated.
>  
> Sincerely, 
> James

Re: OOB management options @ 60 Hudson & 1 Summer

[Patrick W. Gilmore]

On Apr 16, 2021, at 1:49 PM, Warren Kumari  wrote:
> On Fri, Apr 16, 2021 at 1:08 PM Bryan Fields  wrote:
>> On 4/16/21 1:33 AM, Saku Ytti wrote:
> > https://www.markleygroup.com/cloud/network/out-of-band
> 
> Wow, this is an impressive offering.  I wish more providers would do this.
> 
> +manylots. It's always surprising to me how often companies (in all 
> industries) can be broken up into those that understand the value of goodwill 
> and those that instead nickel-and-dime.
> My local Potbelly (sandwich ship) every now and then will just say "No 
> charge, this one's on us". This only happens around once every 30-40 times I 
> go in, but they loyalty that it has created means that I go there **way** 
> more often than I otherwise would. It also means that in the few times that 
> something goes wrong/I have a bad experience, I don't really care.
> 
> The additional profit that they've made from having me as a loyal customer 
> more than covers the cost of 1 free sammich every N. 
> 
> In many ways Markley seems similar - they feel like they understand that some 
> things (like OOB) are annoying to deal with, and that the loyalty / goodwill 
> provided by being "nice" more than repays the cost of the service.

As the person who created that product for Markley, I can tell you that is 
precisely what we were thinking.

It cost us nearly nothing, made customers stickier, generated good will, and 
created a chance to talk to them about cloud offerings or similar. The only 
“catch” is you need a fiber xconn. The thinking was it was barely more than a 
copper xconn for POTS yet you get gigabit instead of dialup, or you would have 
used fiber to another ISP anyway.

Every serious colo has enough bandwidth that 2 Mbps won’t be noticed, competent 
network engineers (one hopes), and free switch ports (or can get them cheap). 
Why don’t they do this? Perhaps someone in finance feels it can be “monetized”. 
I feel the monetization lowers adoption and kills the other benefits Warren 
mentions above - which are worth a hell of a lot more than the paltry sum they 
would get from billing a few customers.

-- 
TTFN,
patrick

PS: The guest SSID at Markley has no captive portal. It was a problem for 
customers who wanted to have their equipment get on the wifi to download 
images, etc, so we took it off.

Re: Texas ERCOT power shortages (again) April 13

[Patrick W. Gilmore]

The issue was not only perfectly foreseeable, ERCOT has a ten year old document 
explaining PRECISELY how to avoid such an occurrence happening.

Did you miss the second paragraph below?

-- 
TTFN,
patrick

> On Apr 14, 2021, at 11:35 AM, Brian Johnson  wrote:
> 
> Not what I was saying. The demand for virtue-signaling green energy is not an 
> effective strategy to actually having power available.
> 
> I appreciate the nuances, but the need to imply that a profit motive was the 
> issue is not proven. This issue was NOT foreseeable except with the perfect 
> reverse 20/20 vision. It’s like saying that I shouldn’t have built the house 
> where the tornado hit.
> 
>> On Apr 14, 2021, at 10:12 AM, Patrick W. Gilmore > <mailto:patr...@ianai.net>> wrote:
>> 
>> Brian:
>> 
>> The idea that because ERCOT is a non-profit somehow means they would never 
>> do anything to save money, or management is not granted bonuses or salary 
>> increases based on savings, or have no financial incentive is ridiculous. 
>> E.g. Salaries for the top ERCOT executives increased 50% from 2012 to 2019. 
>> “Just pointing out facts.” 
>> 
>> Also, green vs. traditional has little to do with why ERCOT had problems. It 
>> is undisputed that ERCOT failed in 2011, was handed a report by the feds 
>> showing why they failed and how to fix it, yet ERCOT did not require 
>> suppliers to enact those fixes. Those actions had a direct, operational 
>> effect on the Internet. And as such, seem perfectly on-topic for NANOG.
>> 
>> Why that happened may still be on topic. For instance, you state correctly 
>> that ERCOT is a non-profit (although you and I disagree on precisely how 
>> that affects things). But the suppliers are not. Are we 100% certain the 
>> CEO’s salary jumping far far far far far faster than inflation had nothing 
>> to do with protecting the suppliers’ profits? I am not. However, that 
>> question is only tenuously operational.
>> 
>> Bringing it back to the topic on hand: How do we keep the grid up? Or plan 
>> for it not being up? Simply saying “green power is unreliable” is not an 
>> answer when many RFPs at least ask what percentage of your power is green, 
>> or flat out require at least some of your production be green. Making a 
>> blanket statement that “XXX is a non-profit” does not absolve them from poor 
>> business practices, which at least saves the non-profit money and frequently 
>> results in profits outside that entity. Etc.
>> 
>> -- 
>> TTFN,
>> patrick
>> 
>> 
>>> On Apr 14, 2021, at 10:00, Brian Johnson >> <mailto:brian.john...@netgeek.us>> wrote:
>>> 
>>> There is no profit motive for a non-profit company. It’s completely 
>>> relevant to your response.
>>> 
>>> For profit companies have similar issues with power generation and 
>>> maintenance as the way power is generated requires maintenance. No power 
>>> system is generating at 100% of capability at any single point. Your 
>>> assumptions of neglect, poor maintenance and failing to learn are 
>>> subterfuge. Traditional methods are more reliable (so far) than the newer 
>>> “green” methods.
>>> 
>>> Just pointing out facts.
>>> 
>>>> On Apr 14, 2021, at 8:26 AM, Tom Beecher >>> <mailto:beec...@beecher.cc>> wrote:
>>>> 
>>>> Brian-
>>>> 
>>>> I am aware. That's also not relevant at all to the point. 
>>>> 
>>>> On Wed, Apr 14, 2021 at 9:22 AM Brian Johnson >>> <mailto:brian.john...@netgeek.us>> wrote:
>>>> Tom,
>>>> 
>>>> You do realize that ERCOT is a non-profit organization….
>>>> 
>>>>> On Apr 14, 2021, at 8:04 AM, Tom Beecher >>>> <mailto:beec...@beecher.cc>> wrote:
>>>>> 
>>>>> > Funny how this obsession with a green grid has made the grid
>>>>> > unreliable, resulting in sales of gas-burning generators and
>>>>> > perishable fuel.  Dare I say it's not been worth it?
>>>>> 
>>>>> Yes, desire for renewable power sources is totally the reason that power 
>>>>> generators neglect proper preventative maintenance and adoption of 
>>>>> lessons learned during past problem periods. It absolutely has nothing to 
>>>>> do with profit being the most important thing ever. Right? 
>>>>> 
>>>>> On Wed, Apr 14, 2021 at 8:48 AM Mark Tinka >>>> <mailto:mark@tinka.a

Re: Texas ERCOT power shortages (again) April 13

[Patrick W. Gilmore]

Brian:

The idea that because ERCOT is a non-profit somehow means they would never do 
anything to save money, or management is not granted bonuses or salary 
increases based on savings, or have no financial incentive is ridiculous. E.g. 
Salaries for the top ERCOT executives increased 50% from 2012 to 2019. “Just 
pointing out facts.” 

Also, green vs. traditional has little to do with why ERCOT had problems. It is 
undisputed that ERCOT failed in 2011, was handed a report by the feds showing 
why they failed and how to fix it, yet ERCOT did not require suppliers to enact 
those fixes. Those actions had a direct, operational effect on the Internet. 
And as such, seem perfectly on-topic for NANOG.

Why that happened may still be on topic. For instance, you state correctly that 
ERCOT is a non-profit (although you and I disagree on precisely how that 
affects things). But the suppliers are not. Are we 100% certain the CEO’s 
salary jumping far far far far far faster than inflation had nothing to do with 
protecting the suppliers’ profits? I am not. However, that question is only 
tenuously operational.

Bringing it back to the topic on hand: How do we keep the grid up? Or plan for 
it not being up? Simply saying “green power is unreliable” is not an answer 
when many RFPs at least ask what percentage of your power is green, or flat out 
require at least some of your production be green. Making a blanket statement 
that “XXX is a non-profit” does not absolve them from poor business practices, 
which at least saves the non-profit money and frequently results in profits 
outside that entity. Etc.

-- 
TTFN,
patrick


> On Apr 14, 2021, at 10:00, Brian Johnson  wrote:
> 
> There is no profit motive for a non-profit company. It’s completely relevant 
> to your response.
> 
> For profit companies have similar issues with power generation and 
> maintenance as the way power is generated requires maintenance. No power 
> system is generating at 100% of capability at any single point. Your 
> assumptions of neglect, poor maintenance and failing to learn are subterfuge. 
> Traditional methods are more reliable (so far) than the newer “green” methods.
> 
> Just pointing out facts.
> 
>> On Apr 14, 2021, at 8:26 AM, Tom Beecher  wrote:
>> 
>> Brian-
>> 
>> I am aware. That's also not relevant at all to the point. 
>> 
>>> On Wed, Apr 14, 2021 at 9:22 AM Brian Johnson  
>>> wrote:
>>> Tom,
>>> 
>>> You do realize that ERCOT is a non-profit organization….
>>> 
 On Apr 14, 2021, at 8:04 AM, Tom Beecher  wrote:
 
 > Funny how this obsession with a green grid has made the grid
 > unreliable, resulting in sales of gas-burning generators and
 > perishable fuel.  Dare I say it's not been worth it?
 
 Yes, desire for renewable power sources is totally the reason that power 
 generators neglect proper preventative maintenance and adoption of lessons 
 learned during past problem periods. It absolutely has nothing to do with 
 profit being the most important thing ever. Right? 
 
> On Wed, Apr 14, 2021 at 8:48 AM Mark Tinka  wrote:
> 
> 
> On 4/14/21 13:35, Billy Croan wrote:
> 
> > Sounds like we all need to start keeping a few days reserve of energy 
> > on hand at home now because the utilities can't be trusted to keep 
> > their system online in 2021.
> 
> It just makes sense to plan along those lines, really. Despite popular 
> belief, power companies are preferring energy conservation from their 
> customers more than they do sales, because they just can't keep throwing 
> up new coal-fired or nuclear power stations a la the days of old (anyone 
> remember the 1973 and 1979 oil crises?)
> 
> Most people would assume that power companies want to sell more 
> electricity so they can make more money, but they dread the days when 
> the network is brought to its knees, even if the revenue will climb. So 
> between asking customers to save more on energy + being able to rely 
> less on fossil fuels for generation, one needs to consider their 
> personal energy security over the long term, fully or partially 
> independent of the traditional grid.
> 
> 
> > Funny how this obsession with a green grid has made the grid 
> > unreliable, resulting in sales of gas-burning generators and 
> > perishable fuel.  Dare I say it's not been worth it?
> 
> I wouldn't say that the obsession is without merit. It's just that 
> regular folk are only seeking the solution from one perspective - that 
> of the power generators. If folk (and that includes the gubbermints) met 
> the power companies half way, renewables would make a lot more sense, 
> more quickly. But as I said before, when we flick the switch, it must 
> turn on. End of. And then we revert to demanding power companies to 
> embrace the additional revenue, or fulfill their mandate to deliver a 

Re: wow, lots of akamai

[Patrick W. Gilmore]

adding more capacity, it's a complex technical challenge 
> that CDN's ought to give some more thought, and game publishers should start 
> considering too.
> 
> -Matt
> 
> On Thu, Apr 1, 2021 at 3:30 PM Patrick W. Gilmore  <mailto:patr...@ianai.net>> wrote:
> I am sorry, maybe I misunderstand.
> 
> Matt: Are you arguing the CDNs are at fault because the game companies tell 
> everyone to download simultaneously, and the ISPs sold the users connectivity 
> to do that download?
> 
> If so, are you really arguing “I sold my users XXX Mbps, but if they try to 
> use it, I want *YOU* to tell them no”? Because that is what it sounds like to 
> me.
> 
> Imagine a gym sold 10,000 memberships with 10 machines because they figured 
> everyone would sit on their ass. They would be right most of the time - and 
> rake in that sweet, sweet monthly cash for zero effort after the initial 
> sale. But if Oprah or Cher or Biden or some other person famous enough to go 
> by one name tweets “get your ass to the gym!!", does the gym really think 
> getting mad at Oprah is the solution? Or do they expect Oprah to pay for the 
> extra machines they have to buy now?
> 
> Selling a service you know will not work if everyone uses it simultaneously 
> can be profitable, but there is risk. Do not blame third parties when you 
> lose that bet.
> 
> -- 
> TTFN,
> patrick
> 
>> On Apr 1, 2021, at 5:04 PM, Tom Beecher > <mailto:beec...@beecher.cc>> wrote:
>> 
>> No disrespect taken, or intended back in your direction, but again, I 
>> disagree. 
>> 
>> If thousands of users are downloading 50G files at the same time, it really 
>> doesn't matter if they are pulling from a CDN or the origin directly. The 
>> volume of traffic still has to be handled. Yes, it's a burden on the ISP, 
>> but it's a burden created by the usage created by their subscribers. 
>> 
>> 
>> On Thu, Apr 1, 2021 at 4:57 PM Matt Erculiani > <mailto:merculi...@gmail.com>> wrote:
>> Tom,
>> 
>> All due respect, but there is a massive difference between one user 
>> downloading 50G and thousands of users each downloading 50G when they all go 
>> to play their videogame of choice at around the same time.
>> 
>> -Matt
>> 
>> 
>> 
>> On Thu, Apr 1, 2021 at 2:46 PM Tom Beecher > <mailto:beec...@beecher.cc>> wrote:
>> A user sends a few megabytes of request and receives 50 gigs of reply. They 
>> aren't DDoSing the network, but they're amplifying a single 50 gig copy they 
>> receive from the mothership and turning it into likely tens of terabytes of 
>> traffic.
>> Yes, that's a CDN's job, but that volume of legitimate traffic and the very 
>> tiny window with which it is transmitted is likely to be a burden for even 
>> the largest residential ISPs.
>> 
>> I'm sitting at home, and I could send a 50k request for a 50G file right now 
>> from a source not fronted by a CDN. What do? My ISP is still has to deliver 
>> it to me. The fact that the 50G file does or does not come from a CDN is 
>> irrelevant. The CDN just happens to be a point source that a lot of users 
>> happen to connect to. 
>> 
>> CDNs want to have the best performance to users because that's what brings 
>> them business. A poorly performing CDN will lose customers to a better 
>> performing one. The trend for years has been instead of ISPs investing in 
>> infrastructure to effectively handle the traffic that their users request, 
>> they turf that to CDNs. In many cases, a CDN will put a cache box in or 
>> extend a circuit at a loss to them, because they know if the performance 
>> metrics get bad, business will be taken elsewhere, even if the CAUSE of the 
>> poor performance is actually at the edge of, or inside , the ISPs network. 
>> 
>> ISPs in the US can get away with this because their users are captive and 
>> rarely have an alternative choice of provider.  
>> 
>> 
>> On Thu, Apr 1, 2021 at 4:33 PM Matt Erculiani > <mailto:merculi...@gmail.com>> wrote:
>> Patrick,
>> 
>> > First, to be blunt, if you really think Akamai nodes are “sitting idle for 
>> > weeks” before CoD comes out with a new game,
>> > you are clearly confused.
>> 
>> "Idle" in the sense that when you look at a graph of traffic before and 
>> after a large push such as this makes the rest of the week's traffic look 
>> like a horizontal line at the bottom, admittedly poor word choice, yes, but 
>> far from "confused" as to what CDNs do under relatively normal 
>> circumstances. Ot

Re: wow, lots of akamai

[Patrick W. Gilmore]

Just so I am clear, you are saying “I would rather have it come over my 
undersea cables than from inside the datacenter”?

And you are assuming TCP transport.

-- 
TTFN,
patrick

> On Apr 1, 2021, at 6:23 PM, Tony Wicks  wrote:
> 
> This is not actually (as in yes it does matter) the case, if a file comes 
> from a CDN it is often a close and low latency source that will run up to 
> very high speeds. For example in our case we connect to local peering 
> exchanges (or PNI’s/local caches) at 100G or Nx10G with latency to the end 
> user in the 1-30ms range resulting in very large peaks of local backhaul 
> traffic. If a file is delivers from source or from remote CDN’s/exchanges 
> these are located in other countries with between 25ms (New Zealand to 
> Australia) and 130-200ms (New Zealand to LA/SJC or Singapore) latency, this 
> results in a much slower and normally barely noticeable traffic blip. Yes as 
> an ISP we need to carry the traffic in both cases but the first case can 
> result in a 20-30% local backhaul increase for a couple of hours and in the 
> second case its just BAU traffic for a day or two. Local CDN is obviously the 
> better option for cost and the consumer, but you certainly do notice the 
> traffic in local backhaul.
>  
> From: NANOG  > On Behalf Of Tom Beecher
> Sent: Friday, 2 April 2021 10:05 am
> To: Matt Erculiani mailto:merculi...@gmail.com>>
> Cc: North American Operators' Group mailto:nanog@nanog.org>>
> Subject: Re: wow, lots of akamai
>  
>  
> If thousands of users are downloading 50G files at the same time, it really 
> doesn't matter if they are pulling from a CDN or the origin directly. The 
> volume of traffic still has to be handled. Yes, it's a burden on the ISP, but 
> it's a burden created by the usage created by their subscribers. 

Re: wow, lots of akamai

[Patrick W. Gilmore]

I am sorry, maybe I misunderstand.

Matt: Are you arguing the CDNs are at fault because the game companies tell 
everyone to download simultaneously, and the ISPs sold the users connectivity 
to do that download?

If so, are you really arguing “I sold my users XXX Mbps, but if they try to use 
it, I want *YOU* to tell them no”? Because that is what it sounds like to me.

Imagine a gym sold 10,000 memberships with 10 machines because they figured 
everyone would sit on their ass. They would be right most of the time - and 
rake in that sweet, sweet monthly cash for zero effort after the initial sale. 
But if Oprah or Cher or Biden or some other person famous enough to go by one 
name tweets “get your ass to the gym!!", does the gym really think getting mad 
at Oprah is the solution? Or do they expect Oprah to pay for the extra machines 
they have to buy now?

Selling a service you know will not work if everyone uses it simultaneously can 
be profitable, but there is risk. Do not blame third parties when you lose that 
bet.

-- 
TTFN,
patrick

> On Apr 1, 2021, at 5:04 PM, Tom Beecher  wrote:
> 
> No disrespect taken, or intended back in your direction, but again, I 
> disagree. 
> 
> If thousands of users are downloading 50G files at the same time, it really 
> doesn't matter if they are pulling from a CDN or the origin directly. The 
> volume of traffic still has to be handled. Yes, it's a burden on the ISP, but 
> it's a burden created by the usage created by their subscribers. 
> 
> 
> On Thu, Apr 1, 2021 at 4:57 PM Matt Erculiani  <mailto:merculi...@gmail.com>> wrote:
> Tom,
> 
> All due respect, but there is a massive difference between one user 
> downloading 50G and thousands of users each downloading 50G when they all go 
> to play their videogame of choice at around the same time.
> 
> -Matt
> 
> 
> 
> On Thu, Apr 1, 2021 at 2:46 PM Tom Beecher  wrote:
> A user sends a few megabytes of request and receives 50 gigs of reply. They 
> aren't DDoSing the network, but they're amplifying a single 50 gig copy they 
> receive from the mothership and turning it into likely tens of terabytes of 
> traffic.
> Yes, that's a CDN's job, but that volume of legitimate traffic and the very 
> tiny window with which it is transmitted is likely to be a burden for even 
> the largest residential ISPs.
> 
> I'm sitting at home, and I could send a 50k request for a 50G file right now 
> from a source not fronted by a CDN. What do? My ISP is still has to deliver 
> it to me. The fact that the 50G file does or does not come from a CDN is 
> irrelevant. The CDN just happens to be a point source that a lot of users 
> happen to connect to. 
> 
> CDNs want to have the best performance to users because that's what brings 
> them business. A poorly performing CDN will lose customers to a better 
> performing one. The trend for years has been instead of ISPs investing in 
> infrastructure to effectively handle the traffic that their users request, 
> they turf that to CDNs. In many cases, a CDN will put a cache box in or 
> extend a circuit at a loss to them, because they know if the performance 
> metrics get bad, business will be taken elsewhere, even if the CAUSE of the 
> poor performance is actually at the edge of, or inside , the ISPs network. 
> 
> ISPs in the US can get away with this because their users are captive and 
> rarely have an alternative choice of provider.  
> 
> 
> On Thu, Apr 1, 2021 at 4:33 PM Matt Erculiani  <mailto:merculi...@gmail.com>> wrote:
> Patrick,
> 
> > First, to be blunt, if you really think Akamai nodes are “sitting idle for 
> > weeks” before CoD comes out with a new game,
> > you are clearly confused.
> 
> "Idle" in the sense that when you look at a graph of traffic before and after 
> a large push such as this makes the rest of the week's traffic look like a 
> horizontal line at the bottom, admittedly poor word choice, yes, but far from 
> "confused" as to what CDNs do under relatively normal circumstances. 
> Otherwise very valid points you've raised.
> 
> Tom,
> 
> > Akamai, and other CDNs, do not **generate** traffic ; they serve the 
> > requests generated by users.  
> 
> A user sends a few megabytes of request and receives 50 gigs of reply. They 
> aren't DDoSing the network, but they're amplifying a single 50 gig copy they 
> receive from the mothership and turning it into likely tens of terabytes of 
> traffic.
> Yes, that's a CDN's job, but that volume of legitimate traffic and the very 
> tiny window with which it is transmitted is likely to be a burden for even 
> the largest residential ISPs.
> 
> -Matt
> 
> On Thu, Apr 1, 2021 at 2:09 PM Patrick W. Gilmore  <mailto:patr...@i

Re: wow, lots of akamai

[Patrick W. Gilmore]

Matt:

I am going to disagree with your characterization of how Akamai - and many 
other CDNs - manage things. First, to be blunt, if you really think Akamai 
nodes are “sitting idle for weeks” before CoD comes out with a new game, you 
are clearly confused.

More importantly, I know for a fact Akamai has spent ungodly amounts of money & 
resources putting content precisely where the ISPs ask them to put it, deliver 
it over the pipes the ISPs ask them to deliver it, at precisely the capacity 
the ISPs tell them.

On the other hand, I agree with your characterization of residential broadband. 
It is ridiculous to expect a neighborhood with 1,000 homes each with 1 Gbps 
links to have a terabit of uplink capacity. But it also should have a lot more 
than 10 Gbps, IMHO. Unfortunately, most neighborhoods I have seen are closer to 
the latter than the former.

Finally, this could quickly devolve into finger pointing. You say the CDNs bear 
some responsibility? They may well respond that the large broadband providers 
ask for cash to interconnect - but still require the CDNs to do all the work. 
The CDNs did not create the content, or tell the users which content to pull. 
When I pay $NATIONAL_PROVIDER, I expect them to provide me with access to the 
Internet. Not just to the content that pays that provider.

Personally, I have zero problems with the ISPs saying “give me a cache to put 
here with this sized uplink” or “please deliver to these users over this xconn 
/ IX / whatever”. I have a huge problem with the ISPs blaming the ISPs for 
delivering what the ISP’s users request.

Of course, this could all be solved if there were more competition in broadband 
in the US (and many other countries). But that is a totally different 10,000 
post thread (that we have had many dozens of times).

-- 
TTFN,
patrick

> On Apr 1, 2021, at 3:53 PM, Matt Erculiani  wrote:
> 
> Niels,
> 
> I think to clarify Jean's point, when you buy a 300mbps circuit, you're 
> paying for 300mbps of internet access. 
> 
> That does not mean that a network should (and in this case small-medium ones 
> simply can't) build all of their capacity to service a large number of 
> customer circuits at line rate at the same time for an extended period, 
> ESPECIALLY to the exact same endpoint. It's just not economically reasonable 
> to expect that. Remember we're talking about residential service here, not 
> enterprise circuits.
> 
> Therefore, how do you prevent this spike of [insert large number here] 
> gigabits traversing the network at the same time from causing issues? Build 
> more network? That sounds easy, but there are plenty of legitimate reasons 
> why ISPs can't or don't want to do that, particularly for an event that only 
> occurs once per quarter or so.
> 
> Does Akamai bear some burden here to make these rollouts less troublesome for 
> the ISPs they traverse through the last mile(s)? IMO yes, yes they do. When 
> you're doing something new and unprecedented, as Akamai frequently brags 
> about on Twitter, like having rapid, bursty growth of traffic, you need to 
> consider that just because you can generate it, doesn't mean it can be 
> delivered.  They've gotta be more sophisticated than a bunch of servers with 
> SSD arrays, ramdisks, and 100 gig interfaces, so there's no excuse for them 
> here to just blindly fill every link they have after sitting idle for 
> weeks/months at a time and expect everything to come out alright and nobody 
> to complain about it.
> 
> On Thu, Apr 1, 2021 at 1:21 PM Niels Bakker  > wrote:
> * nanog@nanog.org  (Jean St-Laurent via NANOG) [Thu 
> 01 Apr 2021, 21:03 CEST]:
> >An artificial roll out penalty somehow? Probably not at the ISP 
> >level, but more at the game level. Well, ISP could also have some 
> >mechanisms to reduce the impact or even Akamai could force a 
> >progressive roll out.
> 
> It's an online game. You can't play the game with outdated assets. 
> You'd not see walls where other players would, for example.
> 
> What you're suggesting is the ability of ISPs to market Internet access 
> at a certain speed but not have to deliver it based on conditions they 
> create.
> 
> 
> -- Niels.
> 
> 
> -- 
> Matt Erculiani
> ERCUL-ARIN

Re: Famous operational issues

[Patrick W. Gilmore]

On Feb 22, 2021, at 7:02 AM, t...@pelican.org wrote:
> On Thursday, 18 February, 2021 22:37, "Warren Kumari"  
> said:
> 
>> 4: Not too long after I started doing networking (and for the same small
>> ISP in Yonkers), I'm flying off to install a new customer. I (of course)
>> think that I'm hot stuff because I'm going to do the install, configure the
>> router, whee, look at me! Anyway, I don't want to check a bag, and so I
>> stuff the Cisco 2501 in a carryon bag, along with tools, etc (this was all
>> pre-9/11!). I'm going through security and the TSA[0] person opens my bag
>> and pulls the router out. "What's this?!" he asks. I politely tell him that
>> it's a router. He says it's not. I'm still thinking that I'm the new
>> hotness, and so I tell him in a somewhat condescending way that it is, and
>> I know what I'm talking about. He tells me that it's not a router, and is
>> starting to get annoyed. I explain using my "talking to a 5 year old" voice
>> that it most certainly is a router. He tells me that lying to airport
>> security is a federal offense, and starts looming at me. I adjust my
>> attitude and start explaining that it's like a computer and makes the
>> Internet work. He gruffly hands me back the router, I put it in my bag and
>> scurry away. As I do so, I hear him telling his colleague that it wasn't a
>> router, and that he certainly knows what a router is, because he does
>> woodwork...
> 
> Here in the UK we avoid that issue by pronouncing the packet-shifter as 
> "rooter", and only the wood-working tool as "rowter" :)

So wrong.

A “root” server is part of the DNS. A “route” server is part of BGP.


> Of course, it raises a different set of problems when talking to the 
> Australians…

Everything is weird down down. But I still like them. :-)

-- 
TTFN,
patrick

Re: Famous operational issues

[Patrick W. Gilmore]

On Feb 18, 2021, at 6:10 PM, Karl Auer  wrote:
> 
> I think it was Macchiavelli who said that one should not ascribe to
> malice anything adequately explained by incompetence…

https://en.wikipedia.org/wiki/Hanlon%27s_razor
Never attribute to malice that which is adequately explained by 
stupidity.

I personally prefer this version from Robert A. Heinlein:
Never underestimate the power of human stupidity.

And to put it on topic, cover your EPOs

In 1994, there was a major earthquake near the city of Los Angeles. City hall 
had to be evacuated and it would take over a year to reinforce the building to 
make it habitable again. My company moved all the systems in the basement of 
city hall to a new datacenter a mile or so away. After the install, we spent 
more than a week coaxing their ancient (even for 1994) machines back online, 
such as a Prime Computer and an AS400 with tons of DASD. Well, tons of 
cabinets, certainly less storage than my watch has now.

I was in the DC going over something with the lady in charge when someone 
walked in to ask her something. She said “just a second”. That person took one 
step to the side of the door and leaned against the wall - right on an EPO 
which had no cover.

Have you ever heard an entire row of DASD spin down instantly? Or taken 40 
minutes to IPL an AS400? In the middle of the business day? For the second most 
populous city in the country?

Me: Maybe you should get a cover for that?
Her: Good idea.

Couple weeks later, in the same DC, going over final checklist. A fedex guy 
walks in. (To this day, no idea how he got in a supposedly locked DC.) She says 
“just a second”, and I get a very strong deja vu feeling. He takes one step to 
the side and leans against the wall.

Me: Did you order that EPO cover?
Her: Nope.

-- 
TTFN,
patrick

Re: Viable Third Option?

[Patrick W. Gilmore]

Second vote for NTT.

Also, second vote for GTT.

-- 
TTFN,
patrick


> On Feb 17, 2021, at 14:07, David Hubbard  
> wrote:
> 
> 
> I’ve been pretty happy with NTT but their POPs can be limited; I’ve had to 
> pick up waves to them, which sometimes still comes out ahead.  I’m slowly 
> dropping Cogent due to the v6 issues.  I haven’t been able to try HE because 
> they and a frequent colo provider I use (Switch) don’t seem to get along.
>  
> From: NANOG  on behalf 
> of Mike Hammett 
> Date: Wednesday, February 17, 2021 at 11:52 AM
> To: NANOG list 
> Subject: Viable Third Option?
>  
> This is from the perspective of an eyeball network. I understand that content 
> networks would have different objectives and reasons. For instance, I have 
> little to no reason as an eyeball network to exchange traffic with any other 
> eyeball network (aside from P2P games). For a content network, getting into 
> the eyeball networks is their objective.
>  
> My crystal ball tells me this thread will spiral out of control because 
> people won't be able to keep it on topic, but it is a question that I hear 
> VERY often. I also expect a lot of purely bad or outdated information to get 
> thrown out.
>  
> Please try to keep it on topic and not being pedantic over relatively 
> unimportant details.
>  
> There are two major low-cost providers, Cogent and HE.
>  
> Cogent
> Refuses to peer IPv6 with HE
> Refuses to peer IPv6 with Google
> Aggressive sales tactics
> Hurricane
> Doesn't have Cogent IPv6 because of Cogent's refusal
> Lack of communities for anything other than blackholes
>  
> I know there are a variety of other providers such as Fusion Network that 
> operate at similar price points, but are available in way fewer locations.
>  
> What else is out there? Anyone else that isn't 5x, 10x the cost?
>  
> Cogent and HE get looked down upon (and sometimes deservedly so), but when I 
> talk to someone trying to sell me a port in 350 Cermak for 8x the cost of 
> Cogent and HE, you better have a very good argument for why you're worth 
> it...  and they never do. "We're not Cogent." "and?" Many times I'm quoted 
> transit that costs more than Cogent + IX + HE and they don't really have a 
> good argument for it.
>  
> As an eyeball, I join an IX and there goes 50% - 85% of my traffic and almost 
> all of my traffic that anyone is going to notice or complain about if there 
> are issues (video streaming).
>  
> I do understand that enterprise eyeballs may have different requirements.
>  
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> 
> Midwest Internet Exchange
> 
> The Brothers WISP

Re: Half Fibre Pair

[Patrick W. Gilmore]

Back in the day, there were these things called half-circuits or half-cables.

Telephone companies in different countries would “share” a cable under the 
ocean, where the company in each country would own “half” the cable - i.e. from 
their shore to the middle of the ocean.

I have no idea what the context here is, but ….

-- 
TTFN,
patrick

> On Jan 26, 2021, at 5:02 PM, Ben Cannon  wrote:
> 
> I’d internet that to be a really weird way to describe a single strand as 
> well, but I could see a confused person asserting it’s 44 out of 88 
> wavelengths? I’ve never heard that.
> 
> Ms. Lady Benjamin PD Cannon, ASCE
> 6x7 Networks & 6x7 Telecom, LLC 
> CEO 
> b...@6by7.net 
> "The only fully end-to-end encrypted global telecommunications company in the 
> world.”
> 
> FCC License KJ6FJJ
> 
> Sent from my iPhone via RFC1149.
> 
>> On Jan 26, 2021, at 12:51 PM, Rod Beck  
>> wrote:
>> 
>> 
>> Can someone explain to me what is a half fibre pair? I took it literally to 
>> mean a single fibre strand but someone insisted it was a large quantity of 
>> spectrum. Please illuminate. On or off list as you please. 
>> 
>> Regards, 
>> 
>> Roderick. 
>> 
>> 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 
>> 
>> 

Re: A letter from the CEO

[Patrick W. Gilmore]

I am impressed that you stepped up, admitted the mistake, and apologized. Thank 
you for taking responsibility.

Anyone reading this who can say they never made a mistake can continue to 
criticize you. As I am about as far from that standard as one can be, I will 
consider this penance enough for your first mistake.

Fair warning: If you email nanog-l multiple times “by mistake”, that will not 
be so easily overlooked. Whether in error or not, multiple “mistakes” become a 
problem. Remember Grey’s law, "sufficiently advanced incompetence is 
indistinguishable from malice” (or the similar Heinlein’s law, or Hanlon’s 
razor, etc.). Perhaps you should spend some extra time verifying your list 
hygiene?

-- 
TTFN,
patrick

> On Nov 20, 2020, at 6:27 PM, Lady Benjamin PD Cannon  wrote:
> 
> Hi all, we never intended to spam the list, that was a total screw-up on our 
> part, one I take full responsibility for.   A list of exclusions got 
> included.   Please accept my sincere apologies.
> 
> Our key differentiator is that we encrypt our backbone links. All of ‘em. So 
> we say we’re another layer to get through in a security policy.  Idea being 
> your data are marginally safer with us than being blasted in the clear.
> 
> Again, sorry for including the list in our list like total nimrods.
> 
> —L.B.
> 
> Lady Benjamin PD Cannon, ASCE
> 6x7 Networks & 6x7 Telecom, LLC 
> CEO 
> b...@6by7.net 
> "The only fully end-to-end encrypted global telecommunications company in the 
> world.”
> FCC License KJ6FJJ
> 
> 
> 
>> On Nov 20, 2020, at 3:20 PM, Mel Beckman > > wrote:
>> 
>> 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 >> > 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:
>>>  
>>> 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
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  
>>> 
>>> 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
>>> 

Re: Apple moved from CDN, and ARIN whois

[Patrick W. Gilmore]

Not everything is moved.

patrick@TiggerBook-C-32 ~ % dig www.apple.com
[…]
;; ANSWER SECTION:
www.apple.com.  219 IN  CNAME   www.apple.com.edgekey.net.
www.apple.com.edgekey.net. 12102 IN CNAME   
www.apple.com.edgekey.net.globalredir.akadns.net.
www.apple.com.edgekey.net.globalredir.akadns.net. 849 IN CNAME 
e6858.dsce9.akamaiedge.net.

Obviously different people will get different answers. But the point is, Apple 
is not completely off 3rd party CDNs. Or maybe they are back on 3rd party CDNs?

-- 
TTFN,
patrick

> On Sep 24, 2020, at 11:39 AM, Mike Hammett  wrote:
> 
> Breaking from current CDN infrastructure without reasonable accessibility to 
> the new CDN is a problem.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions 
>   
>  
>  
> 
> Midwest Internet Exchange 
>   
>  
> 
> The Brothers WISP 
>   
> 
> From: "Denys Fedoryshchenko"  >
> To: nanog@nanog.org 
> Sent: Thursday, September 24, 2020 9:27:07 AM
> Subject: Apple moved from CDN, and ARIN whois
> 
> Hi,
> 
> Interesting, it seems AS6185 moved traffic from all CDN to their own 
> content network.
> I noticed big spikes in traffic and complaints about slowness, figured 
> out, Apple content (especially updates) are not coming from a numerous 
> co-hosted CDN, but became "live",
> congesting upstreams.
> So much efforts on collocating endless CDN in premises to keep things 
> closer to users and handle traffic surges, and yet again, some companies 
> keep inventing their own.
> 
> P.S. I dont know if it is bug, but whois at ARIN return "No match found 
> for n + 17.0.0.0/8" for 17.0.0.0/8,
> but works fine for single ip from this range, like 17.0.0.0, and returns 
> info about 17.0.0.0/8

Re: AANP Akamai

[Patrick W. Gilmore]

netsupp...@akamai.com

-- 
TTFN,
patrick

> On Sep 2, 2020, at 2:40 PM, ahmed.dala...@hrins.net wrote:
> 
> Hello NANOG, 
> 
> Could somebody from Akamai AANP’s network team contact me off-list? I’ve 
> tried the peering and NOC and got no replies in months. 
> 
> Thanks
> Ahmed

Re: Don Smith, RIP.

[Patrick W. Gilmore]

Would like to add my name to the very (very, very, very) long list of people 
who respected and will miss Don.

I do not drink coffee, but for this occasion, it feels appropriate to say:
(coffee != sleep) & (!coffee == sleep)

-- 
TTFN,
patrick

> On Jul 23, 2020, at 7:50 PM, Paul Ferguson  wrote:
> 
> I was informed of this earlier today... I’ve known Don for almost all of the 
> 20+ years that he was engaged with this community. I am very sad to hear of 
> his passing.
> 
> Among his many accomplishments, one of the things that always impressed me 
> about Don was that -- in addition to being a good friend and colleague -- he 
> was also no-nonsense expert technical voice of reason and sanity (also a 
> CCIE) and an early volunteer SANS Daily Incident Handler.
> 
> He will be sorely missed.
> 
> - ferg
> 
> 
> On 7/23/20 4:22 PM, Dobbins, Roland wrote:
> 
>> It is with a heavy heart that I must relate the news that Don Smith, 
>> formerly of CenturyLink and more lately of Netscout Arbor, passed away in 
>> his sleep last night.
>> Don was a colleague, friend, and mentor to many; he was a mainstay of the 
>> operational community, and tirelessly worked to make the Internet safer and 
>> more resilient for us all.  His intellect, wit, and generosity of spirit 
>> were well-known to those who were privileged to have the opportunity to work 
>> with and learn from him.
>> Don’s contributions to the industry were manifold.  While we are all 
>> diminished by his loss, his legacy abides; and we can honor him by 
>> continuing to build upon that foundation, for the betterment of the Internet 
>> community as a whole.
>> Once Don’s family have established plans for his memorial, they will be 
>> posted here.
>> 
>> Roland Dobbins 
> 
> -- 
> Paul Ferguson
> Tacoma, WA  USA
> Illegitimi non carborundum.

Re: Google peering in LAX

[Patrick W. Gilmore]

On Mar 2, 2020, at 6:30 PM, Seth Mattinen  wrote:
> On 3/2/20 3:09 PM, Patrick W. Gilmore wrote:
>> Your routers, your decision.
>> But how much traffic are you sending TO Google? Most people get the vast 
>> majority of traffic FROM Google. They send you videos, you send them ACKs. 
>> Does it matter where the ACKs go?
> 
> 
> A customer is complaining that data they're sending is going over a higher 
> latency (longer) path. I don't know what they're doing I don't generally ask 
> why, but they claim it's a problem for whatever they're doing and I don't 
> have a reason to doubt them. It's not youtube.
> 
> I agree that it's an undesirable long term solution but if filtering select 
> transit-only /24's shifts the path to peering and reduces latency, if the 
> customer is happy then I'm happy and if/when Google starts accepting peering 
> requests again I'll revisit it.

Again, your routers, your decision. But if I had a customer who was 
complaining, I would take steps to fix it.

Google is sending you prefixes over the IX. You have every right to send them 
traffic over the IX to those prefixes.

That said, I fear this is going to be a problem long term. A blind “no /24s” 
filter is dangerous, plus it might solve all traffic issues. It is going to 
take effort to be sure you don’t get bitten by the Law Of Unintended 
Consequences.

Good luck.

-- 
TTFN,
patrick

Re: Google peering in LAX

[Patrick W. Gilmore]

On Mar 2, 2020, at 17:38, Seth Mattinen  wrote:
> On 3/2/20 2:20 PM, Hugo Slabbert wrote:
>> I believe Owen was referring here to Google's actions: that the disagg is 
>> the antisocial behaviour and that transit providers (the people they are 
>> paying) would be more tolerant of that antisocial behaviour than would be 
>> peers (the people they are not paying).
> 
> 
> I suppose that one went over my head.
> 
> To clarify I am the one with peering in LAX and I'm only seeing the big 
> aggregates via the Any2 Easy servers. At the moment I can only infer that 
> Google announces aggregates to the route servers and maybe one only gets the 
> /24's after you turn up a direct neighbor or PNI, but there's no way to do 
> that since Google isn't accepting new peering requests and steers such 
> requests back to what's available on route servers.
> 
> I suppose what I could do is filter /24's from 15169$ in the absence of being 
> able to see if a direct/PNI peering would include them where route servers do 
> not.

Your routers, your decision.

But how much traffic are you sending TO Google? Most people get the vast 
majority of traffic FROM Google. They send you videos, you send them ACKs. Does 
it matter where the ACKs go?

-- 
TTFN,
patrick

Re: Software Defined Networks

[Patrick W. Gilmore]

I tell everyone we had SDNs in the 90s.

But we called it “expect scripts”.

:-)

-- 
TTFN,
patrick


> On Dec 4, 2019, at 9:41 PM, Jennifer Rexford  wrote:
> 
> SDN is definitely an overloaded and confusing term that is used 
> inconsistently.  Here are a few attempts to explain:
> 
> - “The Road to SDN: An Intellectual History of Programmable Networks” (ACM 
> Queue, December 2013)
>   https://queue.acm.org/detail.cfm?id=2560327 
> 
> 
> - “Abstractions for Software-Defined Networks” (CACM, October 2014)
>http://www.cs.cornell.edu/~jnfoster/papers/sdn-abstractions.pdf 
> 
> 
> - “From Ethane to SDN and Beyond” (ACM SIGCOMM CCR, October 2019)
>https://ccronline.sigcomm.org/wp-content/uploads/2019/10/acmdl19-347.pdf 
> 
> 
> — Jen
> 
> 
>> On Dec 4, 2019, at 12:56 PM, Rod Beck > > wrote:
>> 
>> Can someone explain what is all the fuss? SDN is like the latest telecom 
>> craze but the articles do a poor job of explaining the advantages. I seek 
>> concrete examples. 
>> 
>> Regards, 
>> 
>> Roderick. 
>> 
>> 
>> Roderick Beck
>> VP of Business Development
>> United Cable Company
>> www.unitedcablecompany.com 
>> New York City & Budapest
>> rod.b...@unitedcablecompany.com 
>> 36-70-605-5144
> 

HPE SAS Solid State Drives - Critical Firmware Upgrade Required

[Patrick W. Gilmore]

I do not normally post about firmware bugs, but I have this nightmare scenario 
running through my head of someone with a couple of mirrored HPE SSD arrays and 
all the drives going POOF!  simultaneously. Even with an off-site backup, that 
could be disastrous. So if you have HPE SSDs, check this announcement.

https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00092491en_us

-- 
TTFN,
patrick

Re: This endless pissing contest is operational, how? Re: Elad Cohen

[Patrick W. Gilmore]

On Sep 19, 2019, at 9:08 AM, John Sage  wrote:
> 
> On 9/19/19 3:25 AM, Elad Cohen wrote:
>> Mr. Ronald Guilmette
> 
> Are there *any* moderators #OnHere at all?

Moderators? No. Anyone subscribed to the list can post anything at any time.

But posts are reviewed after the fact if there is suspicion or accusations of 
AUP violation.

That is not a real-time process. Give them a day or so.

In the mean time, may I suggest procmail (or whatever your MTA/MUA's filtering 
system is called)?

-- 
TTFN,
patrick

Re: Cogent sales reps who actually respond

[Patrick W. Gilmore]

On Sep 17, 2019, at 9:46 PM, Christopher Morrow  wrote:
> On Tue, Sep 17, 2019 at 6:46 PM Martijn Schmidt via NANOG
>  wrote:
>> 
>> Hi Elad,
>> 
>> Is this policy officially documented by AFRINIC somewhere? Can you make 
>> route objects for legacy AFRINIC resources in their RIR operated IRRDB as a 
>> fallback for RPKI?
>> 
>> Best regards,
>> Martijn 
>> From: Elad Cohen 
>> Sent: 18 September 2019 00:40:13
>> To: Martijn Schmidt ; nanog@nanog.org 
>> 
>> Subject: Re: Cogent sales reps who actually respond
>> 
>> Hello Martin, unfortunately RPKI is not yet technically possible for a 
>> legacy range in Afrinic.
>> _
> 
> technically possible to transfer your afrnic space to ripe though,
> right? and do rpki there.

I do not believe so.

AFRINIC has no inter-RIR transfer policy. I do not believe the fact it is 
legacy space matters, AFRINIC won’t let you move it out, and RIPE wouldn’t let 
you bring it in anyway - AFAIK.

They are the only RIR that does not have an inter-RIR policy. Well, LACNIC just 
voted one in, but it is not implemented - yet.

-- 
TTFN,
patrick

Re: Weekly Routing Table Report

[Patrick W. Gilmore]

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  <mailto:romeo.czum...@tierpoint.com>> wrote:
> 
> These numbers are nothing. Wait till IPv6 really start taking off.
> 
> 
> -Original Message-
> From: NANOG mailto:nanog-boun...@nanog.org>> On 
> Behalf Of Patrick W. Gilmore
> Sent: Friday, August 30, 2019 3:09 PM
> To: North American Operators' Group mailto:nanog@nanog.org>>
> 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 > <mailto:csc...@apnic.net>> 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-st...@lists.apnic.net 
>> <mailto:bgp-st...@lists.apnic.net>
>> 
>> For historical data, please see 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=
>>  
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=>
>>  .
>> 
>> If you have any comments please contact Philip Smith > <mailto:pfsi...@gmail.com>>.
>> 
>> 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=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=
>>  
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=>
>>  
>> Detailed Analysis:  
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n>
>> et_current_=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpk
>> Dj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=
>> 1SzKtCXB1OQXt_kKzDwHmtLE8a44hKEkYUtraUzC3gI=
>> 
>> 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:   

Re: Weekly Routing Table Report

[Patrick W. Gilmore]

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-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 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:   1
>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 

Re: What can ISPs do better? Removing racism out of internet

[Patrick W. Gilmore]

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 
> 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.
>> 
>> 
>> 
>> 

Re: User Unknown (WAS: really amazon?)

[Patrick W. Gilmore]

[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

Re: What can ISPs do better? Removing racism out of internet

[Patrick W. Gilmore]

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.
>> 
>> 
>> 
>> 
>> 

Are network operators morons? [was: CloudFlare issues?]

[Patrick W. Gilmore]

[Removing the attribution, because many people have made statements like this 
over the last day - or year. Just selecting this one as a succinct and recent 
example to illustrate the point.]

>> This blog post, and your CEO on Twitter today, took every opportunity to say 
>> “DAMN THOSE MORONS AT 701!”.
> Damn those morons at 701, period.

I must be old. All I can think is Kids These Days, and maybe Get Off My BGP, er 
Lawn.

Any company running a large, high complex infrastructure is going to make 
mistakes. Period.

It is not like 701 is causing problems every week, or even ever year. If you 
think this one incident proves they are ‘morons’, you are only showing you are 
neither experienced nor mature enough to make that judgement.

To be clear, they may well be morons. I no longer know many people architecting 
and operating 701’s backbone, so I cannot tell you first-hand how smart they 
are. Maybe they are stupid, but exceptionally lucky. However, the facts at hand 
do not support your blanket assertion, and making it does not speak well of you.

OTOH, I do have first-hand experience with previous CF blog posts, and to say 
they spin things in their favor is being generous. But then, it’s a blog post, 
i.e. Marketing. What else would you expect?


I know it is anathema to the ethos of the network engineers & architects to 
work together instead of hurling insults, but it would probably result in a 
better Internet. And isn’t that what we all (supposedly) want?

-- 
TTFN,
patrick

Re: looking for hostname router identifier validation

[Patrick W. Gilmore]

Automation isn’t even that hard - just outsource (e.g. 6Connect).

I get why some things stagnate & collect kruft. But it is actually EASIER, and 
probably cheaper (including people time), to have a 3rd party “just do it” when 
it comes to things like DNS & IPAM.

Then again, if everyone ran everything perfectly … oh, then I could retire. :-)

-- 
TTFN,
patrick



> On Apr 30, 2019, at 8:12 AM, Jared Mauch  wrote:
> 
> While at NTT and at Akamai we have managed to publish sane PTR records and 
> make the forward work as well. You need to automate it by pulling from your 
> router configuration database and publish to your DNS database. If you are 
> still doing either by hand then it’s time to make the switch ASAP. 
> 
> Sent from my iCar
> 
> On Apr 29, 2019, at 4:13 PM, Eric Kuhnke  > wrote:
> 
>> I would caution against putting much faith in the validity of geolocation or 
>> site ID by reverse DNS PTR records. There are a vast number of unmaintained, 
>> ancient, stale, erroneous or wildly wrong PTR records out there. I can name 
>> at least a half dozen ISPs that have absorbed other ASes, some of those 
>> which also acquired other ASes earlier in their history, forming a turducken 
>> of obsolete PTR records that has things with ISP domain names last in use in 
>> the year 2002.
>> 
>> 
>> 
>> On Mon, Apr 29, 2019 at 6:15 AM Matthew Luckie > > wrote:
>> Hi NANOG,
>> 
>> To support Internet topology analysis efforts, I have been working on
>> an algorithm to automatically detect router names inside hostnames
>> (PTR records) for router interfaces, and build regular expressions
>> (regexes) to extract them.  By "router name" inside the hostname, I
>> mean a substring, or set of non-contiguous substrings, that is common
>> among interfaces on a router.  For example, suppose we had the
>> following three routers in the savvis.net  domain 
>> suffix, each with two
>> interfaces:
>> 
>> das1-v3005.nj2.savvis.net 
>> das1-v3006.nj2.savvis.net 
>> 
>> das1-v3005.oc2.savvis.net 
>> das1-v3007.oc2.savvis.net 
>> 
>> das2-v3009.nj2.savvis.net 
>> das2-v3012.nj2.savvis.net 
>> 
>> We might infer the router names are das1|nj2, das1|oc2, and das2|nj2,
>> respectively, and captured by the regex:
>> ^([a-z]+\d+)-[^\.]+\.([a-z]+\d+)\.savvis\.net$
>> 
>> After much refinement based on smaller sets of ground truth, I'm
>> asking for broader feedback from operators.  I've placed a webpage at
>> https://www.caida.org/~mjl/rnc/  that shows 
>> the inferences my algorithm
>> made for 2523 domains.  If you operate one of the domains in that
>> list, I would appreciate it if you could comment (private is probably
>> better but public is fine with me) on whether the regex my algorithm
>> inferred represents your naming intent.  In the first instance, I am
>> most interested in feedback for the suffix / date combinations for
>> suffixes that are colored green, i.e. appear to be reasonable.
>> 
>> Each suffix / date combination links to a page that contains the
>> naming convention and corresponding inferences.  The colored part of
>> each hostname is the inferred router name.  The green hostnames appear
>> to be correct, at least as far as the algorithm determined.  Some
>> suffixes have errors due to either stale hostnames or incorrect
>> training data, and those hostnames are colored red or orange.
>> 
>> If anyone is interested in sets of hostnames the algorithm may have
>> inferred as 'stale' for their network, because for some operators it
>> was an oversight and they were grateful to learn about it, I can
>> provide that information.
>> 
>> Thanks,
>> 
>> Matthew

Re: Special Counsel Office report web site

[Patrick W. Gilmore]

On Apr 17, 2019, at 9:02 PM, Sean Donelan  wrote:
> 
> The Special Counsel's report is expected to be posted on its website sometime 
> between 11 a.m. and noon on Thursday, April 18, 2019.
> 
> https://www.justice.gov/sco
> 
> Since I helped with website for the Starr Report on September 11, 1998, I 
> wish all website admins and network admins well tommorrow morning.
> 
> # config t
> ip go faster

Sean:

I remember “ip go faster” when you first posted it back in 1998. It was 
hilarious, I literally “LOL”ed. However, I did not envy you your job with that 
short notice. (But I did envy you all the people who were willing to help on 
such short notice.) I am still impressed at what you were able to pull together 
in just a few days. Major Kudos.

Things will probably be easier this time. The Internet has evolved ways of 
dealing with exactly this problem. (Avi used to call it “slash-dot insurance”, 
but the idea is the same.) Specifically:

TiggerBook-C-32:~ patrick$ dig +short www.justice.gov
www.justice.gov.edgekey.net.
e7598.dscg.akamaiedge.net.

’Nuff said.

-- 
TTFN,
patrick

Re: AT/as7018 now drops invalid prefixes from peers

[Patrick W. Gilmore]

Jay & everyone AT: I just want to say thank you. Kudos to your team for 
implementing and management for having the intestinal fortitude to do so.

-- 
TTFN,
patrick

> On Feb 11, 2019, at 09:53, Jay Borkenhagen  wrote:
> 
> 
> FYI:
> 
> The AT/as7018 network is now dropping all RPKI-invalid route
> announcements that we receive from our peers.  
> 
> We continue to accept invalid route announcements from our customers,
> at least for now.  We are communicating with our customers whose
> invalid announcements we are propagating, informing them that these
> routes will be accepted by fewer and fewer networks over time.
> 
> Thanks to those of you who are publishing ROAs in the RPKI.  We would
> also like to encourage other networks to join us in taking this step
> to improve the quality of routing information in the Internet.
> 
> Thanks!
> 
>   Jay B.
> 
> 

Re: Stupid Question maybe?

[Patrick W. Gilmore]

Why do you think the network portion needs to be contiguous?

Well, it does now. But that was not always the case.

https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid/answer/Patrick-W-Gilmore
https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid

-- 
TTFN,
patrick

> On Dec 19, 2018, at 09:54, Naslund, Steve  wrote:
> 
> I am wondering how a netmask could be not contiguous when the network portion 
> of the address must be contiguous.  I suppose a bit mask could certainly be 
> anything you want but a netmask specifically identifies the network portion 
> of an address.
> 
> Steve
> 
>> I seem to remember that before the advent of VLSM and CIDR there was 
>> no requirement for the 1 bits in the netmask to be contiguous with no 
>> intervening 0 bits and there was always someone who tested it out on a 
>> production network just to prove a point (usually only once)

Re: Massive Price Increase for X-conns at Telehouse Chelsea, NYC

[Patrick W. Gilmore]

On Sep 17, 2018, at 17:51, Nick Hilliard  wrote:
> Patrick W. Gilmore wrote on 17/09/2018 22:40:
>> Expecting any for-profit business (all of them, not just REITs) to do
>> less than extract maximum cash is deluding yourself.
> oh sure, but price gouging is often bad business practice in the long term.  
> Humans evolved a strong sense of injustice and have a long memory for people 
> and organisations whom they feel take advantage of them.
> 
> As someone else pointed out, business practices like this can work in a 
> rising market, but not so well when market conditions become difficult and 
> people end up in a position of being able to make a choice between 
> organisations which may have treated them badly in the past and those which 
> have not.

No argument. You cut out part of my reply:

When a business gives you something for free, they are expecting
something in return - return business, personal data, lower
churn, good reviews, customer loyalty, etc. - that they can turn
into cash. Any business with little or no competition can be
expected to raise prices. This is not exactly new or surprising.

If you “s/free/free or lower cost/“, it satisfies your statement as well. Every 
business should be deciding “how much can I make -long term-“, and take into 
account what you, I, and others have said here. Some will think short term, and 
(hopefully) the market will punish them over time.

Anyway, I think everyone on the thread agrees. Xconn fees are higher than they 
should be, but not necessarily higher than the market will bear. Yet.

Besides, once everyone turns up a single 100 Tbps port to PacketFabric (or two 
for redundancy), xconn fees will be irrelevant. :-)

-- 
TTFN,
patrick

Re: Massive Price Increase for X-conns at Telehouse Chelsea, NYC

[Patrick W. Gilmore]

On Sep 17, 2018, at 15:08, Ethan O'Toole  wrote:
> 
>> If it’s in an interduct by itself, how much would the square footage per
>> month occupied by the average cross connect be worth?
> 
> These big datacenter companies are REITs. Similar to self-storage units and 
> apartment buildings, they exist to extract as much money as possible from the 
> users. Nothing more or nothing less. The price relief only comes when the 
> market is grossly overbuilt and if there is actual competition.

Maybe I am confused, but I thought every for-profit business exists to extract 
as much money as possible.

When a business gives you something for free, they are expecting something in 
return - return business, personal data, lower churn, good reviews, customer 
loyalty, etc. - that they can turn into cash. Any business with little or no 
competition can be expected to raise prices. This is not exactly new or 
surprising.

Expecting any for-profit business (all of them, not just REITs) to do less than 
extract maximum cash is deluding yourself.

-- 
TTFN,
patrick

Re: Confirming source-routed multicast is dead on the public Internet

[Patrick W. Gilmore]

It is hard to prove a negative.

So let’s prove a positive. One of the largest (2nd largest?) transit networks 
on the planet just affirmatively stated they filter at their border. It is now 
possible to state that multicast is not ubiquitous on the Internet.

If any other large transit network (L3, GTT, HE, Cogent, etc.) would like to 
confirm they filter at their borders as well, that would put the final nail in 
the coffin.

-- 
TTFN,
patrick

> On Jul 31, 2018, at 15:15, Job Snijders  wrote:
> 
> On Tue, 31 Jul 2018 at 23:29, Sean Donelan  wrote:
> 
>> Its tought to prove a negative. I'm extremely confident the answer is yes,
>> public internet multicast is not viable. I did all the google searches,
>> check all the usual CAIDA and ISP sites. IP Multicast is used on private
>> enterprise networks, and some ISPs use it for some closed services.
>> 
>> I got sent back with a random comment from a senior official saying "but
>> I heard different." I bit my tongue, and said I would double (now
>> quadruple) check.
>> 
>> If any ISPs have working IP source-routed multicast on the public
>> Internet that I missed, or what I got wrong.  That's what content
>> distribution networks (cdn's) are for instead.
> 
> 
> 
> AS 2914 is working to fully dismantle all its Internet multicast related
> infrastructure and configs. All MSDP sessions have been turned off, we have
> deny-all filters for the multicast AFI, and the RPs have been shut down.
> 
> For years we haven’t seen actual legit multicast traffic. Also the
> multicast “Default-Free Zone” has always been severely partitioned. Not all
> the players were peering with each other, which led to significant
> complexity for any potential multicast source.
> 
> Reasoning behind turning it off is that it limits the attack surface
> (multicast can bring quite some state to the core), reduces the things we
> need to test and qualify, and by taking this off the RFPs we can perhaps
> consider more vendors.
> 
> However, as you noted; multicast within a single administrative domain
> (such as an access network distributing linear TV), or confined to
> purpose-built L3VPNs very much is a thing. On the public Internet multicast
> seems dead.
> 
> Kind regards,
> 
> Job

Re: What are people using for IPAM these days?

[Patrick W. Gilmore]

While there are many good options, I prefer 6Connect personally. Lots of hooks 
to let you automate things (not just which device has which IP address, much 
more), cheap as hell, and support is unbeatable.

-- 
TTFN,
patrick

> On Jun 11, 2018, at 10:45, Owen DeLong  wrote:
> 
> I find lots of people are using either 6connect or InfoBlox.
> 
> YMMV. Both have good IPv6 support.
> 
> Owen
> 
> 
>> On Jun 11, 2018, at 07:07 , Steve Mikulasik  
>> wrote:
>> 
>> PHPIpam, but I do find there to be a lack of current documentation.

Re: Peering at public exchange authentication

[Patrick W. Gilmore]

MD5 on BGP Considered Harmful

-- 
TTFN,
patrick

Composed on a virtual keyboard, please forgive typos. 


> On Sep 29, 2017, at 13:41, craig washington  
> wrote:
> 
> Hello all,
> 
> 
> Wondering your views or common practices for using authentication via BGP at 
> public exchange locations.
> 
> Just for example, lets say you peer with 5 people in the TELX in Atlanta, do 
> you require them to all use authentication for the BGP session?
> 
> Ive seem some use it and some not use it, is it just a preference?

Re: Max Prefix Out, was Re: Verizon 701 Route leak?

[Patrick W. Gilmore]

On Sep 1, 2017, at 5:26 AM, Randy Bush  wrote:
> 
> i have 142 largish bgp customers, a large enough number that the number
> of prefixes i receive from them varies annoyingly.  how do i reasonably
> automate setting of my outbound prefix limit?

First, it seems you know the inbound so automating the outbound is simple 
arithmetic.

But even if that is unruly, setting the outbound to, say, 300K or so would keep 
you from spilling a full table. Not perfect, but better than nothing.

Orr, perhaps this feature is not for you?

-- 
TTFN,
patrick

Re: BGP peering question

[Patrick W. Gilmore]

> Then you need to decide if you want to be a hop between those two peers or if 
> you want them to serve you only. You can change your routing so that both 
> providers know of your routes but you are not sharing routes between the two 
> providers.

The definition of “peering” to most ISPs would definitely not include becoming 
a “hop” between two peers. Most networks would de-peer you if you sent their 
prefixes to another peer.

-- 
TTFN,
patrick

> On Jul 11, 2017, at 2:40 PM, Ethan E. Dee  wrote:
> 
> Considering the wording you use, I would include this,
> 
> 'Peering' is not always necessary. If you can get an upstream provider to 
> give you a pack of IP's and it is sufficient to just use them as a gateway 
> instead of setting up peering that would be preferred.
> 
> If you decide you want to have multiple upstream providers or hit some kind 
> of speed cap is when I would probably peer with someone else. So that you can 
> keep your IP space but share it across a redundant connection from a 
> different provider.
> 
> Then you need to decide if you want to be a hop between those two peers or if 
> you want them to serve you only. You can change your routing so that both 
> providers know of your routes but you are not sharing routes between the two 
> providers.
> 
> BGP is an enormous protocol and extremely scalable so there is alot to 
> consider before you even decide if you want to peer.
> 
> Because it can sometimes be a headache to setup.
> 
> 
> On 07/11/2017 02:17 PM, Bob Evans wrote:
>> There is one more thing to consider based on your app or content latency
>> criteria needs. Do you provide a service that performs better with low
>> latency - such as live desktop, live video/voice. You may wish to peer to
>> have more control and more direct  path to your customer base. If you
>> identify your customer base in a specific region - then explore the best
>> peering exchange points to utilize in that region. This can help you
>> reduce your packet hop count/ deliver time, etc. etc..
>> 
>> Thank You
>> Bob Evans
>> CTO
>> 
>> 
>> 
>> 
>>> On Mon, Jul 10, 2017 at 4:12 PM, craig washington <
>>> craigwashingto...@hotmail.com> wrote:
>>> 
 Newbie question, what criteria do you look for when you decide that you
 want to peer with someone or if you will accept peering with someone
 from
 an ISP point of view.
>>> 
>>> I assume you mean "reciprocal peering" in the sense of shortcut from your
>>> customers to their customers rather than the more generic sense that any
>>> BGP neighbor is a "peer".
>>> 
>>> 1. What does it cost? If you and they are already on an IX peering switch
>>> or you're both at a relaxed location where running another cable carries
>>> no
>>> monthly fee, there's not much down side.
>>> 
>>> 2. Is the improvement to your service worth the cost? It's not worth
>>> buying
>>> a data circuit or cross-connect to support a 100kbps trickle.
>>> 
>>> 3. Do you have the technical acumen to stay on top of it? Some kinds of
>>> breakage in the peering link could jam traffic between your customers and
>>> theirs. If you're not able to notice and respond, you'd be better off
>>> sending the traffic up to your ISPs and letting them worry about it.
>>> 
>>> If the three of those add up to "yes" instead of "no" then peering may be
>>> smart.
>>> 
>>> Regards,
>>> Bill Herrin
>>> 
>>> 
>>> --
>>> William Herrin  her...@dirtside.com  b...@herrin.us
>>> Dirtside Systems . Web: 
>>> 
>> 
> 
> -- 
> Ethan Dee
> Network Admin
> Globalvision
> 864 704 3600
> e...@globalvision.net
> 
> For Support:
> gv-supp...@globalvision.net
> 864 467 1333
> 
> For Sales:
> sa...@globalvision.net
> 864 467 1333

Re: BGP peering question

[Patrick W. Gilmore]

1) Are they present an IX where I am present?

2) Can they configure BGP correctly?

3) … Beer?

Private interconnect requires actual thinking. Putting a procedure in around 
public peering is just overhead we don’t need.

-- 
TTFN,
patrick

> On Jul 10, 2017, at 4:12 PM, craig washington  
> wrote:
> 
> Hello,
> 
> 
> Newbie question, what criteria do you look for when you decide that you want 
> to peer with someone or if you will accept peering with someone from an ISP 
> point of view.
> 
> 
> Thanks.
> 
> 

Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal

[Patrick W. Gilmore]

On Mar 29, 2017, at 6:48 AM, Mike Hammett  wrote:
> 
> ISPs lying? Sounds like something for the courts, not capitol hill. 

You can’t sue someone because they do something you do not like. Well, you can, 
but you won’t win.

I guess you could ask for the providers to put it in their terms of service so 
you have something actionable to sue on. Now see my previous post. I tell my 
provider “put in a clause that says you won’t sell my data”. They reply “no”. 
And I do … what exactly?

. . . . . . . . .

Not sure we will get closure here. Some people think ISPs should be allowed to 
see data. Others do not. I am in the latter camp. The law is on the desk of 
POTUS which will do exactly what I do not want. My guess is he will sign it. 

Posting to NANOG will not change that. Shall we agree to disagree and move on?

-- 
TTFN,
patrick

Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal

[Patrick W. Gilmore]

Mike:

I know Mr. Glass thinks of me as a not knowledgeable network professional, but 
I hope you know I’ve been doing “ISP stuff” for a couple decades. I know how to 
work the system. There really are not any other broadband providers in my area. 
Hell, LTE doesn’t even work well in my house, and I am less than a dozen miles 
from the center of Boston.

But more importantly, even if there were a second provider, how do you expect 
Joe & Mary User to find that provider if I cannot? (Not trying to be arrogant, 
just saying I am more experience in this field than the average consumer.)

Broadband competition in the US is a myth, at least for most people. At best, 
competition is the exception, not the rule. At worst, it’s a thinly veiled 
monopoly. Hell, they brag about it being a duopoly where they can, as if that’s 
a great thing. Comcast’s chairman brags that Time Warner & Comcast do not 
compete in any cities.

-- 
TTFN,
patrick

> On Mar 29, 2017, at 6:35 AM, Mike Hammett <na...@ics-il.net> wrote:
> 
> Are there really no others or are the ones that are there just marketing 
> themselves poorly? Any nearby you could convince to expand? 
> 
> Over my WISP's coverage, I have at least 13 WISP competitors, 7 broadband 
> wireline and nearly that many enterprise fiber. I admit that may be 
> exceptional. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> - Original Message -
> 
> From: "Patrick W. Gilmore" <patr...@ianai.net> 
> To: "NANOG list" <nanog@nanog.org> 
> Sent: Tuesday, March 28, 2017 9:25:54 PM 
> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers 
> opposed to FCC privacy repeal 
> 
> Thanks, I was a bit confused why you said it, which is apparently because I 
> was confused. :-) 
> 
> I agree we need to do a better job educating users why this is important. 
> 
> And just so my opinion is clear, if there were a true market, I would not 
> mind ISPs who did this (with proper notice). Unfortunately, over half of all 
> households in the US have one or fewer choices for broadband providers. I am 
> one of them. What do I do if my ISP wants to collect my data? VPN everything? 
> 
> -- 
> TTFN, 
> patrick 
> 
>> On Mar 28, 2017, at 10:18 PM, Mike Hammett <na...@ics-il.net> wrote: 
>> 
>> It was more a plea to educate the list on why this matters vs. doom and 
>> gloom with a little more gloom and a little less Carmack. Instead I got more 
>> of the sky is falling. 
>> 
>> Note that I don't intend to ever do this at my ISP, nor my IX. 
>> 
>> 
>> 
>> - 
>> Mike Hammett 
>> Intelligent Computing Solutions <http://www.ics-il.com/> 
>> <https://www.facebook.com/ICSIL> 
>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> 
>> <https://www.linkedin.com/company/intelligent-computing-solutions> 
>> <https://twitter.com/ICSIL> 
>> Midwest Internet Exchange <http://www.midwest-ix.com/> 
>> <https://www.facebook.com/mdwestix> 
>> <https://www.linkedin.com/company/midwest-internet-exchange> 
>> <https://twitter.com/mdwestix> 
>> The Brothers WISP <http://www.thebrotherswisp.com/> 
>> <https://www.facebook.com/thebrotherswisp> 
>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg> 
>> From: "Patrick W. Gilmore" <patr...@ianai.net <mailto:patr...@ianai.net>> 
>> To: "NANOG list" <nanog@nanog.org <mailto:nanog@nanog.org>> 
>> Sent: Tuesday, March 28, 2017 9:12:15 PM 
>> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers 
>> opposed to FCC privacy repeal 
>> 
>> Mike: 
>> 
>> My guess is you do not. 
>> 
>> Which is -precisely- why the users (proletariat?) need to find a way to stop 
>> you. Hence laws & regulations. 
>> 
>> Later in this thread you said “we are done here”. Would that you were so 
>> lucky. 
>> 
>> -- 
>> TTFN, 
>> patrick 
>> 
>>> On Mar 28, 2017, at 5:58 PM, Mike Hammett <na...@ics-il.net 
>>> <mailto:na...@ics-il.net>> wrote: 
>>> 
>>> Why am I supposed to care? 
>>> 
>>> 
>>> 
>>> 
>>> - 
>>> Mike Hammett 
>>> Intelligent Computing Solutions 
>>> 
>>> Midwest Internet Exchange 
>>> 
>>> The Brothers WISP 
>>> 
>>> - Original Message - 
>>> 
>>> From: "Rich Kulawiec"

Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal

[Patrick W. Gilmore]

Thanks, I was a bit confused why you said it, which is apparently because I was 
confused. :-)

I agree we need to do a better job educating users why this is important.

And just so my opinion is clear, if there were a true market, I would not mind 
ISPs who did this (with proper notice). Unfortunately, over half of all 
households in the US have one or fewer choices for broadband providers. I am 
one of them. What do I do if my ISP wants to collect my data? VPN everything?

-- 
TTFN,
patrick

> On Mar 28, 2017, at 10:18 PM, Mike Hammett <na...@ics-il.net> wrote:
> 
> It was more a plea to educate the list on why this matters vs. doom and gloom 
> with a little more gloom and a little less Carmack. Instead I got more of the 
> sky is falling.
> 
> Note that I don't intend to ever do this at my ISP, nor my IX.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions <http://www.ics-il.com/>
>  <https://www.facebook.com/ICSIL> 
> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb> 
> <https://www.linkedin.com/company/intelligent-computing-solutions> 
> <https://twitter.com/ICSIL>
> Midwest Internet Exchange <http://www.midwest-ix.com/>
>  <https://www.facebook.com/mdwestix> 
> <https://www.linkedin.com/company/midwest-internet-exchange> 
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
>  <https://www.facebook.com/thebrotherswisp> 
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> From: "Patrick W. Gilmore" <patr...@ianai.net <mailto:patr...@ianai.net>>
> To: "NANOG list" <nanog@nanog.org <mailto:nanog@nanog.org>>
> Sent: Tuesday, March 28, 2017 9:12:15 PM
> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers 
> opposed to FCC privacy repeal
> 
> Mike:
> 
> My guess is you do not.
> 
> Which is -precisely- why the users (proletariat?) need to find a way to stop 
> you. Hence laws & regulations.
> 
> Later in this thread you said “we are done here”. Would that you were so 
> lucky.
> 
> -- 
> TTFN,
> patrick
> 
> > On Mar 28, 2017, at 5:58 PM, Mike Hammett <na...@ics-il.net 
> > <mailto:na...@ics-il.net>> wrote:
> > 
> > Why am I supposed to care? 
> > 
> > 
> > 
> > 
> > - 
> > Mike Hammett 
> > Intelligent Computing Solutions 
> > 
> > Midwest Internet Exchange 
> > 
> > The Brothers WISP 
> > 
> > - Original Message -
> > 
> > From: "Rich Kulawiec" <r...@gsp.org <mailto:r...@gsp.org>> 
> > To: nanog@nanog.org <mailto:nanog@nanog.org> 
> > Sent: Tuesday, March 28, 2017 4:45:25 PM 
> > Subject: Re: EFF Call for sign-ons: ISPs, networking companies and 
> > engineers opposed to FCC privacy repeal 
> > 
> > On Tue, Mar 28, 2017 at 06:45:04PM +, Mel Beckman wrote: 
> >> The claim oft presented by people favoring this customer abuse is that 
> >> the sold data is anonymous. But it's been well-established that very 
> >> simple data aggregation techniques can develop signatures that reveal 
> >> the identity of people in anonymized data. 
> > 
> > This needs to be repeated loudly and often at every possible opportunity. 
> > I've spent much of the past decade studying this issue and the most 
> > succinct 
> > way I can put it is that however good you (generic "you") think 
> > de-anonymization techniques are, you're wrong: they're way better than 
> > that. 
> > Billions, and I am not exaggerating even a little bit, have been spent 
> > on this problem, and they've been spent by smart people with essentially 
> > unlimited computational resources. And whaddaya know, they've succeeded. 
> > 
> > So if someone presents you a data corpus and says "this data is 
> > anonymized", 
> > the default response should be to mock them, because there is a very high 
> > probability they're either (a) lying or (b) wrong. 
> > 
> > Incidentally, I'm also a signatory of the EFF document, since of course 
> > with nearly 40 years in the field I'm a mere clueless newbie and despite 
> > ripping them a new one about once every other month, I'm clearly a tool 
> > of Google. 
> > 
> > ---rsk 

Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal

[Patrick W. Gilmore]

Mike:

My guess is you do not.

Which is -precisely- why the users (proletariat?) need to find a way to stop 
you. Hence laws & regulations.

Later in this thread you said “we are done here”. Would that you were so lucky.

-- 
TTFN,
patrick

> On Mar 28, 2017, at 5:58 PM, Mike Hammett  wrote:
> 
> Why am I supposed to care? 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> - Original Message -
> 
> From: "Rich Kulawiec"  
> To: nanog@nanog.org 
> Sent: Tuesday, March 28, 2017 4:45:25 PM 
> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers 
> opposed to FCC privacy repeal 
> 
> On Tue, Mar 28, 2017 at 06:45:04PM +, Mel Beckman wrote: 
>> The claim oft presented by people favoring this customer abuse is that 
>> the sold data is anonymous. But it's been well-established that very 
>> simple data aggregation techniques can develop signatures that reveal 
>> the identity of people in anonymized data. 
> 
> This needs to be repeated loudly and often at every possible opportunity. 
> I've spent much of the past decade studying this issue and the most succinct 
> way I can put it is that however good you (generic "you") think 
> de-anonymization techniques are, you're wrong: they're way better than that. 
> Billions, and I am not exaggerating even a little bit, have been spent 
> on this problem, and they've been spent by smart people with essentially 
> unlimited computational resources. And whaddaya know, they've succeeded. 
> 
> So if someone presents you a data corpus and says "this data is anonymized", 
> the default response should be to mock them, because there is a very high 
> probability they're either (a) lying or (b) wrong. 
> 
> Incidentally, I'm also a signatory of the EFF document, since of course 
> with nearly 40 years in the field I'm a mere clueless newbie and despite 
> ripping them a new one about once every other month, I'm clearly a tool 
> of Google. 
> 
> ---rsk 

Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal

[Patrick W. Gilmore]

Having worked networks with massive bandwidth, networks with a single T1 (don’t 
ask, just Google what a T1 is, er, was), and now being somewhere in the middle, 
I agree that the large guys sometimes forget the little guys exist. However, I 
think the change in privacy being proposed hurts -all- users, and 
disproportionately helps the large guys.

A tiny ISP with < 1 Gbps upstream does not have enough user data to sell or 
otherwise “monetize”, while the top 5-10 ISPs have a ready and willing market 
for their users’ data.

Which is why this is so strange. Mr. Glass’ ISP isn’t even a nat on the ass of 
national broadband ISPs. Not an indictment, like I said, I’ve run tiny networks 
myself. However, this change does not help ISPs in his position. Yet he is 
claiming the EFF is fighting for the big guy by opposing this change.

Color me confused. But then again, I am a not knowledgeable network 
professional, so I am probably just confused.

-- 
TTFN,
patrick

> On Mar 28, 2017, at 8:33 AM, Mike Hammett <na...@ics-il.net> wrote:
> 
> Many organizations clamor the FCC for regulation because they hate something 
> about the top 10, 20, etc. ISPs. There is certainly something to hate about 
> them, but almost every time, the baby gets thrown out with the bath water and 
> little ISPs are harmed along the way. Extremes on both sides are what get 
> attention, meanwhile nothing constructive for little ISPs gets done. The 
> policy community forgets them. 
> 
> That same sort of forget about the little guys happens in technical 
> discussions in NANOG as well. Most ISPs and most web hosts have less than 1G 
> of upstream and likely from a single provider. The technical community 
> forgets them. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> 
> Midwest Internet Exchange 
> 
> The Brothers WISP 
> 
> - Original Message -
> 
> From: "Patrick W. Gilmore" <patr...@ianai.net> 
> To: "NANOG list" <nanog@nanog.org> 
> Sent: Monday, March 27, 2017 6:22:27 PM 
> Subject: Re: EFF Call for sign-ons: ISPs, networking companies and engineers 
> opposed to FCC privacy repeal 
> 
> I am somehow please that Mr. Glass does not find me a “knowledgeable network 
> professional”. It feels like a badge of honor. Any other “not” knowledgeable 
> network professionals want to come forward and accept this badge? 
> 
> Personally, I find the FCC’s current rules to be sub-optimal. But saying a 
> gov’t regulation is sub-optimal is like saying water is wet. The question is 
> not whether the regulation could be improved. It is whether the proposed 
> changes are an improvement. 
> 
> To be 1% clear: I prefer the current privacy regime over the new one 
> being proposed. 
> 
> Oh, and I do not believe the EFF is just a shill for Google. But then, I’m 
> just a not knowledgeable network professional, so what do I know? 
> 
> -- 
> TTFN, 
> patrick 
> 
>> On Mar 27, 2017, at 7:13 PM, Brett Glass <na...@brettglass.com> wrote: 
>> 
>> All: 
>> 
>> It's worth noting that most of EFF's list consists of individuals and/or 
>> politically connected organizations, not actual ISPs. This is for good 
>> reason. EFF was founded with the intention of creating a civil rights 
>> organization but has morphed into a captive corporate lobbying shop for 
>> Google, to which several of its board members have close financial ties. EFF 
>> opposes the interests of hard working ISPs and routinely denigrates them and 
>> attempts to foster promotes hatred of them. It also promotes and lobbies for 
>> regulations which advantage Google and disadvantage ISPs -- including the 
>> so-called "broadband privacy" regulations, which heavily burden ISPs while 
>> exempting Google from all oversight. 
>> 
>> No knowledgeable network professional or ISP would support the current FCC 
>> rules. Both they AND the FCC's illegal Title II classification of ISPs must 
>> be rolled back, restoring the FTC's ability to apply uniform and apolitical 
>> privacy standards to all of the players in the Internet ecosystem. The first 
>> step is to support S.J. Res 34/H.J. Res 86, the Congressional resolution 
>> which would revoke the current FCC regulations that were written and paid 
>> for by Google and its lobbyists. So, DO contact your legislators... but do 
>> so in support of the resolutions that will repeal the regulations. It is 
>> vital to the future of the Internet. 
>> 
>> --Brett Glass, Owner and Founder, LARIAT.NET 
>> 
>> At 05:05 PM 3/26/2017, Peter Eckersley wrote: 
>> 
>>> Dear network operators, 
>>> 
>>> I'm sure this

Re: EFF Call for sign-ons: ISPs, networking companies and engineers opposed to FCC privacy repeal

[Patrick W. Gilmore]

I am somehow please that Mr. Glass does not find me a “knowledgeable network 
professional”. It feels like a badge of honor. Any other “not” knowledgeable 
network professionals want to come forward and accept this badge?

Personally, I find the FCC’s current rules to be sub-optimal. But saying a 
gov’t regulation is sub-optimal is like saying water is wet. The question is 
not whether the regulation could be improved. It is whether the proposed 
changes are an improvement.

To be 1% clear: I prefer the current privacy regime over the new one being 
proposed.

Oh, and I do not believe the EFF is just a shill for Google. But then, I’m just 
a not knowledgeable network professional, so what do I know?

-- 
TTFN,
patrick

> On Mar 27, 2017, at 7:13 PM, Brett Glass  wrote:
> 
> All:
> 
> It's worth noting that most of EFF's list consists of individuals and/or 
> politically connected organizations, not actual ISPs. This is for good 
> reason. EFF was founded with the intention of creating a civil rights 
> organization but has morphed into a captive corporate lobbying shop for 
> Google, to which several of its board members have close financial ties. EFF 
> opposes the interests of hard working ISPs and routinely denigrates them and 
> attempts to foster promotes hatred of them. It also promotes and lobbies for 
> regulations which advantage Google and disadvantage ISPs -- including the 
> so-called "broadband privacy" regulations, which heavily burden ISPs while 
> exempting Google from all oversight.
> 
> No knowledgeable network professional or ISP would support the current FCC 
> rules. Both they AND the FCC's illegal Title II classification of ISPs must 
> be rolled back, restoring the FTC's ability to apply uniform and apolitical 
> privacy standards to all of the players in the Internet ecosystem. The first 
> step is to support S.J. Res 34/H.J. Res 86, the Congressional resolution 
> which would revoke the current FCC regulations that were written and paid for 
> by Google and its lobbyists. So, DO contact  your legislators... but do so in 
> support of the resolutions that will repeal the regulations. It is vital to 
> the future of the Internet.
> 
> --Brett Glass, Owner and Founder, LARIAT.NET
> 
> At 05:05 PM 3/26/2017, Peter Eckersley wrote:
> 
>> Dear network operators,
>> 
>> I'm sure this is a controversial topic in the NANOG community, but EFF and a
>> number of ISPs and networking companies are writing to Congress opposing the
>> repeal of the FCC's broadband privacy rules, which require explicit opt-in
>> consent before ISPs use or sell sensitive, non-anonymized data (including
>> non-anonymized locations and browsing histories).
>> 
>> If you or your employer would like to sign on to such a letter, please reply
>> off-list by midday Monday with your name, and a one-sentence description of
>> your affiliation and/or major career accomplishments.

Re: Conference Videos

[Patrick W. Gilmore]

On Mar 13, 2017, at 6:06 PM, Steve Feldman  wrote:
> On Mar 13, 2017, at 2:52 PM, Mike Hammett  wrote:
>> 
>> Another organization I'm in has a hard policy of no recordings of any 
>> sessions at their conferences. They think that recordings of content (even 
>> vendor-sponsored, vendor-specific sessions with vendor consent) would have a 
>> catastrophic effect on conference attendance. 
>> 
>> NANOG doesn't seem to have that issue. Any background on the process to get 
>> there? Any regrets? 
>> 
> 
> Many attendees also find value in the parts of the conference that aren't 
> recorded, like hallway conversations, informal meetings, and even social 
> events.
> 
> Keeping and maintaining the archive of slides and video recordings is an 
> essential part of NANOG's educational mission, which was key to obtaining and 
> maintaining the IRS 401(c)(3) nonprofit status.
> 
> So at least for the time I was on the Board, not only were there no regrets, 
> but we worked hard to maintain and enhance the video experience.



Speakers are informed they are going to be recorded. If they have sensitive 
information, they can choose a track and ask it not be recorded. NANOG has done 
this in the past, but you should talk to the Program Committee if you are 
interested in this.

-- 
TTFN,
patrick

Re: google ipv6 routes via cogent

[Patrick W. Gilmore]

On Mar 3, 2017, at 9:05 PM, Job Snijders <j...@instituut.net> wrote:
> On Fri, Mar 03, 2017 at 09:42:04AM -0500, Patrick W. Gilmore wrote:
>> On Mar 3, 2017, at 7:00 AM, Nick Hilliard <n...@foobar.org> wrote:
>>> Niels Bakker wrote:
>>>> As I explained in the rest of my email that you conveniently didn't
>>>> quote, it's so that you can selectively import routes from all your
>>>> providers in situations where your router cannot handle a full table.
>>> 
>>> it can also break horribly in situations where the provider is providing
>>> "transit" but doesn't provide full transit.
>>> 
>>> OTOH, if you are single-homed, it is highly advisable to accept a
>>> default, the reason being that most transit providers provide bgp
>>> communities with "don't advertise to customers" semantics.  So if you're
>>> single-homed and use a full dfz feed without default route, you will not
>>> have full connectivity to all the routes available from the transit
>>> provider.
> 
> Correct.
> 
>> If you are single-homed, there is no need for BGP at all.
> 
> That is very strongly worded, and in plenty of cases a false assertion.
> 
>> And injecting your ASN into the table is probably not terribly useful
>> to everyone else’s FIB.
> 
> ASNs don't have anything to do with FIB.
> 
>> There are, of course, corner cases. But in general, single-homed
>> people shouldn’t be using BGP.
> 
> There are numerous reasons to use BGP when single-homed:
> 
>- as preparation to multi-home in the (near) future
>- ability to quickly change providers
>- to use BGP based blackholing features
>- to save time on provisioning work (adding new prefixes becomes a
>  matter of just announcing and updating IRR/RPKI).
>- loadbalanacing / loadsharing across multiple links
>- ability to use bgp communities for traffic engineering
> 
> In other words, if you have your own IP space, I'd recommend to get your
> own ASN and use BGP.

First, I said specifically there are corner cases. Everything you say above is 
a corner case. The sum of everyone in need of the above is to the right of the 
decimal compared to all single homed networks. Limiting it to “it you have your 
own IP space” makes the set even smaller.

You are also reaching here. Preparation for multi-homing in the near future is 
just multi-homing. Adding prefixes is a very occasional thing, and in some 
cases is actually not easier with BGP. (Ever worked with some provider’s IRR 
implementation?) Etc.

End of day, if you have your own space and only allow aggregates into the DFZ, 
even as a stub behind someone else, it doesn’t really save RIB slots compared 
to having the upstream announce it for you. My problem is making the exceptions 
sound normal. They are not, and we should not treat them as if they are. Else 
we will end up with people wanting to do it who do not understand what they are 
doing, polluting the table, etc.

I stand by my statement. Single Homed Networks Should Not Use BGP. It is a good 
general rule. There are exceptions, but the exceptions are rare and should be 
approached with caution & clue.

-- 
TTFN,
patrick

Re: google ipv6 routes via cogent

[Patrick W. Gilmore]

On Mar 3, 2017, at 7:00 AM, Nick Hilliard  wrote:
> 
> Niels Bakker wrote:
>> As I explained in the rest of my email that you conveniently didn't
>> quote, it's so that you can selectively import routes from all your
>> providers in situations where your router cannot handle a full table.
> 
> it can also break horribly in situations where the provider is providing
> "transit" but doesn't provide full transit.
> 
> OTOH, if you are single-homed, it is highly advisable to accept a
> default, the reason being that most transit providers provide bgp
> communities with "don't advertise to customers" semantics.  So if you're
> single-homed and use a full dfz feed without default route, you will not
> have full connectivity to all the routes available from the transit
> provider.

If you are single-homed, there is no need for BGP at all. And injecting your 
ASN into the table is probably not terribly useful to everyone else’s FIB.

There are, of course, corner cases. But in general, single-homed people 
shouldn’t be using BGP.

-- 
TTFN,
patrick

Re: SHA1 collisions proven possisble

[Patrick W. Gilmore]

Composed on a virtual keyboard, please forgive typos. 

On Feb 26, 2017, at 21:16, Matt Palmer <mpal...@hezmatt.org> wrote:
>> On Sun, Feb 26, 2017 at 05:41:47PM -0600, Brett Frankenberger wrote:
>>> On Sun, Feb 26, 2017 at 12:18:48PM -0500, Patrick W. Gilmore wrote:
>>> I repeat something I've said a couple times in this thread: If I can
>>> somehow create two docs with the same hash, and somehow con someone
>>> into using one of them, chances are there are bigger problems than a
>>> SHA1 hash collision.
>>> 
>>> If you assume I could somehow get Verisign to use a cert I created to
>>> match another cert with the same hash, why in the hell would that
>>> matter?  I HAVE THE ONE VERISIGN IS USING.  Game over.
>>> 
>>> Valdis came up with a possible use of such documents. While I do not
>>> think there is zero utility in those instances, they are pretty small
>>> vectors compared to, say, having a root cert at a major CA.
>> 
>> I want a google.com cert.  I ask a CA to sign my fake google.com
>> certificate.  They decline, because I can't prove I control google.com.
> 
> Even better: I want a CA cert.  I convince a CA to issue me a regular,
> end-entity cert for `example.com` (which I control) in such a way that I can
> generate another cert with the same SHA1 hash, but which has `CA:TRUE` for
> the Basic Constraints extension.
> 
> Wham!  I can now generate certs for *EVERYONE*.  At least until someone
> notices and takes away my shiny new toy...

Since I have said this somewhere on the order of half a dozen times, I will 
assume I am missing something obvious and all of you are doing it right. 

So let me ask you: The attack creates two docs. You do not know the hash before 
the attack starts. You cannot take an existing file with a known hash and 
create a second file which matches the known hash. You start with nothing, run 
the "attack", and get two NEW docs that have the same hash. A hash which is 
brand new. 

Now, please explain how you take a cert with one hash and somehow use this 
attack, which creates two new docs with a new hash, to do, well, anything?

In the example above, the CA knows the SHA-1 hash of the cert it issued. (We 
are assuming there is a CA which still does SHA-1.) How do you get that CA to 
believe the two OTHER certs with DIFFERENT hashes you have to create so you can 
have two docs with the same hash?

-- 
TTFN,
patrick

Re: SHA1 collisions proven possisble

[Patrick W. Gilmore]

On Feb 25, 2017, at 17:44, Jimmy Hess <mysi...@gmail.com> wrote:
>> On Thu, Feb 23, 2017 at 2:03 PM, Patrick W. Gilmore <patr...@ianai.net> 
>> wrote:
>> 
>> For instance, someone cannot take Verisign’s root cert and create a cert 
>> which collides
>> on SHA-1. Or at least we do not think they can. We’ll know in 90 days when
>> Google releases the code.
> 
> Maybe.   If you assume that no SHA attack was known to anybody at the
> time the Verisign
> cert was originally created,  And that the process used to originally
> create Verisign's root cert
> was not tainted  to leverage such attack.
> 
> If it was tainted,  then  maybe there's another version of the
> certificate that was constructed
> with a different Subject name and Subject public key,  but the same
> SHA1 hash, and same Issuer Name and same Issuer Public Key.

I repeat something I've said a couple times in this thread: If I can somehow 
create two docs with the same hash, and somehow con someone into using one of 
them, chances are there are bigger problems than a SHA1 hash collision.

If you assume I could somehow get Verisign to use a cert I created to match 
another cert with the same hash, why in the hell would that matter? I HAVE THE 
ONE VERISIGN IS USING. Game over.

Valdis came up with a possible use of such documents. While I do not think 
there is zero utility in those instances, they are pretty small vectors 
compared to, say, having a root cert at a major CA.

-- 
TTFN,
patrick

Re: SHA1 collisions proven possisble

[Patrick W. Gilmore]

On Feb 24, 2017, at 12:04 PM, Vincent Bernat <ber...@luffy.cx> wrote:
> ❦ 23 février 2017 21:16 -0500, "Patrick W. Gilmore" <patr...@ianai.net> :
> 
>> A couple things will make this slightly less useful for the attacker:
>>  1) How many people are not going to keep a copy? Once both docs are be
>> found to have the same hash, well, game over.
> 
> But if a transaction is automated, it may be too late. For example, if
> the document is a bank transfer slip.

If I can control the bank side of presenting an automated transfer slip, I 
really don’t need to worry about SHA-1 collisions. I already have all your 
money.

-- 
TTFN,
patrick

Re: SHA1 collisions proven possisble

[Patrick W. Gilmore]

On Feb 23, 2017, at 9:08 PM, valdis.kletni...@vt.edu wrote:
> On Thu, 23 Feb 2017 20:56:28 -0500, "Patrick W. Gilmore" said:
> 
>> According to the blog post, you can create two documents which have the same
>> hash, but you do not know what that hash is until the algorithm finishes. You
>> cannot create a document which matches a pre-existing hash, i.e. the one in 
>> the
>> signed doc.
> 
> You missed the point.  I generate *TWO* documents, with different terms but 
> the
> same hash. I don't care if it matches anything else's hash, as long as these 
> two
> documents have the same hash.  I get you to sign the hash on the *ONE* 
> document I present to you
> that is favorable to you.  I then take your signature and transfer it to the
> *OTHER* document.
> 
> No, I can't create a collision to a document you produced, or do anything to a
> document you already signed. But if I'm allowed to take it and make "minor
> formatting changes", or if I can just make sure I have the last turn in the
> back-and-forth negotiating... because the problem is if I can get you to sign 
> a
> plaintext of my choosing….

I did miss the point. Thanks for setting me straight.

A couple things will make this slightly less useful for the attacker:
1) How many people are not going to keep a copy? Once both docs are be
   found to have the same hash, well, game over.

2) The headers will be very strange indeed. The way this works is
   Google twiddled with the headers to make them look the same. That
   is probably pretty obvious if you look for it.

Oh, and third: Everyone should stop using SHA-1 anyway. :-)

--
TTFN,
patrick



signature.asc
Description: Message signed with OpenPGP

Re: SHA1 collisions proven possisble

[Patrick W. Gilmore]

On Feb 23, 2017, at 6:21 PM, valdis.kletni...@vt.edu wrote:
> On Thu, 23 Feb 2017 17:40:42 -0500, "Ricky Beam" said:
> 
>> cost! However this in no way invalidates SHA-1 or documents signed by
>> SHA-1.
> 
> We negotiate a contract with terms favorable to you.  You sign it (or more
> correctly, sign the SHA-1 hash of the document).
> 
> I then take your signed copy, take out the contract, splice in a different
> version with terms favorable to me.  Since the hash didn't change, your
> signature on the second document remains valid.
> 
> I present it in court, and the judge says "you signed it, you're stuck with
> the terms you signed".
> 
> I think that would count as "invalidates documents signed by SHA-1", don't 
> you?

Doesn’t work that way.

According to the blog post, you can create two documents which have the same 
hash, but you do not know what that hash is until the algorithm finishes. You 
cannot create a document which matches a pre-existing hash, i.e. the one in the 
signed doc. Hence my comment that you can’t take Verisign’s root key and create 
a new key which matches the hash.

-- 
TTFN,
patrick

Re: SHA1 collisions proven possisble

[Patrick W. Gilmore]

On Feb 23, 2017, at 2:59 PM, Ca By  wrote:
> On Thu, Feb 23, 2017 at 10:27 AM Grant Ridder  wrote:
> 
>> Coworker passed this on to me.
>> 
>> Looks like SHA1 hash collisions are now achievable in a reasonable time
>> period
>> https://shattered.io/
>> 
>> -Grant
> 
> 
> Good thing we "secure" our routing protocols with MD5

MD5 on BGP considered Harmful.

> :)

:-)

More seriously: The attack (or at least as much as we can glean from the blog 
post) cannot find a collision (file with same hash) from an arbitrary file. The 
attack creates two files which have the same hash, which is scary, but not as 
bad as it could be.

For instance, someone cannot take Verisign’s root cert and create a cert which 
collides on SHA-1. Or at least we do not think they can. We’ll know in 90 days 
when Google releases the code.

-- 
TTFN,
patrick

Re: gagging *IX directors re snoop/block orders

[Patrick W. Gilmore]

There is one problem: The article is factually incorrect on multiple points. So 
comparing A to B when B is a fairy tale does not make much sense.

The proposed constitutional changes are in the public domain.

-- 
TTFN,
patrick

P.S. Full disclosure, I am a LINX director. So maybe I’m saying this to protect 
myself. If only you could read the proposed changes and decide for yourself. 
Oh, wait….


> On Feb 17, 2017, at 11:07 AM, Ken Chase  wrote:
> 
> Just meant it as a parallel operational example. Both situations, while 
> legally
> distinct, present the same operational issues. 
> 
> Purposely breaking things - and then being required to keep the breakage 
> secret -
> is going to mess up a whole lot of things. (How does Chinese operators handle 
> this?)
> 
> Additionally the snooping is an issue, though I can't imagine anyone depends 
> on
> an IX for maintaining secrecy at a contract level :/ Today's realities.
> 
> /kc
> 
> 
> On Fri, Feb 17, 2017 at 10:03:00AM -0600, Mike Hammett said:
>> I'm not sure Cogent is on any IXes? 
>> 
>> 
>> 
>> 
>> - 
>> Mike Hammett 
>> Intelligent Computing Solutions 
>> http://www.ics-il.com 
>> 
>> Midwest-IX 
>> http://www.midwest-ix.com 
>> 
>> - Original Message -
>> 
>> From: "Ken Chase"  
>> To: nanog@nanog.org 
>> Sent: Friday, February 17, 2017 9:56:23 AM 
>> Subject: gagging *IX directors re snoop/block orders 
>> 
>> And when you go to figure out why that IP wont ping through Cogent on 
>> your exchange, and start troubleshooting but can't get any answers 
>> as to why things are bust... 
>> 
>> [ Clearly now an operational issue for NANOG. ] 
>> 
>> Purposely breaking routing and not being able to talk about why is going to 
>> set many orgs at odds with their basic operational charters. I expect that 
>> a paid service will work when it's provided, including help debugging their 
>> end. 
>> 
>> This is slightly different from a service provider, ostensibly you can 
>> go elsewhere to get service - but when you are a member of a nonprofit *IX 
>> (as we are with TorIX), things get a lot more complex. 
>> 
>> I imagine contract lawyers are going to be all over this. 
>> 
>> https://www.theregister.co.uk/2017/02/17/linx_snoopers_charger_gagging_order/
>>  
>> 
>> (their typo in the url) 
>> 
> 
> /kc 
> -- 
> Ken Chase - m...@sizone.org Guelph/Toronto Canada 

Re: YouTube streaming failures

[Patrick W. Gilmore]

I cannot stream on AppleTV or iPhone. Works on my laptop.

Comcast, Massachusetts.

-- 
TTFN,
patrick

> On Feb 12, 2017, at 8:08 PM, Brett A Mansfield  
> wrote:
> 
> I'm seeing this as well, but only on Apple and Linux products. Seems to be 
> working fine on Windows.
> 
> Thank you,
> Brett A Mansfield
> 
>> On Feb 12, 2017, at 5:30 PM, Mel Beckman  wrote:
>> 
>> We are getting many customer reports of YouTube streaming failures. The 
>> content directory and search work, but attempts to view videos results in 
>> "something went wrong, click to try again" error messages. We've reproduced 
>> the problem on AT, Level3, Frontier, Cox and Comast networks. We are also 
>> seeing it on cellular data connections, which tends to rule out geo-IP 
>> errors. Is anyone else seeing this?
>> 
>> -mel beckman

Re: Akamai and Instagram Ranges

[Patrick W. Gilmore]

Akamai does not give out the IP space they use, for good and valid reasons.

Also, Akamai -is- a cache (just pretend for sake of this argument that none of 
you is ridiculously overly pedantic). If you are trying to cache on-net, why 
not just ask them to do it for you? It’s free.

https://www.akamai.com/us/en/multimedia/documents/akamai/akamai-accelerated-network-partner-aanp-faq.pdf

If you do not qualify for free on-net caches, and cannot peer with them 
anywhere, you could try doing a lookup on some popular Akamai customers, or 
even just www.akamai.com, then “optimize” that block. But that might not work 
as well as you hope. Akamai customers want to see every hit, many of them put 
in ‘cache busting’ code.

Good luck.

-- 
TTFN,
patrick

> On Jan 28, 2017, at 6:22 AM, Shahab Vahabzadeh  
> wrote:
> 
> Hello Hello,
> Can anybody help me to find out IP Address Ranges of Akamai and Instagram?
> I wanna do some optimizations on my cache side?
> Thanks
> 
> -- 
> Regards,
> Shahab Vahabzadeh, Network Engineer and System Administrator
> 
> PGP Key Fingerprint = 1C43 988E 01A8 4D95 B662 9118 CD94 9F10 4DF4 6163

Re: How ISPs bill : Time Zones & 95th Percentile Calculations

[Patrick W. Gilmore]

NANOG’ers:

Steve McManus of Akamai and I have a few questions regarding how providers use 
time zones for billing, and how the 95th percentile (95/5) is calculated.

Many ISPs use UTC on logs and such for reasons which should be obvious. But do 
they use local time for billing? What if there are ports in multiple time 
zones? When calculating 95/5 for LACP groups, is the aggregate used or 
individual physical ports? Etc.

We have created a short form to collect some real-world data on this.

https://goo.gl/d1HRNb

We fully understand this is far from a statistically randomized double-blind 
survey, but it is what we could do in the few minutes of spare time we had.

The form is only 7 multiple-choice questions, with two optional “comment” 
sections and an optional contact info section. We would really appreciate if 
people would share data (anonymously!) on how they bill or get billed.

The form is designed to be used once per relationship. If you have two 
upstreams who use two different billing methods, we would greatly appreciate if 
you could fill in the form twice. It seemed easier to have you click 7 radio 
buttons twice than ask you to explain the different methods on one form.

Thank you for your time. Results will be aggregated and published at some later 
date to be determined. If you would like the results faster, be sure to leave 
your email address in the contact section.

-- 
TTFN,
patrick



-- 
TTFN,
patrick

Re: Common Reliable Out Of Band Management Options at Carrier Hotels

[Patrick W. Gilmore]

That is a good price, and a nice service from the provider.

However, why is that more diverse than LTE? If the colo provider uses the same 
transit and/or transit provider(s) you do, it sounds very not-diverse.

-- 
TTFN,
patrick

> On Jan 18, 2017, at 10:18 AM, Luke Guillory <lguill...@reservetele.com> wrote:
> 
> We were quoted sub $200 for 10M DIA from the datacenter which included a 
> copper handoff which would be more diverse than the cell option.
> 
> 
> 
> Luke
> 
> 
> 
> 
> 
> Luke Guillory
> Network Operations Manager
> 
> Tel:985.536.1212
> Fax:985.536.0300
> Email:  lguill...@reservetele.com
> 
> Reserve Telecommunications
> 100 RTC Dr
> Reserve, LA 70084
> 
> _
> 
> Disclaimer:
> The information transmitted, including attachments, is intended only for the 
> person(s) or entity to which it is addressed and may contain confidential 
> and/or privileged material which should not disseminate, distribute or be 
> copied. Please notify Luke Guillory immediately by e-mail if you have 
> received this e-mail by mistake and delete this e-mail from your system. 
> E-mail transmission cannot be guaranteed to be secure or error-free as 
> information could be intercepted, corrupted, lost, destroyed, arrive late or 
> incomplete, or contain viruses. Luke Guillory therefore does not accept 
> liability for any errors or omissions in the contents of this message, which 
> arise as a result of e-mail transmission. .
> 
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Patrick W. Gilmore
> Sent: Wednesday, January 18, 2017 9:13 AM
> To: NANOG list
> Subject: Re: Common Reliable Out Of Band Management Options at Carrier Hotels
> 
> +1 for OpenGear + LTE / cell.
> 
> Obviously POTS works and is available in any carrier hotel and not insanely 
> expensive.
> 
> Also, lots (not all) colocation providers will give you very cheap ethernet 
> OOB. (E.g. Our colo gives you GigE for the cost of the xconn + 2 Mbps 95/5 
> free.) I would ask before looking at getting a 3G/4G modem. Assuming, of 
> course, you are comfortable with the colo provider’s network being diverse 
> enough from your own.
> 
> --
> TTFN,
> patrick
> 
>> On Jan 18, 2017, at 8:55 AM, David Hubbard <dhubb...@dino.hostasaurus.com> 
>> wrote:
>> 
>> Provided you can get a cell signal, we’ve been very happy with Opengear 
>> boxes.  We’d been using their ACM5508 which is eight serial ports, two 
>> Ethernet, cell.  It runs linux, you can ssh into it, do fancy things like 
>> keep the cell side down and use text messages to bring it up if you need to 
>> get in, does VPN, PPTP, monitors environmental things if needed, etc.  They 
>> replaced that model with the 7004 and 7008 (4 or 8 serial).  They have 
>> console servers if you need more ports; we have a 32-port daisy chained to a 
>> 5508 in a location we had serial growth, but their 7200-series is cell plus 
>> high density serial in one.
>> 
>> In a data center with particularly bad cell reception, Opengear recommended 
>> getting a high gain antenna from wpsantennas.com.  I contacted them and the 
>> recommendation for my specific use case was a Panorama WMMG-7-27.  We had it 
>> mounted above the overhead infrastructure on top of our cage and it 
>> dramatically improved the signal to make it a non-issue.
>> 
>> David
>> 
>> On 1/17/17, 4:59 PM, "NANOG on behalf of Darin Herteen" 
>> <nanog-boun...@nanog.org on behalf of syn...@live.com> wrote:
>> 
>>   Greetings list,
>> 
>> 
>>   We are exploring standardizing our Out Of Band options across our network 
>> and various off-net locations and the question was brought up "What about 
>> carrier hotels? What constraints might present themselves at those 
>> locations?"
>> 
>> 
>>   Assuming each hotel we are located in can provide either Ethernet or DSL 
>> I'm guessing that is going to come a cost (cross-connects, rack space etc..) 
>> that might end up being cost prohibitive.
>> 
>> 
>>   So my inquiry is... What does the list find to be a reasonably priced yet 
>> reliable solution in carrier hotels for OOB? Or is that contradictory :)
>> 
>> 
>>   Thoughts on Cellular?
>> 
>> 
>>   Any experience/insight would be appreciated.
>> 
>> 
>>   Thanks,
>> 
>> 
>>   Darin
>> 
>> 
> 

Re: Common Reliable Out Of Band Management Options at Carrier Hotels

[Patrick W. Gilmore]

+1 for OpenGear + LTE / cell.

Obviously POTS works and is available in any carrier hotel and not insanely 
expensive.

Also, lots (not all) colocation providers will give you very cheap ethernet 
OOB. (E.g. Our colo gives you GigE for the cost of the xconn + 2 Mbps 95/5 
free.) I would ask before looking at getting a 3G/4G modem. Assuming, of 
course, you are comfortable with the colo provider’s network being diverse 
enough from your own.

-- 
TTFN,
patrick

> On Jan 18, 2017, at 8:55 AM, David Hubbard  
> wrote:
> 
> Provided you can get a cell signal, we’ve been very happy with Opengear 
> boxes.  We’d been using their ACM5508 which is eight serial ports, two 
> Ethernet, cell.  It runs linux, you can ssh into it, do fancy things like 
> keep the cell side down and use text messages to bring it up if you need to 
> get in, does VPN, PPTP, monitors environmental things if needed, etc.  They 
> replaced that model with the 7004 and 7008 (4 or 8 serial).  They have 
> console servers if you need more ports; we have a 32-port daisy chained to a 
> 5508 in a location we had serial growth, but their 7200-series is cell plus 
> high density serial in one.
> 
> In a data center with particularly bad cell reception, Opengear recommended 
> getting a high gain antenna from wpsantennas.com.  I contacted them and the 
> recommendation for my specific use case was a Panorama WMMG-7-27.  We had it 
> mounted above the overhead infrastructure on top of our cage and it 
> dramatically improved the signal to make it a non-issue.
> 
> David
> 
> On 1/17/17, 4:59 PM, "NANOG on behalf of Darin Herteen" 
>  wrote:
> 
>Greetings list,
> 
> 
>We are exploring standardizing our Out Of Band options across our network 
> and various off-net locations and the question was brought up "What about 
> carrier hotels? What constraints might present themselves at those locations?"
> 
> 
>Assuming each hotel we are located in can provide either Ethernet or DSL 
> I'm guessing that is going to come a cost (cross-connects, rack space etc..) 
> that might end up being cost prohibitive.
> 
> 
>So my inquiry is... What does the list find to be a reasonably priced yet 
> reliable solution in carrier hotels for OOB? Or is that contradictory :)
> 
> 
>Thoughts on Cellular?
> 
> 
>Any experience/insight would be appreciated.
> 
> 
>Thanks,
> 
> 
>Darin
> 
> 

Re: Dyn DDoS this AM?

[Patrick W. Gilmore]

On Oct 21, 2016, at 12:40 PM, David Hubbard  
wrote:
> 
> Do we know the attack destinations so we can watch transit traffic destined 
> for it to help sources that may be unaware?

My guess is you should track anything to as33517.

-- 
TTFN,
patrick

Re: Dyn DDoS this AM?

[Patrick W. Gilmore]

https://www.caida.org/projects/spoofer/ 
<https://www.caida.org/projects/spoofer/>

-- 
TTFN,
patrick

> On Oct 21, 2016, at 12:01 PM, Mike Hammett <na...@ics-il.net> wrote:
> 
> Are there sites that can test your BCP38\84 compliance? I'm okay, but 
> interested in what I can share to raise awareness. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message -
> 
> From: "Patrick W. Gilmore" <patr...@ianai.net> 
> To: "NANOG list" <nanog@nanog.org> 
> Sent: Friday, October 21, 2016 10:48:21 AM 
> Subject: Re: Dyn DDoS this AM? 
> 
> I cannot give additional info other than what’s been on “public media”. 
> 
> However, I would very much like to say that this is a horrific trend on the 
> Internet. The idea that someone can mention a DDoS then get DDoS’ed Can Not 
> Stand. See Krebs’ on the Democratization of Censorship. See lots of other 
> things. 
> 
> To Dyn and everyone else being attacked: 
> The community is behind you. There are problems, but if we stick together, we 
> can beat these miscreants. 
> 
> To the miscreants: 
> You will not succeed. Search "churchill on the beaches”. It’s a bit 
> melodramatic, but it’s how I feel at this moment. 
> 
> To the rest of the community: 
> If you can help, please do. I know a lot of you are thinking “what can I do?" 
> There is a lot you can do. BCP38 & BCP84 instantly come to mind. Sure, that 
> doesn’t help Mirai, but it still helps. There are many other things you can 
> do as well. 
> 
> But a lot of it is just willingness to help. When someone asks you to help 
> trace an attack, do not let the request sit for a while. Damage is being 
> done. Help your neighbor. When someone’s house is burning, your current 
> project, your lunch break, whatever else you are doing is almost certainly 
> less important. If we stick together and help each other, we can - we WILL - 
> win this war. If we are apathetic, we have already lost. 
> 
> 
> OK, enough motivational speaking for today. But take this to heart. Our 
> biggest problem is people thinking they cannot or do not want to help. 
> 
> -- 
> TTFN, 
> patrick 
> 
>> On Oct 21, 2016, at 10:55 AM, Chris Grundemann <cgrundem...@gmail.com> 
>> wrote: 
>> 
>> Does anyone have any additional details? Seems to be over now, but I'm very 
>> curious about the specifics of such a highly impactful attack (and it's 
>> timing following NANOG 68)... 
>> 
>> https://krebsonsecurity.com/2016/10/ddos-on-dyn-impacts-twitter-spotify-reddit/
>>  
>> 
>> -- 
>> @ChrisGrundemann 
>> http://chrisgrundemann.com 
> 

Re: Dyn DDoS this AM?

[Patrick W. Gilmore]

Attack has re-started. This is the time, folks. Rally the troops, offer help, 
watch your flow.

STOP THIS NOW.

-- 
TTFN,
patrick

> On Oct 21, 2016, at 11:48 AM, Patrick W. Gilmore <patr...@ianai.net> wrote:
> 
> I cannot give additional info other than what’s been on “public media”.
> 
> However, I would very much like to say that this is a horrific trend on the 
> Internet. The idea that someone can mention a DDoS then get DDoS’ed Can Not 
> Stand. See Krebs’ on the Democratization of Censorship. See lots of other 
> things.
> 
> To Dyn and everyone else being attacked:
> The community is behind you. There are problems, but if we stick together, we 
> can beat these miscreants.
> 
> To the miscreants:
> You will not succeed. Search "churchill on the beaches”. It’s a bit 
> melodramatic, but it’s how I feel at this moment.
> 
> To the rest of the community:
> If you can help, please do. I know a lot of you are thinking “what can I do?" 
> There is a lot you can do. BCP38 & BCP84 instantly come to mind. Sure, that 
> doesn’t help Mirai, but it still helps. There are many other things you can 
> do as well.
> 
> But a lot of it is just willingness to help. When someone asks you to help 
> trace an attack, do not let the request sit for a while. Damage is being 
> done. Help your neighbor. When someone’s house is burning, your current 
> project, your lunch break, whatever else you are doing is almost certainly 
> less important. If we stick together and help each other, we can - we WILL - 
> win this war. If we are apathetic, we have already lost.
> 
> 
> OK, enough motivational speaking for today. But take this to heart. Our 
> biggest problem is people thinking they cannot or do not want to help.
> 
> -- 
> TTFN,
> patrick
> 
>> On Oct 21, 2016, at 10:55 AM, Chris Grundemann <cgrundem...@gmail.com 
>> <mailto:cgrundem...@gmail.com>> wrote:
>> 
>> Does anyone have any additional details? Seems to be over now, but I'm very
>> curious about the specifics of such a highly impactful attack (and it's
>> timing following NANOG 68)...
>> 
>> https://krebsonsecurity.com/2016/10/ddos-on-dyn-impacts-twitter-spotify-reddit/
>>  
>> <https://krebsonsecurity.com/2016/10/ddos-on-dyn-impacts-twitter-spotify-reddit/>
>> 
>> -- 
>> @ChrisGrundemann
>> http://chrisgrundemann.com
> 

Re: Dyn DDoS this AM?

[Patrick W. Gilmore]

I cannot give additional info other than what’s been on “public media”.

However, I would very much like to say that this is a horrific trend on the 
Internet. The idea that someone can mention a DDoS then get DDoS’ed Can Not 
Stand. See Krebs’ on the Democratization of Censorship. See lots of other 
things.

To Dyn and everyone else being attacked:
The community is behind you. There are problems, but if we stick together, we 
can beat these miscreants.

To the miscreants:
You will not succeed. Search "churchill on the beaches”. It’s a bit 
melodramatic, but it’s how I feel at this moment.

To the rest of the community:
If you can help, please do. I know a lot of you are thinking “what can I do?" 
There is a lot you can do. BCP38 & BCP84 instantly come to mind. Sure, that 
doesn’t help Mirai, but it still helps. There are many other things you can do 
as well.

But a lot of it is just willingness to help. When someone asks you to help 
trace an attack, do not let the request sit for a while. Damage is being done. 
Help your neighbor. When someone’s house is burning, your current project, your 
lunch break, whatever else you are doing is almost certainly less important. If 
we stick together and help each other, we can - we WILL - win this war. If we 
are apathetic, we have already lost.


OK, enough motivational speaking for today. But take this to heart. Our biggest 
problem is people thinking they cannot or do not want to help.

-- 
TTFN,
patrick

> On Oct 21, 2016, at 10:55 AM, Chris Grundemann  wrote:
> 
> Does anyone have any additional details? Seems to be over now, but I'm very
> curious about the specifics of such a highly impactful attack (and it's
> timing following NANOG 68)...
> 
> https://krebsonsecurity.com/2016/10/ddos-on-dyn-impacts-twitter-spotify-reddit/
> 
> -- 
> @ChrisGrundemann
> http://chrisgrundemann.com

Re: 18 years ago today - rfc 2468

[Patrick W. Gilmore]

We do.

Thank you for reminding us. And thanks to Dr. Postel for making what we do 
possible.

-- 
TTFN,
patrick

> On Oct 15, 2016, at 9:19 AM, Rodney Joffe  wrote:
> 
> To be clear - Oct 16. Which has just tolled in the APAC region. For most of 
> you it will be tomorrow. But no matter. You get the point. 
> 
>> On Oct 15, 2016, at 9:08 AM, Rodney Joffe  wrote:
>> 
>> How time flies

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Patrick W. Gilmore]

On Sep 27, 2016, at 11:49 AM, Roland Dobbins <rdobb...@arbor.net> wrote:
> On 27 Sep 2016, at 22:37, Patrick W. Gilmore wrote:

>> All the more reason to educate people TODAY on why having vulnerable devices 
>> is a Very Bad Idea.
> 
> Yes, but how do they determine that a given device is vulnerable?

Easy: Can you ping it? It’s vulnerable.

:-)

Hey, I said we would have to educate them. I did not say how that would happen.

-- 
TTFN,
patrick

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Patrick W. Gilmore]

On Sep 27, 2016, at 11:35 AM, Roland Dobbins  wrote:
> On 27 Sep 2016, at 21:48, Brielle Bruns wrote:

>> You start cutting off users or putting them into a walled garden until they 
>> fix their machines, and they will start caring.
> 
> It's important to keep in mind that in the not-so-distant future, their 
> 'machines' will include every article of clothing they own, every can of soda 
> in their refrigerator, ever major (and many minor) components of their 
> automobiles, every blade in their windowshades, etc.

All the more reason to educate people TODAY on why having vulnerable devices is 
a Very Bad Idea.

If we try to teach them when a 6-pack of Coke is a DDoS source, we will have 
lost.

-- 
TTFN,
patrick

Re: IP addresses being attacked in Krebs DDoS?

[Patrick W. Gilmore]

On Sep 25, 2016, at 6:35 PM, Brett Glass <na...@brettglass.com> wrote:
> At 03:50 PM 9/25/2016, Patrick W. Gilmore wrote:

>> What Brett is asking seems reasonable, even useful. Unfortunately, it is not 
>> as simple as posting a list of addresses on a website.
>> 
>> Many devices are compromised because of default user/pass settings. 
>> Publishing a list of IP addresses which are so trivially compromised is 
>> handing the miscreants a gift.
> 
> I think you may have misunderstood my request. I am not asking for the IP 
> addresses of the bots, but the address or addresses which they are attacking. 
> I can then scan outgoing packets for those destination addresses, and -- if I 
> see them -- work my way back to the customers who are unknowingly harboring 
> infected devices. Those devices could be PCs, Webcams, DVRs, even 
> thermostats The customers may not know that they have changeable 
> passwords or backdoors.
> 
> By doing this, we can not only enhance our users' security but forestall 
> complaints. We have had more than one customer quit because an infected 
> device on his or her network impacted the quality of video streaming or 
> VoIP... and, of course, he blamed the ISP. Everyone ALWAYS blames the ISP. ;-)

I did read it the other way.

It’s his website, which you can read about on … his website, 
http://krebsonsecurity.com/. (And for everyone on this list, it should be 
trivial to figure out who helped him get the website back up.) Or his twitter 
feed. Or lots of articles about it. Or lots of mailing lists. Or … etc.

-- 
TTFN,
patrick

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Patrick W. Gilmore]

On Sep 25, 2016, at 5:50 PM, ryan landry  wrote:
> On Sun, Sep 25, 2016 at 9:07 PM, Mark Andrews  wrote:

>> This is such a golden opportunity for each of you to find compromised
>> hosts on your network or your customer's network.  The number of
>> genuine lookups of the blog vs the number of botted machine would
>> make it almost certain that anything directed at the blog is a
>> compromised machine.  A phone call to the customer / further analysis
>> would reduce the false positive rate.
>> 
>> Mark
>> 
>> 
> i wish you luck with that. explaining to grandma that her samsung smart tv
> has been rooted and needs to be updated should be good fun.
> 
> for isp's it's a resourcing vs revenue problem. always has been. always
> will be. far more inclined to hold liable the folks that are churning out
> terribly dangerous cpe / IoT(shit). surely some regulatory body is looking
> into this.

Yeah, ‘cause that was so successful in the past.

Remember University of Wisconsin vs. D-Link and their hard-coded NTP server 
address?

-- 
TTFN,
patrick

Re: IP addresses being attacked in Krebs DDoS?

[Patrick W. Gilmore]

On Sep 25, 2016, at 4:01 PM, Brett Glass  wrote:

> As an ISP who is pro-active when it comes to security, I'd like to know what 
> IP address(es) are being hit by the Krebs on Security DDoS attack. If we 
> know, we can warn customers that they are harboring infected PCs and/or IoT 
> devices. (And if all ISPs did this, it would be possible to curtail such 
> attacks and plug the security holes that make them possible.)

[Pardon the slightly less than specific details below. Must be careful about 
disclosing names or information which is not public yet.]

What Brett is asking seems reasonable, even useful. Unfortunately, it is not as 
simple as posting a list of addresses on a website.

Many devices are compromised because of default user/pass settings. Publishing 
a list of IP addresses which are so trivially compromised is handing the 
miscreants a gift.

We have done things like this with open DNS resolvers and open NTP servers. 
(THANK YOU JARED!!!) However, we had a hope of the administrators fixing the 
problem, and they were at least somewhat easier to find.

This list is different. Harder to find, harder to fix. Grandma is unlikely to 
think about logging into her webcam and changing the admin password - to say 
nothing of reading NANOG in the first place. Hell, even if she did, how exactly 
do you remove malware from a SmartTV?

Obviously we do not consider Brett a bad actor. It is likely we can work 
something out with ISPs like Brett and give them the addresses on their network 
which need remediation. But this is not a five minute job. Plus most of the 
people working on this do so in their spare time. So please be patient as the 
lists are gathered, sorted, and offered in a reasonable manner.

If you are a member of the various secops lists, more info will be forthcoming. 
If not, I’m sure someone will make information available in wider channels. 

To be clear, I am not doing this work personally, so do not email me. The 
people who are doing this work deserve a hearty and huge thanks from the 
community. If you know one of them, buy them a drink or dinner, or at least 
give them a hug. :) I know I will be doing so in Dallas if they let me.

-- 
TTFN,
patrick

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Patrick W. Gilmore]

Is CloudFlare able to filter Layer 7 these days? I was under the impression 
CloudFlare was not able to do that.

There have been a lot of rumors about this attack. Some say reflection, others 
say Layer 7, others say .. other stuff. If it is Layer 7, how are you going to 
‘step in front of the cannon’? Would you just pass through all the traffic?

I realize Matthew is always happy for publicity (hell, the whole planet is 
aware of that). But if your system cannot actually do the required task, I’m 
not sure your company should give you credit for offering a service the user 
cannot use.

-- 
TTFN,
patrick

> On Sep 23, 2016, at 3:16 PM, Justin Paine via NANOG  wrote:
> 
> FWIW, we have offered to help. No word so far. We're more than willing
> to step in front of the cannon pointed his way.
> 
> 
> Justin Paine
> Head of Trust & Safety
> CloudFlare Inc.
> PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D
> 
> 
> On Fri, Sep 23, 2016 at 11:58 AM, Marcin Cieslak  wrote:
>> On Fri, 23 Sep 2016, jim deleskie wrote:
>> 
>>> They were hosting him for free, and like insurance, I can assure you if you
>>> are consistently using a service, and not covering the costs of that
>>> service you won't be a client for long.  This is the basis for AUP/client
>>> contracts and have been going back to the days when we all offered only
>>> dialup internet.
>> 
>> Does being a victim of a DDoS constitute a breach of AUP?
>> 
>> Marcin Cieślak

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Patrick W. Gilmore]

On Sep 23, 2016, at 1:58 PM, Grant Ridder  wrote:
> 
> Didn't realize Akamai kicked out or disabled customers
> http://www.zdnet.com/article/krebs-on-security-booted-off-akamai-network-after-ddos-attack-proves-pricey/
> 
> "Security blog Krebs on Security has been taken offline by host Akamai
> Technologies following a DDoS attack which reached 665 Gbps in size.”

Even Brian Krebs doesn’t think Akamai kicks out or disables customers. In the 
article, he admits he is not paying Akamai.

Should Akamai have kept protecting Krebs? Maybe. But I do not think anyone 
should pass judgement on Akamai - unless that person is willing to pick up the 
tab.

(And some of the companies claiming they will pick up the tab are just hoping 
for PR, since they could not have actually protected Krebs.)

-- 
TTFN,
patrick

Re: Comparing carrier hotels and colo: How much are you paying per 208V 30A circuit

[Patrick W. Gilmore]

L6-30s are probably the most common power drop in colocation.

A) Is proprietary. I won’t pretend you will get zero answers, lots of people 
will likely break their NDAs.

B) You can find any and all of those options.

C) Ditto.

Are you looking for specific cities or buildings? Or just trying to see if it 
is available?

-- 
TTFN,
patrick

> On Aug 17, 2016, at 12:37 PM, Eric Kuhnke  wrote:
> 
> a) How much, in $/mo
> 
> b) To what degree is it protected (1+0 generator, 1+1 generator, N+1
> generator, single UPS, 1+1 UPS, etc).
> 
> c) What extent of diversity were you able to obtain vs. your other AC
> circuits (unique riser?  separate transformer?  separate power feed from
> second route into the building?)

Re: cloudflare hosting a ddos service?

[Patrick W. Gilmore]

CloudFlare will claim they are not hosting the problem. They are just hosting 
the web page that lets you pay for or points at or otherwise directs you to the 
problem.

The actual source of packets is some other IP address. Therefore, they can keep 
hosting the web page. It is not sending the actual [spam|DDoS|hack|etc.], 
right? So stop asking them to do something about it!

Whether you think that is the proper way to provide service on the Internet is 
left as an exercise to the reader.

-- 
TTFN,
patrick

> On Jul 26, 2016, at 9:49 PM, Mike  wrote:
> 
> Hi,
> 
>So vbooter.org's dns and web is hosted by cloudflare?
> 
> "Using vBooter you can take down home internet connections, websites and game 
> servers such us Minecraft, XBOX Live, PSN and many more."
> 
>dig -t ns vbooter.org
> 
> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t ns vbooter.org
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62177
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;vbooter.org.INNS
> 
> ;; ANSWER SECTION:
> vbooter.org.21599INNSrick.ns.cloudflare.com.
> vbooter.org.21599INNSamy.ns.cloudflare.com.
> 
> dig -t a www.vbooter.org
> 
> ; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> -t a www.vbooter.org
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34920
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;www.vbooter.org.INA
> 
> ;; ANSWER SECTION:
> www.vbooter.org.299INCNAMEvbooter.org.
> vbooter.org.299INA104.28.13.7
> vbooter.org.299INA104.28.12.7
> 
> 
>Can anyone from cloudflare answer me why this fits with your business 
> model?
> 
> Mike-

Re: Military coup in Turkey?

[Patrick W. Gilmore]

http://www.telegraph.co.uk/news/2016/07/15/turkey-low-flying-jets-and-gunfire-heard-in-ankara1/

-- 
TTFN,
patrick

> On Jul 15, 2016, at 4:44 PM, b...@theworld.com wrote:
> 
> 
> It looks to me like the Turkish internet is unreachable.
> 
> -- 
>-Barry Shein
> 
> Software Tool & Die| b...@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*

Re: Leap Second planned for 2016

[Patrick W. Gilmore]

On Jul 8, 2016, at 7:47 PM, Saku Ytti  wrote:
> On 9 July 2016 at 02:27, Jared Mauch  wrote:

>> Time is actually harder than it seems. Many bits of software break in 
>> unexpected ways. Expect the unexpected.
> 
> Aye. How many have written code like this:
> 
> start = time();
> do_something();
> elapsed = time() - start;
> 
> Virtually all code dealing with passage of time assumes time moves
> only forward, I'm amazed we don't see more issues during leap seconds.
> Portable monotonic time isn't even available in many languages
> standard libraries.
> 
> Hopefully they'll decide in 2023 finally to get rid of leap seconds
> from UTC. Then GPS_TIME, TAI and UTC are all same with different
> static offset.

But time _DOES_ flow. The seconds count
58, 59, 60, 00, 01, …
If you can’t keep up, that’s not UTC’s fault.

As for stopping the leap seconds, talk to the planet Earth. It’s the one who 
will not conveniently rotate properly. Either that, or run REEALLY Fast in 
that -> direction every once in a while. :-)

-- 
TTFN,
patrick

Re: cross connects and their pound of flesh

[Patrick W. Gilmore]

You assume things like "nobody's business" has something to do with "extracting 
money". 

-- 
TTFN,
patrick

Composed on a virtual keyboard, please forgive typos. 


> On Jun 19, 2016, at 13:02, David Barak <thegame...@yahoo.com> wrote:
> 
> Gotta watch out for specifying T1 when you want Ethernet- they could just 
> give you 4 wires on pins 1,2,4,5 :)
> 
> I see the problem as misunderstanding what "physical" actually means: 4-wire 
> twisted pair is different from 8-wire, is different from coax, is different 
> from SMF etc.  what gets run over it is nobody's business but the person 
> controlling the end points.
> 
> David Barak
> Sent from mobile device, please excuse autocorrection artifacts
> 
>> On Jun 19, 2016, at 8:30 AM, Patrick W. Gilmore <patr...@ianai.net> wrote:
>> 
>> Actually, back in the T1/T3 days, colos frequently asked what you ran on the 
>> cable and then charged you based on the capacity of the circuit - even when 
>> it was the same exact cable. Of course, none of us would ever ask for T1 
>> xconn then run ethernet over it.
>> 
>> Colo providers are absolutely worried about drops in xconn revenue. Look at 
>> some large colo providers who are public and split out their numbers. You’ll 
>> see that the percentage of their profit from xconns is usually more than 
>> double the percentage of their revenue from xconns. Put another way, if 
>> xconn revenue drops by 10%, their profit drops by over 20%. How many public 
>> companies can shrug off a 20% drop in EPS? I submit: Not very many.
>> 
>> This is not surprising. When you build your business on the ignorance of 
>> your customers, you are in a world of hurt once your customers learn even a 
>> little bit more.
>> 
>> -- 
>> TTFN,
>> patrick
>> 
>>> On Jun 19, 2016, at 10:13 AM, jim deleskie <deles...@gmail.com> wrote:
>>> 
>>> I don't buy this.  They sold you one cable before, they sell you cable now.
>>> Little difference then we moved customers from a T1 to  T3 back in the
>>> 90's.  If Colo's can't understand more then 20+ yrs of evolution its hardly
>>> right to blame it on the market.
>>> 
>>> 
>>> -jim
>>> Mimir Networks
>>> www.mimirnetworks.com
>>> 
>>> 
>>>> On Sun, Jun 19, 2016 at 11:07 AM, Mike Hammett <na...@ics-il.net> wrote:
>>>> 
>>>> Before 100G, you'd need ten cross connects to move 100G. Now you'd need
>>>> only one. That's a big drop in revenue.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -
>>>> Mike Hammett
>>>> Intelligent Computing Solutions
>>>> http://www.ics-il.com
>>>> 
>>>> 
>>>> 
>>>> Midwest Internet Exchange
>>>> http://www.midwest-ix.com
>>>> 
>>>> 
>>>> - Original Message -
>>>> 
>>>> From: "Brandon Butterworth" <bran...@rd.bbc.co.uk>
>>>> To: br...@pobox.com, d...@temk.in
>>>> Cc: nanog@nanog.org
>>>> Sent: Sunday, June 19, 2016 8:55:57 AM
>>>> Subject: Re: cross connects and their pound of flesh
>>>> 
>>>> Dave Temkin <d...@temk.in> wrote:
>>>>> And as colo operators get freaked out over margin compression on the
>>>>> impending 10->100G conversion (which is happening exponentially faster
>>>> than
>>>>> 100->1G & 1G->10G) they'll need to move those levers of spend around
>>>>> regardless.
>>>> 
>>>> If they've based their model on extracting profit proportional
>>>> to technology speed then they've misunderstood Moore's law
>>>> 
>>>> brandon
>> 

Re: cross connects and their pound of flesh

[Patrick W. Gilmore]

Actually, back in the T1/T3 days, colos frequently asked what you ran on the 
cable and then charged you based on the capacity of the circuit - even when it 
was the same exact cable. Of course, none of us would ever ask for T1 xconn 
then run ethernet over it.

Colo providers are absolutely worried about drops in xconn revenue. Look at 
some large colo providers who are public and split out their numbers. You’ll 
see that the percentage of their profit from xconns is usually more than double 
the percentage of their revenue from xconns. Put another way, if xconn revenue 
drops by 10%, their profit drops by over 20%. How many public companies can 
shrug off a 20% drop in EPS? I submit: Not very many.

This is not surprising. When you build your business on the ignorance of your 
customers, you are in a world of hurt once your customers learn even a little 
bit more.

-- 
TTFN,
patrick

> On Jun 19, 2016, at 10:13 AM, jim deleskie  wrote:
> 
> I don't buy this.  They sold you one cable before, they sell you cable now.
>  Little difference then we moved customers from a T1 to  T3 back in the
> 90's.  If Colo's can't understand more then 20+ yrs of evolution its hardly
> right to blame it on the market.
> 
> 
> -jim
> Mimir Networks
> www.mimirnetworks.com
> 
> 
> On Sun, Jun 19, 2016 at 11:07 AM, Mike Hammett  wrote:
> 
>> Before 100G, you'd need ten cross connects to move 100G. Now you'd need
>> only one. That's a big drop in revenue.
>> 
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> 
>> 
>> 
>> Midwest Internet Exchange
>> http://www.midwest-ix.com
>> 
>> 
>> - Original Message -
>> 
>> From: "Brandon Butterworth" 
>> To: br...@pobox.com, d...@temk.in
>> Cc: nanog@nanog.org
>> Sent: Sunday, June 19, 2016 8:55:57 AM
>> Subject: Re: cross connects and their pound of flesh
>> 
>> Dave Temkin  wrote:
>>> And as colo operators get freaked out over margin compression on the
>>> impending 10->100G conversion (which is happening exponentially faster
>> than
>>> 100->1G & 1G->10G) they'll need to move those levers of spend around
>>> regardless.
>> 
>> If they've based their model on extracting profit proportional
>> to technology speed then they've misunderstood Moore's law
>> 
>> brandon
>> 
>> 

Appeals court upholds Network Neutrality rules

[Patrick W. Gilmore]

Presented without comment:

https://www.washingtonpost.com/news/the-switch/wp/2016/06/14/the-fcc-just-won-a-sweeping-victory-on-net-neutrality-in-federal-court/

Seems topical to NANOG audience.

-- 
TTFN,
patrick

Re: NANOG67 - Tipping point of community and sponsor bashing?

[Patrick W. Gilmore]

On Jun 14, 2016, at 11:50 AM, Hugo Slabbert  wrote:
> On Tue 2016-Jun-14 10:12:10 -0500, Matt Peterson  wrote:
> 
>> This week at NANOG67, a presentation was given early on that did not
>> reflect well for our community at large. Regardless of the content or
>> accuracy of the data presented (not the intention of this thread), specific
>> members of the community (some of which are sponsors) were clearly targeted
>> in a hurtful manner. The delivery of the content did not seem within the
>> spirit of NANOG, but instead a personal opinion piece. While no specific
>> rules of the speaking guidelines
>>  were likely
>> broken, this does bring up a point of where the acceptable threshold exists
>> (if at all). To be abundantly clear - I have nothing against the content
>> itself, the presenter, the PC's choice of allowing this talk, etc. - I only
>> wish to clarify if our guidelines need modernization.
>> 
>> As a community, how do we provide constructive criticism to industry
>> suppliers (that may also be fellow competitors, members, and/or suppliers)?
>> For example, router vendors are routinely compared without specific names
>> mentioned (say in the case of a unpublished vulnerability) - how is a
>> service provider any different?
> 
> I understand the discretion involved in your question, but could we clarify 
> exactly what presentation is being discussed so those of us who were not 
> present at NANOG67 can also participate in an informed way?

I personally think the meta-question Matt asked is more important than opinions 
on a specific presentation. Plus I worry about devolving into a “that was a 
good preso” / “no it wasn’t!!” flamefest.

--
TTFN,
patrick




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Cogent & Google IPv6

[Patrick W. Gilmore]

On Feb 24, 2016, at 4:48 PM, Ricky Beam <jfb...@gmail.com> wrote:
> On Wed, 24 Feb 2016 15:48:22 -0500, Patrick W. Gilmore <patr...@ianai.net> 
> wrote:
>> And Ricky is wrong, the vast majority of prefixes Cogent routes have zero 
>> dollars behind them. Cogent gets paid by customers, not peers. (At least not 
>> the big ones.)
> 
> Show me a single connection to Cogent for which Cogent isn't being paid. 
> Cogent is the only provider I've ever heard of that will not do any form of 
> settlement-free peering.

You really think AT, Comcast, Level 3, Sprint, Verizon, etc. are paying 
Cogent?

Good thing I put my drink down before I read that.

Or do you think Cogent is paying all of them? That is a possibility, but it 
means that Cogent is not getting paid - by definition.

-- 
TTFN,
patrick

Re: Cogent & Google IPv6

[Patrick W. Gilmore]

“Tier One” used to mean SFI or customer downstream to every prefix on the ‘Net. 
Today it is more like “transit free”, since some “tier one” providers have paid 
peering.

And Ricky is wrong, the vast majority of prefixes Cogent routes have zero 
dollars behind them. Cogent gets paid by customers, not peers. (At least not 
the big ones.)

-- 
TTFN,
patrick

> On Feb 24, 2016, at 3:26 PM, Mike Hammett  wrote:
> 
> Isn't that how "Tier 1s" have always operated? Like, always? Customers or 
> peers with peers subject to various requirements. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message -
> 
> From: "Ricky Beam"  
> To: "Matt Hoppes"  
> Cc: "NANOG"  
> Sent: Wednesday, February 24, 2016 2:18:24 PM 
> Subject: Re: Cogent & Google IPv6 
> 
> On Wed, 24 Feb 2016 14:46:56 -0500, Matt Hoppes 
>  wrote: 
>> Isn't that how the Internet is suppose to work? 
> 
> Perhaps. But that's not how *Cogent* works. They have a very idiotic view 
> of "Tier 1". They have no transit connections with anyone; someone is 
> paying them for every prefix they accept. 
> 
> Translation: No one in their right mind does business with Cogent. 

Re: Cogent & Google IPv6

[Patrick W. Gilmore]

Agreed on all points. “Double dipping” is not morally abhorrent, or even 
slightly slimy. However, Cogent customers paid Cogent to connect to The 
Internet, not “The other networks that are paying Cogent”. So in this case, if 
I had to make a choice of which provider to drop, I’d stick with Google. (I do 
not have to make such a decision.)

One could claim the same about HE vs. Cogent. However, I’m still going to give 
the nod to the people saying “we are happy to connect” over the people who say 
“pay me to connect”. Obviously a lot of details I’m glossing over, but HE does 
have, IMHO, a good argument for v6 peering with Cogent. Doesn’t mean either is 
“wrong", just that is how I would vote with my wallet if I had to make the 
choice. (Again, I do not.)

So when FB does the same thing, when Comcast does the same thing, when Apple 
does the same thing, when …. When will Cogent feel enough pain to relent?

Or will this simply delay the full implementation of IPv6 even more, and Cogent 
won’t notice because everyone falls back to v4?

-- 
TTFN,
patrick

> On Feb 24, 2016, at 3:16 PM, Mike Hammett <na...@ics-il.net> wrote:
> 
> Whomever hurts the most will blink first. I don't really care who that is. I 
> have no ill will towards "double dipping". Either they do or they don't offer 
> the desired connectivity and I'm moving on. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message -
> 
> From: "Patrick W. Gilmore" <patr...@ianai.net> 
> To: "NANOG list" <nanog@nanog.org> 
> Sent: Wednesday, February 24, 2016 2:12:07 PM 
> Subject: Re: Cogent & Google IPv6 
> 
> Are HE & Google the new L3 & FT? 
> 
> Nah, L3 would never have baked Cogent a cake. :) 
> 
> Shall we start a pool? Only problem is, should the pool be “who will 
> disconnect from Cogent next?” or “when will Cogent blink?” I’m voting for the 
> former. 
> 
> -- 
> TTFN, 
> patrick 
> 
>> On Feb 24, 2016, at 3:08 PM, Baldur Norddahl <baldur.nordd...@gmail.com> 
>> wrote: 
>> 
>> This is Google saying that Google does not want to pay for traffic to 
>> Cogent. If Cogent wants to exchange any traffic with Google, Cogent is 
>> invited to peer directly with Google. Of course Cogent refuses. And now 
>> Cogent is not only missing the part of IPv6 internet that is Hurricane 
>> Electric single homed but also everything Google. 
>> 
>> Why does Cogent refuse? They used to deliver this traffic on free peering 
>> with another tier 1 provider. Now they are asked to deliver the same 
>> traffic for the same price (free) on a direct peering session. They won't 
>> because Cogent believes Google should pay for this traffic. That another 
>> Cogent customer already paid for the traffic does not matter. They want 
>> double dipping or nothing. So nothing it is. 
>> 
>> Seems to me that if you are serious about IPv6 you can not use Cogent as 
>> your primary or secondary transit provider. You can use them as your third 
>> if you want to. 
>> 
>> Regards, 
>> 
>> Baldur 
>> 
>> 
>> 
>> On 24 February 2016 at 20:46, Matt Hoppes <mhop...@indigowireless.com> 
>> wrote: 
>> 
>>> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6, 
>>> shouldn't the traffic flow out to one of their peer points where another 
>>> peer DOES peer with Google IPv6 and get you in? 
>>> 
>>> Isn't that how the Internet is suppose to work? 
>>> 
>>> 
>>> On 2/24/16 2:43 PM, Damien Burke wrote: 
>>> 
>>>> Not sure. I got the same thing today as well. 
>>>> 
>>>> Is this some kind of ipv6 war? 
>>>> 
>>>> -Original Message- 
>>>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ian Clark 
>>>> Sent: Wednesday, February 24, 2016 10:25 AM 
>>>> To: NANOG 
>>>> Subject: Cogent & Google IPv6 
>>>> 
>>>> Anyone know what's actually going on here? We received the following 
>>>> information from the two of them, and this just started a week or so ago. 
>>>> 
>>>> 
>>>> *From Cogent, the transit provider for a branch office of ours:* 
>>>> 
>>>> Dear Cogent Customer, 
>>>> 
>>>> Thank you for contacting Cogent Customer Support for information about 
>>>> the Google IPv6 addresses you are unable to reach. 
>>>> 
>>>> Google uses transit provider

Re: Cogent & Google IPv6

[Patrick W. Gilmore]

Are HE & Google the new L3 & FT?

Nah, L3 would never have baked Cogent a cake. :)

Shall we start a pool? Only problem is, should the pool be “who will disconnect 
from Cogent next?” or “when will Cogent blink?” I’m voting for the former.

-- 
TTFN,
patrick

> On Feb 24, 2016, at 3:08 PM, Baldur Norddahl  
> wrote:
> 
> This is Google saying that Google does not want to pay for traffic to
> Cogent. If Cogent wants to exchange any traffic with Google, Cogent is
> invited to peer directly with Google. Of course Cogent refuses. And now
> Cogent is not only missing the part of IPv6 internet that is Hurricane
> Electric single homed but also everything Google.
> 
> Why does Cogent refuse? They used to deliver this traffic on free peering
> with another tier 1 provider. Now they are asked to deliver the same
> traffic for the same price (free) on a direct peering session. They won't
> because Cogent believes Google should pay for this traffic. That another
> Cogent customer already paid for the traffic does not matter. They want
> double dipping or nothing. So nothing it is.
> 
> Seems to me that if you are serious about IPv6 you can not use Cogent as
> your primary or secondary transit provider. You can use them as your third
> if you want to.
> 
> Regards,
> 
> Baldur
> 
> 
> 
> On 24 February 2016 at 20:46, Matt Hoppes 
> wrote:
> 
>> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6,
>> shouldn't the traffic flow out to one of their peer points where another
>> peer DOES peer with Google IPv6 and get you in?
>> 
>> Isn't that how the Internet is suppose to work?
>> 
>> 
>> On 2/24/16 2:43 PM, Damien Burke wrote:
>> 
>>> Not sure. I got the same thing today as well.
>>> 
>>> Is this some kind of ipv6 war?
>>> 
>>> -Original Message-
>>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ian Clark
>>> Sent: Wednesday, February 24, 2016 10:25 AM
>>> To: NANOG
>>> Subject: Cogent & Google IPv6
>>> 
>>> Anyone know what's actually going on here?  We received the following
>>> information from the two of them, and this just started a week or so ago.
>>> 
>>> 
>>> *From Cogent, the transit provider for a branch office of ours:*
>>> 
>>> Dear Cogent Customer,
>>> 
>>> Thank you for contacting Cogent Customer Support for information about
>>> the Google IPv6 addresses you are unable to reach.
>>> 
>>> Google uses transit providers to announce their IPv4 routes to Cogent.
>>> 
>>> At this time however, Google has chosen not to announce their IPv6 routes
>>> to Cogent through transit providers.
>>> 
>>> We apologize for any inconvenience this may cause you and will notify you
>>> if there is an update to the situation.
>>> 
>>> 
>>> 
>>> *From Google (re: Cogent):*
>>> 
>>> Unfortunately it seems that your transit provider does not have IPv6
>>> connectivity with Google. We suggest you ask your transit provider to look
>>> for alternatives to interconnect with us.
>>> 
>>> Google maintains an open interconnect policy for IPv6 and welcomes any
>>> network to peer with us for access via IPv6 (and IPv4). For those networks
>>> that aren't able, or chose not to peer with Google via IPv6, they are able
>>> to reach us through any of a large number of transit providers.
>>> 
>>> For more information in how to peer directly with Google please visit
>>> https://peering.google.com
>>> 
>>> 
>>> --
>>> Ian Clark
>>> Lead Network Engineer
>>> DreamHost
>>> 
>>> 

Re: Cogent & Google IPv6

[Patrick W. Gilmore]

To answer Matt’s question, NO.

Assume Cogent peers with NTT. Assume Google peers with NTT. NTT has very good 
v6 connectivity (not an assumption).

Cogent cannot send a packet to NTT and say “please hand this to Google”. Nor 
can Google hand a packet to NTT with a destination of Cogent.

Under this scenario, NTT is not being paid by Cogent or Google. Why would they 
take a packet from one and give it to the other?

-- 
TTFN,
patrick

> On Feb 24, 2016, at 2:53 PM, Max Tulyev  wrote:
> 
> If you connected to Internet ONLY through Cogent - there is no other
> way. If you have another upstreams - Google should be reachable.
> 
> On 24.02.16 21:46, Matt Hoppes wrote:
>> Correct me if I'm wrong, but if Cogent isn't peering with Google IPv6,
>> shouldn't the traffic flow out to one of their peer points where another
>> peer DOES peer with Google IPv6 and get you in?
>> 
>> Isn't that how the Internet is suppose to work?
>> 
>> 
>> On 2/24/16 2:43 PM, Damien Burke wrote:
>>> Not sure. I got the same thing today as well.
>>> 
>>> Is this some kind of ipv6 war?
>>> 
>>> -Original Message-
>>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ian Clark
>>> Sent: Wednesday, February 24, 2016 10:25 AM
>>> To: NANOG
>>> Subject: Cogent & Google IPv6
>>> 
>>> Anyone know what's actually going on here?  We received the following
>>> information from the two of them, and this just started a week or so ago.
>>> 
>>> 
>>> *From Cogent, the transit provider for a branch office of ours:*
>>> 
>>> Dear Cogent Customer,
>>> 
>>> Thank you for contacting Cogent Customer Support for information about
>>> the Google IPv6 addresses you are unable to reach.
>>> 
>>> Google uses transit providers to announce their IPv4 routes to Cogent.
>>> 
>>> At this time however, Google has chosen not to announce their IPv6
>>> routes to Cogent through transit providers.
>>> 
>>> We apologize for any inconvenience this may cause you and will notify
>>> you if there is an update to the situation.
>>> 
>>> 
>>> 
>>> *From Google (re: Cogent):*
>>> 
>>> Unfortunately it seems that your transit provider does not have IPv6
>>> connectivity with Google. We suggest you ask your transit provider to
>>> look for alternatives to interconnect with us.
>>> 
>>> Google maintains an open interconnect policy for IPv6 and welcomes any
>>> network to peer with us for access via IPv6 (and IPv4). For those
>>> networks that aren't able, or chose not to peer with Google via IPv6,
>>> they are able to reach us through any of a large number of transit
>>> providers.
>>> 
>>> For more information in how to peer directly with Google please visit
>>> https://peering.google.com
>>> 
>>> 
>>> -- 
>>> Ian Clark
>>> Lead Network Engineer
>>> DreamHost
>>> 
>> 

Re: PCH Peering Paper

[Patrick W. Gilmore]

> On Feb 17, 2016, at 5:04 PM, Owen DeLong <o...@delong.com> wrote:
> 
> 
>> The premise above therefore devolves to: Since most of the traffic is to 
>> those networks, then most of the bits flow over contracted peerings.
>> 
>> Perhaps “most” can be argued, but obviously a significant portion of all 
>> peering bits flow over contracted sessions. Hopefully we can all agree on 
>> that.
> 
> There’s greater complexity here, however…
> 
> Many of the bits that flow flow over several networks between their source 
> and destination. Likely the vast majority of bits traverse at least 3 
> autonomous systems in the process.
> 
> So when you want to count traffic that went over a non-contract peering 
> session vs. traffic that went over a contract peering session, how do you 
> count traffic that traverses some of each?

Lower in my post:

On Feb 16, 2016, at 10:31 AM, Patrick W. Gilmore <patr...@ianai.net> wrote:
> I guess you could say the bits sent over transit will eventually hit a 
> contracted peering session, since the people in the core contract their 
> sessions. But does that matter to the small guys?


-- 
TTFN,
patrick