Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Constantine A. Murenin]

On Thu, 20 Dec 2018 at 22:12, Brian J. Murrell  wrote:
>
> On Thu, 2018-12-20 at 17:28 -0600, Constantine A. Murenin wrote:
> > Hi Brian,
>
> Hi,
>
> > But what's exactly at 2a03:2880:f012:3:face:b00c:0:1?
>
> It's one of the endpoints involved in Facebook's Messenger service.
> IIRC it's "graph.facebook.com", although I note that that address is
> currently answering as:
>
> graph.facebook.com. 2068IN  CNAME   api.facebook.com.
> api.facebook.com.   2068IN  CNAME   star.c10r.facebook.com.
> star.c10r.facebook.com. 25  IN  2a03:2880:f00e:a:face:b00c:0:2
>
> To be fair though, that one could just be what a load-balancing name
> service is responding at the moment.  Notice that the two addresses are
> only off by one.
>
> But even more interesting is that it's now working:
>
> My traceroute  [v0.92]
> pc.interlinx.bc.ca (2001:1970:5261:d600:c5d9:3319:afbc:3bb6) 
> 2018-12-20T23:07:14-0500
> Keys:  Help   Display mode   Restart statistics   Order of fields   quit
>  Packets   Pings
>  Host  Loss%   Snt   Last   Avg  Best  
> Wrst StDev
>  1. 2001:1970:5261:d600::1  0.0%940.6   0.7   0.4   
> 3.8   0.3
>  2. 2001:1970:4000:82::10.0%949.0  20.2   7.3 
> 889.2  91.0
>  3. 2001:1970:0:1a7::1 39.4%94   19.8  19.5  17.9  
> 26.3   1.8
>  4. 2001:1970:0:61::1  45.2%93   18.1  16.5  14.3  
> 22.5   1.9
>  5. ae7.pr03.yyz1.tfbnw.net 0.0%93   19.6  19.4  14.9  
> 76.8   9.4
>  6. po103.psw04.yyz1.tfbnw.net  0.0%93   14.5  15.8  13.9  
> 24.0   1.5
>  7. po4.msw1ab.01.yyz1.tfbnw.net0.0%93   15.3  15.7  14.2  
> 24.0   1.3
>  8. 2a03:2880:f00e:a:face:b00c:0:1  0.0%93   19.2  15.5  13.7  
> 22.5   1.7
>
> And even just a few minutes ago it was not as I was testing it for
> another (off-list) query:
>
> My traceroute  [v0.92]
> pc.interlinx.bc.ca (2001:1970:5261:d600:c5d9:3319:afbc:3bb6) 
> 2018-12-20T22:47:51-0500
> Keys:  Help   Display mode   Restart statistics   Order of fields   quit
>  Packets   Pings
>  Host  Loss%   Snt   Last   Avg  Best  
> Wrst StDev
>  1. 2001:1970:5261:d600::1  0.0%   1120.6   0.7   0.5   
> 5.1   0.4
>  2. 2001:1970:4000:82::10.0%   1129.2  15.8   7.3 
> 374.4  36.2
>  3. 2001:1970:0:1a7::1 17.0%   112   18.3  19.1  17.6  
> 21.9   0.8
>  4. 2001:1970:0:61::1  33.0%   112   15.9  16.0  14.8  
> 27.9   1.8
>  5. 2001:1978:1300::1   0.0%   112   15.5  17.0  14.1  
> 49.8   4.4
>  6. 2001:1978:203::45   0.0%   112   29.5  29.8  28.2  
> 46.8   2.1
>  7. ???
>
> Perhaps the bit of cage rattling that I have done here has knocked
> something loose.  :-)
>
> Cheers,
> b.

I think TFBNW folks definitely read these lists, even if they never
respond officially.

Their whole network was apparently down via IPv6 for like at least a
few days several years ago; they've then fixed it back in the day by
simply removing the  records. :-)

https://puck.nether.net/pipermail/outages/2013-May/005570.html
https://puck.nether.net/pipermail/outages/2013-May/005579.html

It's kind of amazing that tech reporters never really pick up these
stories, TBH.  I guess these outages don't really sell, especially if
noone but a few selected users can even detect it in the first place,
even if they do last for days or even weeks/years for certain users in
certain configurations.

Cheers,
Constantine.

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Brian J. Murrell]

On Thu, 2018-12-20 at 17:28 -0600, Constantine A. Murenin wrote:
> Hi Brian,

Hi,

> But what's exactly at 2a03:2880:f012:3:face:b00c:0:1?

It's one of the endpoints involved in Facebook's Messenger service. 
IIRC it's "graph.facebook.com", although I note that that address is
currently answering as:

graph.facebook.com. 2068IN  CNAME   api.facebook.com.
api.facebook.com.   2068IN  CNAME   star.c10r.facebook.com.
star.c10r.facebook.com. 25  IN  2a03:2880:f00e:a:face:b00c:0:2

To be fair though, that one could just be what a load-balancing name
service is responding at the moment.  Notice that the two addresses are
only off by one.

But even more interesting is that it's now working:

My traceroute  [v0.92]
pc.interlinx.bc.ca (2001:1970:5261:d600:c5d9:3319:afbc:3bb6) 
2018-12-20T23:07:14-0500
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
 Packets   Pings
 Host  Loss%   Snt   Last   Avg  Best  Wrst 
StDev
 1. 2001:1970:5261:d600::1  0.0%940.6   0.7   0.4   3.8 
  0.3
 2. 2001:1970:4000:82::10.0%949.0  20.2   7.3 889.2 
 91.0
 3. 2001:1970:0:1a7::1 39.4%94   19.8  19.5  17.9  26.3 
  1.8
 4. 2001:1970:0:61::1  45.2%93   18.1  16.5  14.3  22.5 
  1.9
 5. ae7.pr03.yyz1.tfbnw.net 0.0%93   19.6  19.4  14.9  76.8 
  9.4
 6. po103.psw04.yyz1.tfbnw.net  0.0%93   14.5  15.8  13.9  24.0 
  1.5
 7. po4.msw1ab.01.yyz1.tfbnw.net0.0%93   15.3  15.7  14.2  24.0 
  1.3
 8. 2a03:2880:f00e:a:face:b00c:0:1  0.0%93   19.2  15.5  13.7  22.5 
  1.7

And even just a few minutes ago it was not as I was testing it for
another (off-list) query:

My traceroute  [v0.92]
pc.interlinx.bc.ca (2001:1970:5261:d600:c5d9:3319:afbc:3bb6) 
2018-12-20T22:47:51-0500
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
 Packets   Pings
 Host  Loss%   Snt   Last   Avg  Best  Wrst 
StDev
 1. 2001:1970:5261:d600::1  0.0%   1120.6   0.7   0.5   5.1 
  0.4
 2. 2001:1970:4000:82::10.0%   1129.2  15.8   7.3 374.4 
 36.2
 3. 2001:1970:0:1a7::1 17.0%   112   18.3  19.1  17.6  21.9 
  0.8
 4. 2001:1970:0:61::1  33.0%   112   15.9  16.0  14.8  27.9 
  1.8
 5. 2001:1978:1300::1   0.0%   112   15.5  17.0  14.1  49.8 
  4.4
 6. 2001:1978:203::45   0.0%   112   29.5  29.8  28.2  46.8 
  2.1
 7. ???

Perhaps the bit of cage rattling that I have done here has knocked
something loose.  :-)

Cheers,
b.



signature.asc
Description: This is a digitally signed message part

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Brian J. Murrell]

On Thu, 2018-12-20 at 21:44 -0500, Harald Koch wrote:
> 
> To OP: I believe that every last-mile provider in Canda is still
> offering IPv6 as a best-effort, unsupported service.

Yeah.  I'm aware of this.  But I want to give them the benefit of the
doubt that this problem is simply ignorance and something they'd like
to fix rather than any of the more depressing alternatives.

Cheers,
b.



signature.asc
Description: This is a digitally signed message part

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Harald Koch]

On Thu, Dec 20, 2018, at 14:04, David Hubbard wrote:
> Yikes, they should change their name rather than be mistaken for Cogent lol

Cogent started business in 1999 and Cogeco has been around since the 1950s. Who 
should change their name again?

(To OP: I believe that every last-mile provider in Canda is still offering IPv6 
as a best-effort, unsupported service. As a former Canadian networking guy, 
this ... angers me. Good luck ...)

-- 
Harald Koch
c...@pobox.com

Re: Non-profit IX vs. neutral for-profit IX

[Tim Raphael]

The other point to consider is that a NFP can justify more locations and offer 
services (such as extended reach) that don’t have the same profit margins or 
ROI as for-profits.
This often leads to greater value to those with smaller networks and fewer 
customers allowing them to grow and expand without increased aggregation or 
transit costs. This in-turn leads to a richer array of providers and chips away 
at the monopolies in niche markets.

The NFP IXP I work for focuses on providing value to the broader community and 
the Internet as a whole - especially somewhere like Australia which has unique 
constraints.

Additionally, “Neutral” and For-Profit doesn’t always compute in my mind, there 
will always be commercial alliances that lead to not-total neutrality.
When a NFP is owned by it’s members there has to be 100% transparency in 
organisational decisions around member funds and resources which ensures 
accountability reliability.

- Tim


> On 21 Dec 2018, at 3:58 am, Brielle Bruns  wrote:
> 
> On 12/20/2018 12:51 PM, Aaron wrote:
>> Probably price.  Also perception of value.  If you're a for profit 
>> enterprise then they're paying for interconnection plus your bump.  If 
>> you're non-profit the perception is that there is a larger value because 
>> there's no bump.  Whether that's true or not, who knows but that's the 
>> perception I've heard.
> 
> Depending on the size of the non-profit, I'd almost compare it to how the 
> hospitals are here in Boise.
> 
> The non-profits are oversized, monopolistic, price gouging, etc.  Their care 
> can be pretty meh, esp since they bought up all the little independent 
> clinics (yay, ER pricing for a basic family clinic visit).
> 
> The for-profit smaller clinics and hospitals run a pretty tight ship, better 
> value for their money, service is very good, and compete with one another for 
> who has the best service.
> 
> People think they are getting 'better' because they are going to a place that 
> is supposed to be run to benefit people over profit, but alas, you'd be very 
> very wrong.
> -- 
> Brielle Bruns
> The Summit Open Source Development Group
> http://www.sosdg.org/ http://www.ahbl.org
> 

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Constantine A. Murenin]

Hi Brian,

With all the CoGeCo  vs. CogentCo  confusion, I don't think
anyone asked the obvious question yet…

But what's exactly at 2a03:2880:f012:3:face:b00c:0:1?

I've tried reaching it on port http, and it doesn't answer:

% curl -6 -v --head --resolve
"www.facebook.com:80:2a03:2880:f012:3:face:b00c:0:1" www.facebook.com
* Added www.facebook.com:80:2a03:2880:f012:3:face:b00c:0:1 to DNS cache
* About to connect() to www.facebook.com port 80 (#0)
*   Trying 2a03:2880:f012:3:face:b00c:0:1...
* Connection refused
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
%

Meanwhile, regular IPv6 connectivity to Facebook works just fine, over
HE.net, no less.

Cheers,
Constantine.
http://cm.su/

On Thu, 20 Dec 2018 at 11:36, Brian J. Murrell  wrote:
>
> I've been trying to figure out why I can reach an IPv6 address at
> Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two
> Internet connections as well as via an HE IPv6 tunnel but not the other
> of my two ISP connections
>
> At one point in time a traceroute was dying inside of he.net:
>
>  Host  Loss%   Snt   Last   Avg  Best  
> Wrst StDev
>  1. 2001:1970:5261:d600::1  0.0% 72.1   1.3   0.7   
> 2.9   0.8
>  2. 2001:1970:4000:82::10.0% 7   10.0  14.0   8.3  
> 37.9  10.6
>  3. 2001:1970:0:1a6::1 16.7% 7   13.2 215.5  10.8 
> 1031. 455.9
>  4. he.ip6.torontointernetxchange.net   0.0% 7   12.3  12.9  11.2  
> 15.3   1.6
>  5. 100ge9-2.core2.chi1.he.net  0.0% 7   23.6  23.0  21.3  
> 27.6   2.2
>  6. 100ge15-2.core1.chi1.he.net 0.0% 7   21.7  22.5  21.6  
> 24.9   1.2
>  7. 100ge12-1.core1.atl1.he.net 0.0% 7   34.2  35.1  34.1  
> 36.1   0.7
>  8. 100ge5-1.core1.tpa1.he.net  0.0% 7   49.1  46.6  44.8  
> 49.1   1.5
>  9. 100ge12-1.core1.mia1.he.net 0.0% 7   51.6  54.5  50.5  
> 73.3   8.3
> 10. ???
>
> But I think it getting that far time was an anomaly and frankly it
> usually dies even before exiting my ISP's (Cogeco) network like this:
>
>  Host   Loss%   Snt   Last   Avg  Best  
> Wrst StDev
>  1. 2001:1970:5261:d600::1   0.0%330.6   0.7   0.6   
> 1.0   0.1
>  2. 2001:1970:4000:82::1 0.0%338.2  10.8   8.1  
> 40.5   5.6
>  3. 2001:1970:0:1a7::1  15.2%33   23.4  20.1  16.5  
> 23.4   1.5
>  4. 2001:1970:0:61::1   33.3%33   16.8  17.6  14.5  
> 25.9   2.5
>  5. 2001:1978:1300::10.0%33   16.0  17.5  14.2  
> 29.6   3.1
>  6. 2001:1978:203::450.0%33   30.7  30.7  28.4  
> 35.1   1.7
>  7. ???
>
> When I asked the kind folks at he.net for some advice about the problem
> (i.e. in the first traceroute above) their diagnosis was that
> Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco
> IPv6 address.
>
> Trying to talk to my ISP (again, Cogeco) has been impossible.  One
> simply cannot reach the people who know more than how to reset your
> router and configure your e-mail.
>
> I wonder how I could go any further with this to confirm the diagnosis
> that Facebook doesn't have a route to the Cogeco network's IPv6 address
> space given that I only have access to my end of the path.
>
> Cheers,
> b.

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Anurag Bhatia]

Hi Brain


Let's chat offlist to find why this is happening. The behaviour looks
unusual and needs more troubleshooting.


Thanks



Anurag Bhatia
(Hurricane Electric)

On Thu, Dec 20, 2018 at 11:06 PM Brian J. Murrell 
wrote:

> I've been trying to figure out why I can reach an IPv6 address at
> Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two
> Internet connections as well as via an HE IPv6 tunnel but not the other
> of my two ISP connections
>
> At one point in time a traceroute was dying inside of he.net:
>
>  Host  Loss%   Snt   Last   Avg  Best
> Wrst StDev
>  1. 2001:1970:5261:d600::1  0.0% 72.1   1.3   0.7
>  2.9   0.8
>  2. 2001:1970:4000:82::10.0% 7   10.0  14.0   8.3
> 37.9  10.6
>  3. 2001:1970:0:1a6::1 16.7% 7   13.2 215.5  10.8
> 1031. 455.9
>  4. he.ip6.torontointernetxchange.net   0.0% 7   12.3  12.9
> 11.2  15.3   1.6
>  5. 100ge9-2.core2.chi1.he.net  0.0% 7   23.6  23.0
> 21.3  27.6   2.2
>  6. 100ge15-2.core1.chi1.he.net 0.0% 7   21.7  22.5
> 21.6  24.9   1.2
>  7. 100ge12-1.core1.atl1.he.net 0.0% 7   34.2  35.1
> 34.1  36.1   0.7
>  8. 100ge5-1.core1.tpa1.he.net  0.0% 7   49.1  46.6
> 44.8  49.1   1.5
>  9. 100ge12-1.core1.mia1.he.net 0.0% 7   51.6  54.5
> 50.5  73.3   8.3
> 10. ???
>
> But I think it getting that far time was an anomaly and frankly it
> usually dies even before exiting my ISP's (Cogeco) network like this:
>
>  Host   Loss%   Snt   Last   Avg
> Best  Wrst StDev
>  1. 2001:1970:5261:d600::1   0.0%330.6   0.7
>  0.6   1.0   0.1
>  2. 2001:1970:4000:82::1 0.0%338.2  10.8
>  8.1  40.5   5.6
>  3. 2001:1970:0:1a7::1  15.2%33   23.4  20.1
> 16.5  23.4   1.5
>  4. 2001:1970:0:61::1   33.3%33   16.8  17.6
> 14.5  25.9   2.5
>  5. 2001:1978:1300::10.0%33   16.0  17.5
> 14.2  29.6   3.1
>  6. 2001:1978:203::450.0%33   30.7  30.7
> 28.4  35.1   1.7
>  7. ???
>
> When I asked the kind folks at he.net for some advice about the problem
> (i.e. in the first traceroute above) their diagnosis was that
> Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco
> IPv6 address.
>
> Trying to talk to my ISP (again, Cogeco) has been impossible.  One
> simply cannot reach the people who know more than how to reset your
> router and configure your e-mail.
>
> I wonder how I could go any further with this to confirm the diagnosis
> that Facebook doesn't have a route to the Cogeco network's IPv6 address
> space given that I only have access to my end of the path.
>
> Cheers,
> b.
>
>

-- 


Anurag Bhatia
anuragbhatia.com

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Constantine A. Murenin]

The most famous lack of IPv6 connectivity is between AS6939 (Hurricane
Electric LLC) and AS174 (Cogent Communication), not to be confused
with AS7992 (Cogeco Cable), which actually does peer with both
cogentco.com and he.net, including on IPv6.

The HE/Cogent issue is so widely known that, apparently, nearly
everyone in this thread is misattributing the well-known issue as the
reason for the problems described by the OP, but they're very
obviously not related, apart from the similarity in the brand names.

C.

On Thu, 20 Dec 2018 at 15:02, Jacques Latour  wrote:
>
> Job,
>
> What other partitioning like this exists?
>
> Jack
>
>
>
>
>
> From: NANOG  On Behalf Of Job Snijders
> Sent: December 20, 2018 2:11 PM
> To: Matthew Kaufman 
> Cc: nanog@nanog.org
> Subject: Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?
>
>
>
> At this moment it appears there are multiple rifts in the IPv6 default-free 
> zone (that don’t exist in the IPv4 realm), between various organizations. 
> Focusing on one particular partitioning may not help address the other issues.
>
>
>
> Kind regards,
>
>
>
> Job

Re: Auto-reply from Yahoo...

[Rich Kulawiec]

On Thu, Dec 20, 2018 at 12:20:10PM -0700, Grant Taylor via NANOG wrote:
> I would have thought (read: expected) that the nanog-ow...@nanog.com email
> address would have gone to the list owners.

It should.  If it doesn't, then the mail system is broken.  Note that
the -owner address is supported by Mailman (which runs these lists) and
that it will generate an alias for that -- among others -- when the
list is created.

> I agree that there should be an easy way to contact list owners.  Hence the
> standard convention of $LIST-owner address / alias.

Yes.  Y'know, on my never-ending todo list there's an item to write an
update to RFC 2142 with that in it.  And possibly "listmaster" as the
role address for the keeper-of-all-mailing-lists.

---rsk

Re: historical Bogon lists

[Rabbi Rob Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear team,

The fine folks at CAIDA have maintained a repository of the bogon
lists we've produced, going back to 18 SEP 2013.

http://data.caida.org/datasets/bogon/

They are integrating the 2018 data provided by Alessandro Improta, and
will have that in place after the new year.

Will that work for folks, or would a git repository be useful in
different ways?

My thanks to Paul Hick, CAIDA, and Alessandro Improta for the
assistance here!

Thank you!
Rob.
- -- 
Rabbi Rob Thomas   Team Cymru
   "It is easy to believe in freedom of speech for those with whom we
agree." - Leo McKern
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEDcVjavXj08cL/QwdQ+hhYvqF8o0FAlwcBZEACgkQQ+hhYvqF
8o0gRA/7BbZt05/FEMXyTXXDhjB5pbgZVX33EbP+s2M/8EwcriKhHg9vLTqiILS+
3Gq+6N3GboarEqgDBNamEm150H34e536+7+jknAu229P0xe44Wku57WlYYA0GOn+
oCfn0tOjjJzIA4pzf4IXWt7n4I99Er6SD5+LhkSOqBQADqnELDRsb/43dhKtIZvL
eCqkYvPBxHmuuOvrQfASBK9jRYqmuaDeMeemrgeKPsPC26gfG+hmNPWRH6nbZxof
o3OTCE/XQABioHj6XXJwoUVMguYVFwi9XaKa1+wvc3JxbQL5WiS/LZATgnp0PSci
EgklBefGWOyWK+TCWK4Uz72828+wfPdduQx3EHhtxcau+JlmwVaBXSyDxcWb1NpK
dhYdz9y2xkNo/2Mu0A/mVdnn/cayHu1PpOyQIUxltx24xDGjOfmGWwTWaHrYmmX4
LTsy5L0HMJInr0SsPpQVyiysJQlBDB9BWMk/Yi18HZWPMor0q8lvJXu7rroU1rZL
qD86py+CaiJ/T9fhuIPWrQN4mjFhDvZg/jLbb5z4FVwLxmKQP/QuHVwCPhpLNOIe
wVggDQ8XIAEA16NzvP5GOzTlsWekfrqAacHQ9k8z1zvfPShFvK8AlEW18+sQdskO
BsQz+NR0sngTeZh/4re2SUdin2dQrTvcDyPjs+BFnwYGdXFAfrg=
=MOKS
-END PGP SIGNATURE-

RE: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Jacques Latour]

Job,
What other partitioning like this exists?
Jack


From: NANOG  On Behalf Of Job Snijders
Sent: December 20, 2018 2:11 PM
To: Matthew Kaufman 
Cc: nanog@nanog.org
Subject: Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

At this moment it appears there are multiple rifts in the IPv6 default-free 
zone (that don’t exist in the IPv4 realm), between various organizations. 
Focusing on one particular partitioning may not help address the other issues.

Kind regards,

Job

Re: Stupid Question maybe?

[Saku Ytti]

On Thu, 20 Dec 2018 at 21:06, Grant Taylor via NANOG  wrote:

> Do you have /24 cover prefixes advertised to the Internet?

Yes, just it drops at the peering edge as more specific is not found.

> $EMPLOYER requires globally routable access to the link net IP on our
> equipment for specific configurations.  Sorry, I can't go into details.
>
> I'm trying to ascertain if the configuration (as I understand it) that
> advocating for would work for us or not.

Would require details, but I believe the host/32 pointing to interface
(no next-hop IP) ought to  do the trick.

-- 
  ++ytti

Re: Auto-reply from Yahoo...

[Tom Beecher]

To be clear, I got this reported to the team internally that handles the
auto responder stuff. I’m a network guy, not a mail guy.

If the list admins can unsubscribe the address it’s probably going to be
faster, especially around the holidays here.

On Thu, Dec 20, 2018 at 13:09 William Allen Simpson <
william.allen.simp...@gmail.com> wrote:

> On 12/20/18 11:46 AM, Grant Taylor via NANOG wrote:
> > On 12/14/2018 11:48 AM, Grant Taylor wrote:
> >> I've been seeing them for three or four days now.
> >
> > BUMP
> >
> > This has been going on for more than a week now.  I'm quite confident
> that there have been hundreds of auto-replies.  (I'm seeing 285 incoming
> message from the NANOG mailing list since I became aware of the auto-reply.)
> >
> > I'm really surprised that there has not been any reply or action by the
> NANOG list owner(s).  I would have hoped, if not expected, better, or any,
> response by now.
> >
> Well, somebody who seemed to be from Yahoo claimed they were fixing
> their auto-responder.  Obviously, that hasn't been deployed yet.
>

Re: Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released

[M. Omer GOLGELI]

Hi Vasileios,

Congratulations of building this.

Wanted to try it out as a VM but frankly...
The "docker" part put me off...


M.
---


On 2018-12-20 20:23, Vasileios Kotronis wrote:

Dear operators,

FORTH's INSPIRE group and CAIDA are delighted to announce the public
release of the ARTEMIS BGP prefix hijacking detection tool, available
as open-source software at
https://github.com/FORTH-ICS-INSPIRE/artemis

ARTEMIS is designed to be operated by an AS in order to monitor BGP
for potential hijacking attempts against its own prefixes. The system
detects such attacks within seconds, enabling immediate mitigation.
The current release has been tested at a major greek ISP, a dual-homed
edge academic network, and a major US R backbone network.

We would be happy if you'd give it a try and provide feedback. Feel
free to make pull requests on GitHub and help us make this a true
community project.

ARTEMIS is funded by European Research Council (ERC) grant agreement
no. 338402 (NetVolution Project), the RIPE NCC Community Projects
2017, the Comcast Innovation Fund, US NSF grants OAC-1848641 and
CNS-1423659 and US DHS S contract HHSP233201600012C.

Best regards,
Vasileios

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Brian J. Murrell]

On Thu, 2018-12-20 at 21:48 +0200, Max Tulyev wrote:
> Well known problem.

Interesting.  As in a general problem across the Internet or a well
known problem with Cogeco specifically?

> You can use our tunnel broker connection (tb.netassist.ua) as a
> workaround.

Thanks.  But I actually already have a tunnel as well as a(nother)
native IPv6 ISP (yes, I have two consumer ISP connections) which routes
to Facebook properly.

The problem is that for the clients behind this router receiving RAs
for all three upstream connections and plumbing IPv6 addresses on each
of those networks, I know of no way to prevent them from choosing their
Cogeco IP address among the 3 and thus trying to use the Cogeco route.

I can (and have) put a rule into that router to refuse connections to
Facebook when using the Cogeco source address which sends TCP clients a
TCP reset with the hope that (good at least) clients/IPv6 stacks will
try a different source address but the results on that seem spotty at
best.

b.



signature.asc
Description: This is a digitally signed message part

Re: Non-profit IX vs. neutral for-profit IX

[Brielle Bruns]

On 12/20/2018 12:51 PM, Aaron wrote:
Probably price.  Also perception of value.  If you're a for profit 
enterprise then they're paying for interconnection plus your bump.  If 
you're non-profit the perception is that there is a larger value because 
there's no bump.  Whether that's true or not, who knows but that's the 
perception I've heard.


Depending on the size of the non-profit, I'd almost compare it to how 
the hospitals are here in Boise.


The non-profits are oversized, monopolistic, price gouging, etc.  Their 
care can be pretty meh, esp since they bought up all the little 
independent clinics (yay, ER pricing for a basic family clinic visit).


The for-profit smaller clinics and hospitals run a pretty tight ship, 
better value for their money, service is very good, and compete with one 
another for who has the best service.


People think they are getting 'better' because they are going to a place 
that is supposed to be run to benefit people over profit, but alas, 
you'd be very very wrong.

--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: Non-profit IX vs. neutral for-profit IX

[Constantine A. Murenin]

On Thu, 20 Dec 2018 at 13:44, Mike Hammett  wrote:
> What are your thoughts on why a network would join a non-profit IX, but not a 
> neutral, for-profit IX? Let's assume that traffic levels are similar.

But are traffic levels actually similar?  Most areas have one or the
other dominating the field, so, which one you join usually depends on
other (more pressing) factors.

C.

Re: Non-profit IX vs. neutral for-profit IX

[Aaron]

Probably price.  Also perception of value.  If you're a for profit 
enterprise then they're paying for interconnection plus your bump.  If 
you're non-profit the perception is that there is a larger value because 
there's no bump.  Whether that's true or not, who knows but that's the 
perception I've heard.



On 12/20/2018 1:31 PM, Mike Hammett wrote:
What are your thoughts on why a network would join a non-profit IX, 
but not a neutral, for-profit IX? Let's assume that traffic levels are 
similar.




-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 



--

Aaron Wendel
Chief Technical Officer
Wholesale Internet, Inc. (AS 32097)
(816)550-9030
http://www.wholesaleinternet.com

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Max Tulyev]

Well known problem.

You can use our tunnel broker connection (tb.netassist.ua) as a workaround.

17.12.18 22:01, Brian J. Murrell пише:
> I've been trying to figure out why I can reach an IPv6 address at
> Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two
> Internet connections as well as via an HE IPv6 tunnel but not the other
> of my two ISP connections
> 
> At one point in time a traceroute was dying inside of he.net:
> 
>  Host  Loss%   Snt   Last   Avg  Best  
> Wrst StDev
>  1. 2001:1970:5261:d600::1  0.0% 72.1   1.3   0.7   
> 2.9   0.8
>  2. 2001:1970:4000:82::10.0% 7   10.0  14.0   8.3  
> 37.9  10.6
>  3. 2001:1970:0:1a6::1 16.7% 7   13.2 215.5  10.8 
> 1031. 455.9
>  4. he.ip6.torontointernetxchange.net   0.0% 7   12.3  12.9  11.2  
> 15.3   1.6
>  5. 100ge9-2.core2.chi1.he.net  0.0% 7   23.6  23.0  21.3  
> 27.6   2.2
>  6. 100ge15-2.core1.chi1.he.net 0.0% 7   21.7  22.5  21.6  
> 24.9   1.2
>  7. 100ge12-1.core1.atl1.he.net 0.0% 7   34.2  35.1  34.1  
> 36.1   0.7
>  8. 100ge5-1.core1.tpa1.he.net  0.0% 7   49.1  46.6  44.8  
> 49.1   1.5
>  9. 100ge12-1.core1.mia1.he.net 0.0% 7   51.6  54.5  50.5  
> 73.3   8.3
> 10. ???
> 
> But I think it getting that far time was an anomaly and frankly it
> usually dies even before exiting my ISP's (Cogeco) network like this:
> 
>  Host   Loss%   Snt   Last   Avg  Best  
> Wrst StDev
>  1. 2001:1970:5261:d600::1   0.0%330.6   0.7   0.6   
> 1.0   0.1
>  2. 2001:1970:4000:82::1 0.0%338.2  10.8   8.1  
> 40.5   5.6
>  3. 2001:1970:0:1a7::1  15.2%33   23.4  20.1  16.5  
> 23.4   1.5
>  4. 2001:1970:0:61::1   33.3%33   16.8  17.6  14.5  
> 25.9   2.5
>  5. 2001:1978:1300::10.0%33   16.0  17.5  14.2  
> 29.6   3.1
>  6. 2001:1978:203::450.0%33   30.7  30.7  28.4  
> 35.1   1.7
>  7. ???
> 
> When I asked the kind folks at he.net for some advice about the problem
> (i.e. in the first traceroute above) their diagnosis was that
> Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco
> IPv6 address.
> 
> Trying to talk to my ISP (again, Cogeco) has been impossible.  One
> simply cannot reach the people who know more than how to reset your
> router and configure your e-mail.
> 
> I wonder how I could go any further with this to confirm the diagnosis
> that Facebook doesn't have a route to the Cogeco network's IPv6 address
> space given that I only have access to my end of the path.
> 
> Cheers,
> b.
> 

Non-profit IX vs. neutral for-profit IX

[Mike Hammett]

What are your thoughts on why a network would join a non-profit IX, but not a 
neutral, for-profit IX? Let's assume that traffic levels are similar. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

Re: [Request] Contact information for CenturyLink network operations

[Anne P. Mitchell, Esq.]

>> Hi all,
>> 
>> Got a network issue with a DoS'er originating from Comcast into
>> CenturyLink but unable to find the right people to work on this from
>> the CenturyLink side.  Looking for a contact to reach me off-list to
>> help solve this or insert a block in a upstream router.
> 
> Don, please email me offlist (amitch...@isipp.com);  CenturyLink is now part 
> of Level3...we can get you to the right person.

Oops, as was just pointed out to me offlist, I reversed that (too much blood in 
my caffeine stream)...I should have said that CenturyLink *borged* Level3.

Anne

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Constantine A. Murenin]

They should probably just rebrand to CoGeCo, but that does look kinda
silly, so, they probably won't.

https://en.wikipedia.org/wiki/Cogeco

> Cogeco is an acronym for Compagnie Générale de Communication ("General 
> Communications Company").

Both Cogent Communications and Cogeco are in pretty different market
segments (for anyone in the know), so, they each probably don't really
care about the confusion in their respective target markets.

C.

On Thu, 20 Dec 2018 at 13:13, David Hubbard
 wrote:
>
> Yikes, they should change their name rather than be mistaken for Cogent lol
>
> On 12/20/18, 2:04 PM, "Clayton Zekelman"  wrote:
>
>
> Cogent != Cogeco
>
> Cogent - US Backbone Provider
> Cogeco - Canadian Cable TV & Internet provider
>
> At 01:00 PM 20/12/2018, David Hubbard wrote:
> >Google and HE don't have IPv6 connectivity with
> >Cogent because Cogent's CEO has been in some
> >decades long pissing match with them about free
> >settlement free peering.  That's the unfortunate
> >reality of the situation; nothing you can do
> >other than have another route to HE/Google IPv6
> >targets.  We have some Cogent circuits that are
> >effectively useless for IPv6 as our customer
> >base has heavy traffic to/from Google cloud
> >services, so they can't be used for a backup /
> >DR scenario; their only real value is an optimal
> >route to other Cogent customers.  I'm slowly
> >replacing our Cogent circuits when feasible
> >because the reality is our customers reaching
> >Google over IPv6 via all our upstreams is more
> >valuable than Cogent's cost savings.
> >
> >
> >
> >On 12/20/18, 12:37 PM, "NANOG on behalf of
> >Brian J. Murrell"  >behalf of br...@interlinx.bc.ca> wrote:
> >
> > I've been trying to figure out why I can reach an IPv6 address at
> > Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my 
> two
> > Internet connections as well as via an HE IPv6 tunnel but not the 
> other
> > of my two ISP connections
> >
> > At one point in time a traceroute was dying inside of he.net:
> >
> >  Host
> > Loss%   Snt   Last   Avg  Best  Wrst StDev
> >  1.
> > 2001:1970:5261:d600::1  0.0%
> >   72.1   1.3   0.7   2.9   0.8
> >  2.
> > 2001:1970:4000:82::10.0%
> >   7   10.0  14.0   8.3  37.9  10.6
> >  3.
> > 2001:1970:0:1a6::1 16.7%
> >   7   13.2 215.5  10.8 1031. 455.9
> >  4.
> > he.ip6.torontointernetxchange.net   0.0%
> >   7   12.3  12.9  11.2  15.3   1.6
> >  5.
> > 100ge9-2.core2.chi1.he.net  0.0%
> >   7   23.6  23.0  21.3  27.6   2.2
> >  6.
> > 100ge15-2.core1.chi1.he.net 0.0%
> >   7   21.7  22.5  21.6  24.9   1.2
> >  7.
> > 100ge12-1.core1.atl1.he.net 0.0%
> >   7   34.2  35.1  34.1  36.1   0.7
> >  8.
> > 100ge5-1.core1.tpa1.he.net  0.0%
> >   7   49.1  46.6  44.8  49.1   1.5
> >  9.
> > 100ge12-1.core1.mia1.he.net 0.0%
> >   7   51.6  54.5  50.5  73.3   8.3
> > 10. ???
> >
> > But I think it getting that far time was an anomaly and frankly it
> > usually dies even before exiting my ISP's (Cogeco) network like 
> this:
> >
> >  Host
> > Loss%   Snt   Last   Avg  Best  Wrst StDev
> >  1.
> > 2001:1970:5261:d600::1   0.0%
> >   330.6   0.7   0.6   1.0   0.1
> >  2.
> > 2001:1970:4000:82::1 0.0%
> >   338.2  10.8   8.1  40.5   5.6
> >  3.
> > 2001:1970:0:1a7::1  15.2%
> >   33   23.4  20.1  16.5  23.4   1.5
> >  4.
> > 2001:1970:0:61::1   33.3%
> >   33   16.8  17.6  14.5  25.9   2.5
> >  5.
> > 2001:1978:1300::10.0%
> >   33   16.0  17.5  14.2  29.6   3.1
> >  6.
> > 2001:1978:203::450.0%
> >   33   30.7  30.7  28.4  35.1   1.7
> >  7. ???
> >
> > When I asked the kind folks at he.net for some advice about the 
> problem
> > (i.e. in the first traceroute above) their diagnosis was that
> > Facebook's IPv6 router(s) likely didn't have a route back to my 
> Cogeco
> > IPv6 address.
> >
> > Trying to talk to my ISP (again, Cogeco) has been impossible.  One
> > simply cannot reach the people who know more than how to reset your
> > router and configure your e-mail.
> >
> > I wonder how I could go any further with this to confirm the 
> diagnosis
> > that Facebook doesn't have a route to the Cogeco network's IPv6 
> address
> > space given that I only have access to my end of the path.
> >
> 

Re: Auto-reply from Yahoo...

[Grant Taylor via NANOG]

On 12/20/2018 12:10 PM, M. Ömer GÖLGELİ wrote:

Here, I have added the admins to this mail to let them know what bugs us...


Okay (See below.)

Maybe there should be a reporting address listed on NANOG page just for 
this purposes.


I would have thought (read: expected) that the nanog-ow...@nanog.com 
email address would have gone to the list owners.


I agree that there should be an easy way to contact list owners.  Hence 
the standard convention of $LIST-owner address / alias.


I don't know.  Maybe something got broken during an upgrade.  I'll stop 
harping.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Job Snijders]

At this moment it appears there are multiple rifts in the IPv6 default-free
zone (that don’t exist in the IPv4 realm), between various organizations.
Focusing on one particular partitioning may not help address the other
issues.

Kind regards,

Job

Re: Auto-reply from Yahoo...

[M . Ömer GÖLGELİ]

Here, I have added the admins to this mail to let them know what bugs us... And sure with each response I do too get an email like the one attached screenshot. Yeah, these are notes bounces but one of the auto responders which is hard to track. Maybe there should be a reporting address listed on NANOG page just for this purposes. M. ---On 20 Dec 2018 21:00, Grant Taylor via NANOG  wrote:On 12/20/2018 10:17 AM, M. Ömer GÖLGELİ wrote:

> This can happen for many reasons.

> Quitting employees, dropping domains, death whatever.



Yep.  I get it.



> They should be *somehow* auto removed after a certain number of bounces.



The catch is, they aren't /bounces/.  They are auto-responses to the 

sender of the email.  Meaning I'll get one to me for this reply.  You 

very likely got one to you for the message that I'm replying to.



Delivery to the problematic recipient is very likely succeeding at an 

SMTP level.



So, the mailing list manager doesn't see them and has no opportunity to 

do anything about them.







-- 

Grant. . . .

unix || die

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[David Hubbard]

Yikes, they should change their name rather than be mistaken for Cogent lol

On 12/20/18, 2:04 PM, "Clayton Zekelman"  wrote:


Cogent != Cogeco

Cogent - US Backbone Provider
Cogeco - Canadian Cable TV & Internet provider

At 01:00 PM 20/12/2018, David Hubbard wrote:
>Google and HE don't have IPv6 connectivity with 
>Cogent because Cogent's CEO has been in some 
>decades long pissing match with them about free 
>settlement free peering.  That's the unfortunate 
>reality of the situation; nothing you can do 
>other than have another route to HE/Google IPv6 
>targets.  We have some Cogent circuits that are 
>effectively useless for IPv6 as our customer 
>base has heavy traffic to/from Google cloud 
>services, so they can't be used for a backup / 
>DR scenario; their only real value is an optimal 
>route to other Cogent customers.  I'm slowly 
>replacing our Cogent circuits when feasible 
>because the reality is our customers reaching 
>Google over IPv6 via all our upstreams is more 
>valuable than Cogent's cost savings.
>
>
>
>On 12/20/18, 12:37 PM, "NANOG on behalf of 
>Brian J. Murrell" behalf of br...@interlinx.bc.ca> wrote:
>
> I've been trying to figure out why I can reach an IPv6 address at
> Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two
> Internet connections as well as via an HE IPv6 tunnel but not the 
other
> of my two ISP connections
>
> At one point in time a traceroute was dying inside of he.net:
>
>  Host 
> Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. 
> 2001:1970:5261:d600::1  0.0% 
>   72.1   1.3   0.7   2.9   0.8
>  2. 
> 2001:1970:4000:82::10.0% 
>   7   10.0  14.0   8.3  37.9  10.6
>  3. 
> 2001:1970:0:1a6::1 16.7% 
>   7   13.2 215.5  10.8 1031. 455.9
>  4. 
> he.ip6.torontointernetxchange.net   0.0% 
>   7   12.3  12.9  11.2  15.3   1.6
>  5. 
> 100ge9-2.core2.chi1.he.net  0.0% 
>   7   23.6  23.0  21.3  27.6   2.2
>  6. 
> 100ge15-2.core1.chi1.he.net 0.0% 
>   7   21.7  22.5  21.6  24.9   1.2
>  7. 
> 100ge12-1.core1.atl1.he.net 0.0% 
>   7   34.2  35.1  34.1  36.1   0.7
>  8. 
> 100ge5-1.core1.tpa1.he.net  0.0% 
>   7   49.1  46.6  44.8  49.1   1.5
>  9. 
> 100ge12-1.core1.mia1.he.net 0.0% 
>   7   51.6  54.5  50.5  73.3   8.3
> 10. ???
>
> But I think it getting that far time was an anomaly and frankly it
> usually dies even before exiting my ISP's (Cogeco) network like this:
>
>  Host 
> Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. 
> 2001:1970:5261:d600::1   0.0% 
>   330.6   0.7   0.6   1.0   0.1
>  2. 
> 2001:1970:4000:82::1 0.0% 
>   338.2  10.8   8.1  40.5   5.6
>  3. 
> 2001:1970:0:1a7::1  15.2% 
>   33   23.4  20.1  16.5  23.4   1.5
>  4. 
> 2001:1970:0:61::1   33.3% 
>   33   16.8  17.6  14.5  25.9   2.5
>  5. 
> 2001:1978:1300::10.0% 
>   33   16.0  17.5  14.2  29.6   3.1
>  6. 
> 2001:1978:203::450.0% 
>   33   30.7  30.7  28.4  35.1   1.7
>  7. ???
>
> When I asked the kind folks at he.net for some advice about the 
problem
> (i.e. in the first traceroute above) their diagnosis was that
> Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco
> IPv6 address.
>
> Trying to talk to my ISP (again, Cogeco) has been impossible.  One
> simply cannot reach the people who know more than how to reset your
> router and configure your e-mail.
>
> I wonder how I could go any further with this to confirm the diagnosis
> that Facebook doesn't have a route to the Cogeco network's IPv6 
address
> space given that I only have access to my end of the path.
>
> Cheers,
> b.
>
>

-- 

Clayton Zekelman
Managed Network Systems Inc. (MNSi)
3363 Tecumseh Rd. E
Windsor, Ontario
N8W 1H4

tel. 519-985-8410
fax. 519-985-8409

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Clayton Zekelman]

Cogent != Cogeco

Cogent - US Backbone Provider
Cogeco - Canadian Cable TV & Internet provider

At 01:00 PM 20/12/2018, David Hubbard wrote:
Google and HE don't have IPv6 connectivity with 
Cogent because Cogent's CEO has been in some 
decades long pissing match with them about free 
settlement free peering.  That's the unfortunate 
reality of the situation; nothing you can do 
other than have another route to HE/Google IPv6 
targets.  We have some Cogent circuits that are 
effectively useless for IPv6 as our customer 
base has heavy traffic to/from Google cloud 
services, so they can't be used for a backup / 
DR scenario; their only real value is an optimal 
route to other Cogent customers.  I'm slowly 
replacing our Cogent circuits when feasible 
because the reality is our customers reaching 
Google over IPv6 via all our upstreams is more 
valuable than Cogent's cost savings.




On 12/20/18, 12:37 PM, "NANOG on behalf of 
Brian J. Murrell" behalf of br...@interlinx.bc.ca> wrote:


I've been trying to figure out why I can reach an IPv6 address at
Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two
Internet connections as well as via an HE IPv6 tunnel but not the other
of my two ISP connections

At one point in time a traceroute was dying inside of he.net:

 Host 
Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 
2001:1970:5261:d600::1  0.0% 
  72.1   1.3   0.7   2.9   0.8
 2. 
2001:1970:4000:82::10.0% 
  7   10.0  14.0   8.3  37.9  10.6
 3. 
2001:1970:0:1a6::1 16.7% 
  7   13.2 215.5  10.8 1031. 455.9
 4. 
he.ip6.torontointernetxchange.net   0.0% 
  7   12.3  12.9  11.2  15.3   1.6
 5. 
100ge9-2.core2.chi1.he.net  0.0% 
  7   23.6  23.0  21.3  27.6   2.2
 6. 
100ge15-2.core1.chi1.he.net 0.0% 
  7   21.7  22.5  21.6  24.9   1.2
 7. 
100ge12-1.core1.atl1.he.net 0.0% 
  7   34.2  35.1  34.1  36.1   0.7
 8. 
100ge5-1.core1.tpa1.he.net  0.0% 
  7   49.1  46.6  44.8  49.1   1.5
 9. 
100ge12-1.core1.mia1.he.net 0.0% 
  7   51.6  54.5  50.5  73.3   8.3

10. ???

But I think it getting that far time was an anomaly and frankly it
usually dies even before exiting my ISP's (Cogeco) network like this:

 Host 
Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 
2001:1970:5261:d600::1   0.0% 
  330.6   0.7   0.6   1.0   0.1
 2. 
2001:1970:4000:82::1 0.0% 
  338.2  10.8   8.1  40.5   5.6
 3. 
2001:1970:0:1a7::1  15.2% 
  33   23.4  20.1  16.5  23.4   1.5
 4. 
2001:1970:0:61::1   33.3% 
  33   16.8  17.6  14.5  25.9   2.5
 5. 
2001:1978:1300::10.0% 
  33   16.0  17.5  14.2  29.6   3.1
 6. 
2001:1978:203::450.0% 
  33   30.7  30.7  28.4  35.1   1.7

 7. ???

When I asked the kind folks at he.net for some advice about the problem
(i.e. in the first traceroute above) their diagnosis was that
Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco
IPv6 address.

Trying to talk to my ISP (again, Cogeco) has been impossible.  One
simply cannot reach the people who know more than how to reset your
router and configure your e-mail.

I wonder how I could go any further with this to confirm the diagnosis
that Facebook doesn't have a route to the Cogeco network's IPv6 address
space given that I only have access to my end of the path.

Cheers,
b.




--

Clayton Zekelman
Managed Network Systems Inc. (MNSi)
3363 Tecumseh Rd. E
Windsor, Ontario
N8W 1H4

tel. 519-985-8410
fax. 519-985-8409

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Matthew Kaufman]

In other words, they’re on The Internet and you (and your transit provider)
are not.
On Thu, Dec 20, 2018 at 10:40 AM David Hubbard <
dhubb...@dino.hostasaurus.com> wrote:

> Google and HE don't have IPv6 connectivity with Cogent because Cogent's
> CEO has been in some decades long pissing match with them about free
> settlement free peering.  That's the unfortunate reality of the situation;
> nothing you can do other than have another route to HE/Google IPv6
> targets.  We have some Cogent circuits that are effectively useless for
> IPv6 as our customer base has heavy traffic to/from Google cloud services,
> so they can't be used for a backup / DR scenario; their only real value is
> an optimal route to other Cogent customers.  I'm slowly replacing our
> Cogent circuits when feasible because the reality is our customers reaching
> Google over IPv6 via all our upstreams is more valuable than Cogent's cost
> savings.
>
>
>
> On 12/20/18, 12:37 PM, "NANOG on behalf of Brian J. Murrell" <
> nanog-boun...@nanog.org on behalf of br...@interlinx.bc.ca> wrote:
>
> I've been trying to figure out why I can reach an IPv6 address at
> Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two
> Internet connections as well as via an HE IPv6 tunnel but not the other
> of my two ISP connections
>
> At one point in time a traceroute was dying inside of he.net:
>
>  Host  Loss%   Snt   Last   Avg
> Best  Wrst StDev
>  1. 2001:1970:5261:d600::1  0.0% 72.1   1.3
>  0.7   2.9   0.8
>  2. 2001:1970:4000:82::10.0% 7   10.0  14.0
>  8.3  37.9  10.6
>  3. 2001:1970:0:1a6::1 16.7% 7   13.2 215.5
> 10.8 1031. 455.9
>  4. he.ip6.torontointernetxchange.net   0.0% 7   12.3  12.9
> 11.2  15.3   1.6
>  5. 100ge9-2.core2.chi1.he.net  0.0% 7   23.6  23.0
> 21.3  27.6   2.2
>  6. 100ge15-2.core1.chi1.he.net 0.0% 7   21.7  22.5
> 21.6  24.9   1.2
>  7. 100ge12-1.core1.atl1.he.net 0.0% 7   34.2  35.1
> 34.1  36.1   0.7
>  8. 100ge5-1.core1.tpa1.he.net  0.0% 7   49.1  46.6
> 44.8  49.1   1.5
>  9. 100ge12-1.core1.mia1.he.net 0.0% 7   51.6  54.5
> 50.5  73.3   8.3
> 10. ???
>
> But I think it getting that far time was an anomaly and frankly it
> usually dies even before exiting my ISP's (Cogeco) network like this:
>
>  Host   Loss%   Snt   Last   Avg
> Best  Wrst StDev
>  1. 2001:1970:5261:d600::1   0.0%330.6   0.7
>  0.6   1.0   0.1
>  2. 2001:1970:4000:82::1 0.0%338.2  10.8
>  8.1  40.5   5.6
>  3. 2001:1970:0:1a7::1  15.2%33   23.4  20.1
> 16.5  23.4   1.5
>  4. 2001:1970:0:61::1   33.3%33   16.8  17.6
> 14.5  25.9   2.5
>  5. 2001:1978:1300::10.0%33   16.0  17.5
> 14.2  29.6   3.1
>  6. 2001:1978:203::450.0%33   30.7  30.7
> 28.4  35.1   1.7
>  7. ???
>
> When I asked the kind folks at he.net for some advice about the
> problem
> (i.e. in the first traceroute above) their diagnosis was that
> Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco
> IPv6 address.
>
> Trying to talk to my ISP (again, Cogeco) has been impossible.  One
> simply cannot reach the people who know more than how to reset your
> router and configure your e-mail.
>
> I wonder how I could go any further with this to confirm the diagnosis
> that Facebook doesn't have a route to the Cogeco network's IPv6 address
> space given that I only have access to my end of the path.
>
> Cheers,
> b.
>
>
>
>

Re: Stupid Question maybe?

[Grant Taylor via NANOG]

On 12/20/2018 10:55 AM, Saku Ytti wrote:

Correct.


Do you have /24 cover prefixes advertised to the Internet?

What is that use-case? Do notice that I propose opt-in static host/32 
route pointing to the link, giving far-end INET reachability, if they 
so want, without adding attack surface on the near-end.


$EMPLOYER requires globally routable access to the link net IP on our 
equipment for specific configurations.  Sorry, I can't go into details.


I'm trying to ascertain if the configuration (as I understand it) that 
advocating for would work for us or not.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Mike Hammett]

Cogent != Cogeco 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "David Guo via NANOG"  
To: "Brian J. Murrell" , nanog@nanog.org 
Sent: Thursday, December 20, 2018 11:39:00 AM 
Subject: RE: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? 

It's problem from Cogentco, they do not have IPv6 peer with HE.net and Google 

-Original Message- 
From: NANOG  On Behalf Of Brian J. Murrell 
Sent: Tuesday, December 18, 2018 4:02 AM 
To: nanog@nanog.org 
Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space? 

I've been trying to figure out why I can reach an IPv6 address at Facebook 
(2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two Internet 
connections as well as via an HE IPv6 tunnel but not the other of my two ISP 
connections 

At one point in time a traceroute was dying inside of he.net: 

Host Loss% Snt Last Avg Best Wrst StDev 
1. 2001:1970:5261:d600::1 0.0% 7 2.1 1.3 0.7 2.9 0.8 
2. 2001:1970:4000:82::1 0.0% 7 10.0 14.0 8.3 37.9 10.6 
3. 2001:1970:0:1a6::1 16.7% 7 13.2 215.5 10.8 1031. 455.9 
4. he.ip6.torontointernetxchange.net 0.0% 7 12.3 12.9 11.2 15.3 1.6 
5. 100ge9-2.core2.chi1.he.net 0.0% 7 23.6 23.0 21.3 27.6 2.2 
6. 100ge15-2.core1.chi1.he.net 0.0% 7 21.7 22.5 21.6 24.9 1.2 
7. 100ge12-1.core1.atl1.he.net 0.0% 7 34.2 35.1 34.1 36.1 0.7 
8. 100ge5-1.core1.tpa1.he.net 0.0% 7 49.1 46.6 44.8 49.1 1.5 
9. 100ge12-1.core1.mia1.he.net 0.0% 7 51.6 54.5 50.5 73.3 8.3 
10. ??? 

But I think it getting that far time was an anomaly and frankly it usually dies 
even before exiting my ISP's (Cogeco) network like this: 

Host Loss% Snt Last Avg Best Wrst StDev 
1. 2001:1970:5261:d600::1 0.0% 33 0.6 0.7 0.6 1.0 0.1 
2. 2001:1970:4000:82::1 0.0% 33 8.2 10.8 8.1 40.5 5.6 
3. 2001:1970:0:1a7::1 15.2% 33 23.4 20.1 16.5 23.4 1.5 
4. 2001:1970:0:61::1 33.3% 33 16.8 17.6 14.5 25.9 2.5 
5. 2001:1978:1300::1 0.0% 33 16.0 17.5 14.2 29.6 3.1 
6. 2001:1978:203::45 0.0% 33 30.7 30.7 28.4 35.1 1.7 
7. ??? 

When I asked the kind folks at he.net for some advice about the problem (i.e. 
in the first traceroute above) their diagnosis was that Facebook's IPv6 
router(s) likely didn't have a route back to my Cogeco 
IPv6 address. 

Trying to talk to my ISP (again, Cogeco) has been impossible. One simply cannot 
reach the people who know more than how to reset your router and configure your 
e-mail. 

I wonder how I could go any further with this to confirm the diagnosis that 
Facebook doesn't have a route to the Cogeco network's IPv6 address space given 
that I only have access to my end of the path. 

Cheers, 
b. 

Re: Stupid Question maybe?

[Saku Ytti]

On Thu, 20 Dec 2018 at 20:07, William Allen Simpson
 wrote:

> Then there were the fine vendors that conflated the link and IP headers.
> That fell apart when IEEE started assigning OUIs that began with 0x4xxx.

There is no way to know in-transit what MPLS carries. Vendors have
implemented heuristics of different complexities to try to guess what
is being carried in effort to enable services like ECMP and netflow.
In hindsight MPLS ethertype probably should tell what it carries
MPLS-IP, MPLS-ETH, MPLS-OTHER.
This is on-going problem with no obvious solution, the ECMP issue can
be largely handled by disabling payload guessing and relying on having
sufficient flow entropy in labels. But the services such as netflow
still need transit guessing.

-- 
  ++ytti

Re: Announcing Peering-LAN prefixes to customers

[Dominic Schallert]

Dear Job, Michael, Ross,
thank you very much for sharing your opinion, the detailed info and references. 
That’s pretty much what I excpected.
Just wondered because I couldn’t find any IXP Conection Agreement stating this 
„issue“ explicitly yet.

Maybe MANRS IXP actions has some recommendations regarding this, checking that 
now.

Best wishes and happy holidays

Cheers
Dominic


> Am 20.12.2018 um 19:06 schrieb Michael Still :
> 
> IXP LANs should not be announced via BGP (or your IGP either). See section 
> 3.1:
> http://nabcop.org/index.php/BCOP-Exchange_Points_v2 
> 
> 
> 
> 
> On Thu, Dec 20, 2018 at 12:50 PM Dominic Schallert  > wrote:
> Hi all,
> 
> this might be a stupid question but today I was discussing with a colleague 
> if Peering-LAN prefixes should be re-distributed/announced to direct 
> customers/peers. My standpoint is that in any case, Peering-LAN prefixes 
> should be filtered and not announced to peers/customers because a Peering-LAN 
> represents some sort of DMZ and there is simply no need for them to be 
> reachable by third-parties not being physically connected to an IXP 
> themselves. Also from a security point of view, a lot of new issues might 
> occur in this situation.
> 
> I’ve been seeing a few transit providers lately announcing (even reachable) 
> Peering-LAN prefixes (for example DE-CIX Peering LAN) to their customers. I’m 
> wondering if there is any document or RFC particularly describing this matter?
> 
> Thanks
> Dominic
> 
> 
> --
> [stillwa...@gmail.com  ~]$ cat .signature
> cat: .signature: No such file or directory
> [stillwa...@gmail.com  ~]$



signature.asc
Description: Message signed with OpenPGP

Re: godaddy contacts

[Anne P. Mitchell, Esq.]

> Is anyone from godaddy in this list? We believe they are announcing our BGP 
> pool. The IP in 17th hop IP pool is ours as a result some of our customers 
> are not able to login to godaddy.
>  
> C:\Users\DP>tracert sso.godaddy.com
>  
> Tracing route to sso.godaddy.com [104.238.65.153]
> over a maximum of 30 hops:
>  
>   1 2 ms 1 ms 3 ms  192.168.225.1
>   2 4 ms 2 ms 2 ms  10.24.0.1
>   3 4 ms 2 ms 3 ms  103.40.48.13
>   4 4 ms 2 ms 2 ms  vbc-10g-ccr.vbctv.in [123.108.200.5]
>   5 4 ms 2 ms 2 ms  vbc-10g-asr.vbctv.in [123.108.200.42]
>   6 5 ms 2 ms 2 ms  14.142.71.141.static-hydrabad.vsnl.net.in 
> [14.142.71.141]
>   726 ms32 ms27 ms  172.25.81.134
>   846 ms33 ms35 ms  ix-ae-0-4.tcore1.mlv-mumbai.as6453.net 
> [180.87.38.5]
>   9   150 ms   148 ms   147 ms  if-ae-5-2.tcore1.wyn-marseille.as6453.net 
> [180.87.38.126]
> 10   147 ms   147 ms   146 ms  if-ae-8-1600.tcore1.pye-paris.as6453.net 
> [80.231.217.6]
> 11   147 ms   145 ms   145 ms  if-ae-11-2.tcore1.pvu-paris.as6453.net 
> [80.231.153.49]
> 12 **  143 ms  80.231.153.66
> 13 *  318 ms * ae-1-11.bear1.Phoenix1.Level3.net 
> [4.69.210.157]
> 14   274 ms   337 ms   305 ms  THE-GO-DADD.bear1.Phoenix1.Level3.net 
> [4.16.142.186]
> 15   329 ms   278 ms   340 ms  ip-148-72-32-9.ip.secureserver.net 
> [148.72.32.9]
> 16   269 ms   282 ms   315 ms  ip-184-168-0-117.ip.secureserver.net 
> [184.168.0.117]
> 17   333 ms   289 ms   288 ms  125.62.192.197
> 18 *** Request timed out.
> 19 *** Request timed out.
> 20 *** Request timed out.
> 21 *** Request timed out.
> 22 *** Request timed out.
> 23 *** Request timed out.
> 24   291 ms   275 ms   273 ms  ip-104-238-65-153.ip.secureserver.net 
> [104.238.65.153]
>  
> Trace complete.
>  

Hi Durga - we can get this in front of the right person - may I have permission 
to forward this to GoDaddy?

Anne

---

Anne P. Mitchell, 
Attorney at Law
GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Legislative Consultant
CEO/President, Institute for Social Internet Public Policy
Board of Directors, Denver Internet Exchange
Board of Directors, Asilomar Microcomputer Workshop
Legal Counsel: The CyberGreen Institute
Legal Counsel: The Earth Law Center
California Bar Association
Cal. Bar Cyberspace Law Committee
Colorado Cyber Committee
Ret. Professor of Law, Lincoln Law School of San Jose
Ret. Chair, Asilomar Microcomputer Workshop

Re: Announcing Peering-LAN prefixes to customers

[Michael Still]

IXP LANs should not be announced via BGP (or your IGP either). See section
3.1:
http://nabcop.org/index.php/BCOP-Exchange_Points_v2



On Thu, Dec 20, 2018 at 12:50 PM Dominic Schallert  wrote:

> Hi all,
>
> this might be a stupid question but today I was discussing with a
> colleague if Peering-LAN prefixes should be re-distributed/announced to
> direct customers/peers. My standpoint is that in any case, Peering-LAN
> prefixes should be filtered and not announced to peers/customers because a
> Peering-LAN represents some sort of DMZ and there is simply no need for
> them to be reachable by third-parties not being physically connected to an
> IXP themselves. Also from a security point of view, a lot of new issues
> might occur in this situation.
>
> I’ve been seeing a few transit providers lately announcing (even
> reachable) Peering-LAN prefixes (for example DE-CIX Peering LAN) to their
> customers. I’m wondering if there is any document or RFC particularly
> describing this matter?
>
> Thanks
> Dominic
>


-- 
[stillwa...@gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwa...@gmail.com ~]$

Re: Auto-reply from Yahoo...

[Grant Taylor via NANOG]

On 12/20/2018 10:17 AM, M. Ömer GÖLGELİ wrote:

This can happen for many reasons.
Quitting employees, dropping domains, death whatever.


Yep.  I get it.


They should be *somehow* auto removed after a certain number of bounces.


The catch is, they aren't /bounces/.  They are auto-responses to the 
sender of the email.  Meaning I'll get one to me for this reply.  You 
very likely got one to you for the message that I'm replying to.


Delivery to the problematic recipient is very likely succeeding at an 
SMTP level.


So, the mailing list manager doesn't see them and has no opportunity to 
do anything about them.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[nop]

Cogeco is not related to Cogent

On Thu, Dec 20, 2018, at 0:0.366 AM, David Guo via NANOG写:
> It's problem from Cogentco, they do not have IPv6 peer with HE.net and Google

Re: Announcing Peering-LAN prefixes to customers

[Ross Tajvar]

This brings to mind the following (old) blog post from CloudFlare:
https://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet/
Relevant excerpt here:

> Beyond attacking CloudFlare's direct peers, the attackers also attacked
> the core IX infrastructure on the London Internet Exchange (LINX), the
> Amsterdam Internet Exchange (AMS-IX), the Frankfurt Internet Exchange
> (DE-CIX), and the Hong Kong Internet Exchange (HKIX). From our perspective,
> the attacks had the largest effect on LINX which caused impact over the
> exchange and LINX's systems that monitor the exchange, as visible through
> the drop in traffic recorded by their monitoring systems. (Corrected: see
> below for original phrasing.)
> The congestion impacted many of the networks on the IXs, including
> CloudFlare's. As problems were detected on the IX, we would route traffic
> around them. However, several London-based CloudFlare users reported
> intermittent issues over the last several days. This is the root cause of
> those problems.
> The attacks also exposed some vulnerabilities in the architecture of some
> IXs. We, along with many other network security experts, worked with the
> team at LINX to better secure themselves. In doing so, we developed a list
> of best practices for any IX in order to make them less vulnerable to
> attacks.
> Two specific suggestions to limit attacks like this involve making it more
> difficult to attack the IP addresses that members of the IX use to
> interchange traffic between each other. We are working with IXs to ensure
> that: 1) these IP addresses should not be announced as routable across the
> public Internet; and 2) packets destined to these IP addresses should only
> be permitted from other IX IP addresses. We've been very impressed with the
> team at LINX and how quickly they've worked to implement these changes and
> add additional security to their IX and are hopeful other IXs will quickly
> follow their lead.


On Thu, Dec 20, 2018 at 12:51 PM Dominic Schallert  wrote:

> Hi all,
>
> this might be a stupid question but today I was discussing with a
> colleague if Peering-LAN prefixes should be re-distributed/announced to
> direct customers/peers. My standpoint is that in any case, Peering-LAN
> prefixes should be filtered and not announced to peers/customers because a
> Peering-LAN represents some sort of DMZ and there is simply no need for
> them to be reachable by third-parties not being physically connected to an
> IXP themselves. Also from a security point of view, a lot of new issues
> might occur in this situation.
>
> I’ve been seeing a few transit providers lately announcing (even
> reachable) Peering-LAN prefixes (for example DE-CIX Peering LAN) to their
> customers. I’m wondering if there is any document or RFC particularly
> describing this matter?
>
> Thanks
> Dominic
>

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[David Hubbard]

Google and HE don't have IPv6 connectivity with Cogent because Cogent's CEO has 
been in some decades long pissing match with them about free settlement free 
peering.  That's the unfortunate reality of the situation; nothing you can do 
other than have another route to HE/Google IPv6 targets.  We have some Cogent 
circuits that are effectively useless for IPv6 as our customer base has heavy 
traffic to/from Google cloud services, so they can't be used for a backup / DR 
scenario; their only real value is an optimal route to other Cogent customers.  
I'm slowly replacing our Cogent circuits when feasible because the reality is 
our customers reaching Google over IPv6 via all our upstreams is more valuable 
than Cogent's cost savings.

 

On 12/20/18, 12:37 PM, "NANOG on behalf of Brian J. Murrell" 
 wrote:

I've been trying to figure out why I can reach an IPv6 address at
Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two
Internet connections as well as via an HE IPv6 tunnel but not the other
of my two ISP connections

At one point in time a traceroute was dying inside of he.net:

 Host  Loss%   Snt   Last   Avg  Best  
Wrst StDev
 1. 2001:1970:5261:d600::1  0.0% 72.1   1.3   0.7   
2.9   0.8
 2. 2001:1970:4000:82::10.0% 7   10.0  14.0   8.3  
37.9  10.6
 3. 2001:1970:0:1a6::1 16.7% 7   13.2 215.5  10.8 
1031. 455.9
 4. he.ip6.torontointernetxchange.net   0.0% 7   12.3  12.9  11.2  
15.3   1.6
 5. 100ge9-2.core2.chi1.he.net  0.0% 7   23.6  23.0  21.3  
27.6   2.2
 6. 100ge15-2.core1.chi1.he.net 0.0% 7   21.7  22.5  21.6  
24.9   1.2
 7. 100ge12-1.core1.atl1.he.net 0.0% 7   34.2  35.1  34.1  
36.1   0.7
 8. 100ge5-1.core1.tpa1.he.net  0.0% 7   49.1  46.6  44.8  
49.1   1.5
 9. 100ge12-1.core1.mia1.he.net 0.0% 7   51.6  54.5  50.5  
73.3   8.3
10. ???

But I think it getting that far time was an anomaly and frankly it
usually dies even before exiting my ISP's (Cogeco) network like this:

 Host   Loss%   Snt   Last   Avg  Best  
Wrst StDev
 1. 2001:1970:5261:d600::1   0.0%330.6   0.7   0.6  
 1.0   0.1
 2. 2001:1970:4000:82::1 0.0%338.2  10.8   8.1  
40.5   5.6
 3. 2001:1970:0:1a7::1  15.2%33   23.4  20.1  16.5  
23.4   1.5
 4. 2001:1970:0:61::1   33.3%33   16.8  17.6  14.5  
25.9   2.5
 5. 2001:1978:1300::10.0%33   16.0  17.5  14.2  
29.6   3.1
 6. 2001:1978:203::450.0%33   30.7  30.7  28.4  
35.1   1.7
 7. ???

When I asked the kind folks at he.net for some advice about the problem
(i.e. in the first traceroute above) their diagnosis was that
Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco
IPv6 address.

Trying to talk to my ISP (again, Cogeco) has been impossible.  One
simply cannot reach the people who know more than how to reset your
router and configure your e-mail.

I wonder how I could go any further with this to confirm the diagnosis
that Facebook doesn't have a route to the Cogeco network's IPv6 address
space given that I only have access to my end of the path.

Cheers,
b.

Re: Stupid Question maybe?

[Saku Ytti]

On Thu, 20 Dec 2018 at 18:22, Grant Taylor via NANOG  wrote:

> Are you advocating not advertising customer linknetworks within your own
> organization?

Correct.

> I know of a use cases where linknetworks must be globally accessible.
> At least the customer's linknetwork IP address.  So, not advertising
> them (or at least an aggregate for them) would be problematic.

What is that use-case? Do notice that I propose opt-in static host/32
route pointing to the link, giving far-end INET reachability, if they
so want, without adding attack surface on the near-end.

-- 
  ++ytti

Re: Announcing Peering-LAN prefixes to customers

[Job Snijders]

Dear Dominic,

On Thu, Dec 20, 2018 at 6:49 PM Dominic Schallert  wrote:
> this might be a stupid question but today I was discussing with a colleague 
> if Peering-LAN prefixes should be re-distributed/announced to direct 
> customers/peers. My standpoint is that in any case, Peering-LAN prefixes 
> should be filtered and not announced to peers/customers because a Peering-LAN 
> represents some sort of DMZ and there is simply no need for them to be 
> reachable by third-parties not being physically connected to an IXP 
> themselves. Also from a security point of view, a lot of new issues might 
> occur in this situation.
>
> I’ve been seeing a few transit providers lately announcing (even reachable) 
> Peering-LAN prefixes (for example DE-CIX Peering LAN) to their customers. I’m 
> wondering if there is any document or RFC particularly describing this matter?

It is NTT's policy to reject Peering LAN prefixes (and any
more-specifics) of any IXPs NTT is connected; on both our ingress EBGP
and egress EBGP policies.

We don't see a need for NTT to attempt to make such peering lan
networks reachable for third parties. Such reachability may negatively
impact operations, especially when more-specifics of Peering LAN
prefixes are distributed through the default-free zone.

As a consequence, for IXPs this policy suggests that it is a necessity
to host their own infrastructure (IXP website, mail server, etc)
outside the peering lan prefix.

Kind regards,

Job

Re: Auto-reply from Yahoo...

[Bryce Wilson]

I’m glad that the bounces are not sent to the list, but that means that the 
list does not know about them and therefore can’t do anything automatically. 
There is little we can do other than block the email individually until the 
list owners or Yahoo themselves manage to remove them.

This should be a lesson to those running email auto-reply systems to set up 
some way to have them not make these auto-replies to mailing lists which should 
not be too hard to automate.

Thanks ~ Bryce Wilson, AS202313, EVIX AS137933

> On Dec 20, 2018, at 9:17 AM, M. Ömer GÖLGELİ  wrote:
> 
> This can happen for many reasons. 
> Quitting employees, dropping domains, death whatever. 
> 
> They should be *somehow* auto removed after a certain number of bounces. 
> 
> 
> 
> M. 
> ---
> 
> 
> 
> On 20 Dec 2018 19:46, Grant Taylor via NANOG  wrote:
> On 12/14/2018 11:48 AM, Grant Taylor wrote: 
> > I've been seeing them for three or four days now. 
> 
> BUMP 
> 
> This has been going on for more than a week now.  I'm quite confident 
> that there have been hundreds of auto-replies.  (I'm seeing 285 incoming 
> message from the NANOG mailing list since I became aware of the auto-reply.) 
> 
> I'm really surprised that there has not been any reply or action by the 
> NANOG list owner(s).  I would have hoped, if not expected, better, or 
> any, response by now. 
> 
> 
> 
> -- 
> Grant. . . . 
> unix || die 
> 
> 
> 

Re: BGP Experiment

[Job Snijders]

Dear Italo,

Thanks for giving the community a heads-up on your plan! I think your
announcement like these are the best anyone can do when trying legal
but new BGP path attributes.

I'll forward this message to other NOGs and make sure that our NOC
adds it to their calendar.

Kind regards,

Job

On Thu, Dec 20, 2018 at 6:39 PM Italo Cunha  wrote:
>
> NANOG,
>
> We would like to inform you of an experiment to evaluate alternatives
> for speeding up adoption of BGP route origin validation (research
> paper with details [A]).
>
> Our plan is to announce prefix 184.164.224.0/24 with a valid
> standards-compliant unassigned BGP attribute from routers operated by
> the PEERING testbed [B, C]. The attribute will have flags 0xe0
> (optional transitive [rfc4271, S4.3]), type 0xff (reserved for
> development), and size 0x20 (256bits).
>
> Our collaborators recently ran an equivalent experiment with no
> complaints or known issues [A], and so we do not anticipate any
> arising. Back in 2010, an experiment using unassigned attributes by
> RIPE and Duke University caused disruption in Internet routing due to
> a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other
> similar bugs have been patched [e.g., CVE-2013-6051], and new BGP
> attributes have been assigned (BGPsec-path) and adopted (large
> communities). We have successfully tested propagation of the
> announcements on Cisco IOS-based routers running versions 12.2(33)SRA
> and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and
> 1.6.3.
>
> We plan to announce 184.164.224.0/24 from 8 PEERING locations for a
> predefined period of 15 minutes starting 14:30 GMT, from Monday to
> Thursday, between the 7th and 22nd of January, 2019 (full schedule and
> locations [E]). We will stop the experiment immediately in case any
> issues arise.
>
> Although we do not expect the experiment to cause disruption, we
> welcome feedback on its safety and especially on how to make it safer.
> We can be reached at disco-experim...@googlegroups.com.
>
> Amir Herzberg, University of Connecticut
> Ethan Katz-Bassett, Columbia University
> Haya Shulman, Fraunhofer SIT
> Ítalo Cunha, Universidade Federal de Minas Gerais
> Michael Schapira, Hebrew University of Jerusalem
> Tomas Hlavacek, Fraunhofer SIT
> Yossi Gilad, MIT
>
> [A] https://conferences.sigcomm.org/hotnets/2018/program.html
> [B] http://peering.usc.edu
> [C] https://goo.gl/AFR1Cn
> [D] 
> https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment
> [E] https://goo.gl/nJhmx1

RE: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[David Guo via NANOG]

It's problem from Cogentco, they do not have IPv6 peer with HE.net and Google

-Original Message-
From: NANOG  On Behalf Of Brian J. Murrell
Sent: Tuesday, December 18, 2018 4:02 AM
To: nanog@nanog.org
Subject: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

I've been trying to figure out why I can reach an IPv6 address at Facebook 
(2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two Internet 
connections as well as via an HE IPv6 tunnel but not the other of my two ISP 
connections

At one point in time a traceroute was dying inside of he.net:

 Host  Loss%   Snt   Last   Avg  Best  Wrst 
StDev
 1. 2001:1970:5261:d600::1  0.0% 72.1   1.3   0.7   2.9 
  0.8
 2. 2001:1970:4000:82::10.0% 7   10.0  14.0   8.3  37.9 
 10.6
 3. 2001:1970:0:1a6::1 16.7% 7   13.2 215.5  10.8 1031. 
455.9
 4. he.ip6.torontointernetxchange.net   0.0% 7   12.3  12.9  11.2  15.3 
  1.6
 5. 100ge9-2.core2.chi1.he.net  0.0% 7   23.6  23.0  21.3  27.6 
  2.2
 6. 100ge15-2.core1.chi1.he.net 0.0% 7   21.7  22.5  21.6  24.9 
  1.2
 7. 100ge12-1.core1.atl1.he.net 0.0% 7   34.2  35.1  34.1  36.1 
  0.7
 8. 100ge5-1.core1.tpa1.he.net  0.0% 7   49.1  46.6  44.8  49.1 
  1.5
 9. 100ge12-1.core1.mia1.he.net 0.0% 7   51.6  54.5  50.5  73.3 
  8.3
10. ???

But I think it getting that far time was an anomaly and frankly it usually dies 
even before exiting my ISP's (Cogeco) network like this:

 Host   Loss%   Snt   Last   Avg  Best  
Wrst StDev
 1. 2001:1970:5261:d600::1   0.0%330.6   0.7   0.6   
1.0   0.1
 2. 2001:1970:4000:82::1 0.0%338.2  10.8   8.1  
40.5   5.6
 3. 2001:1970:0:1a7::1  15.2%33   23.4  20.1  16.5  
23.4   1.5
 4. 2001:1970:0:61::1   33.3%33   16.8  17.6  14.5  
25.9   2.5
 5. 2001:1978:1300::10.0%33   16.0  17.5  14.2  
29.6   3.1
 6. 2001:1978:203::450.0%33   30.7  30.7  28.4  
35.1   1.7
 7. ???

When I asked the kind folks at he.net for some advice about the problem (i.e. 
in the first traceroute above) their diagnosis was that Facebook's IPv6 
router(s) likely didn't have a route back to my Cogeco
IPv6 address.

Trying to talk to my ISP (again, Cogeco) has been impossible.  One simply 
cannot reach the people who know more than how to reset your router and 
configure your e-mail.

I wonder how I could go any further with this to confirm the diagnosis that 
Facebook doesn't have a route to the Cogeco network's IPv6 address space given 
that I only have access to my end of the path.

Cheers,
b.

Re: [Request] Contact information for CenturyLink network operations

[Anne P. Mitchell, Esq.]

> On Dec 17, 2018, at 11:42 AM, Don Fanning  wrote:
> 
> Hi all,
> 
> Got a network issue with a DoS'er originating from Comcast into
> CenturyLink but unable to find the right people to work on this from
> the CenturyLink side.  Looking for a contact to reach me off-list to
> help solve this or insert a block in a upstream router.

Don, please email me offlist (amitch...@isipp.com);  CenturyLink is now part of 
Level3...we can get you to the right person.

Anne

---
Anne P. Mitchell, 
Attorney at Law
CEO/President, 
SuretyMail Email Reputation Certification and Inbox Delivery Assistance
GDPR, CCPA (CA) & CCDPA (CO) Compliance Consulting
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

Attorney at Law / Legislative Consultant
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Author: The Email Deliverability Handbook
Board Member, Board of Directors, Denver Internet Exchange
Board Member, Board of Directors, Asilomar Microcomputer Workshop
Legal Counsel: The CyberGreen Institute
Legal Counsel: The Earth Law Center
Ret. Professor of Law, Lincoln Law School of San Jose

Re: routeviews.org pending delete

[Larry Smith]

It has been updated it appears:

Registry Expiry Date: 2019-12-14T23:05:47Z

-- 
Larry Smith
lesm...@ecsis.net

On Mon December 17 2018 06:34, Siyuan Miao wrote:
> All,
>
> routeviews.org is pending delete now.
>
> Domain Name: ROUTEVIEWS.ORG
> Registry Domain ID: D48496876-LROR
> Registrar WHOIS Server: whois.networksolutions.com
> Registrar URL: http://www.networksolutions.com
> Updated Date: 2018-12-17T09:33:18Z
> Creation Date: 2000-12-14T23:05:47Z
> Registry Expiry Date: 2019-12-14T23:05:47Z
> Registrar Registration Expiration Date:
> Registrar: Network Solutions, LLC
> Registrar IANA ID: 2
> Registrar Abuse Contact Email: ab...@web.com
> Registrar Abuse Contact Phone: +1.8003337680
> Reseller:
> Domain Status: clientTransferProhibited
> https://icann.org/epp#clientTransferProhibited
> Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod
> Registrant Organization: Network Solutions LLC
> Registrant State/Province: FL
> Registrant Country: US
> Name Server: NS1.PENDINGRENEWALDELETION.COM
> Name Server: NS2.PENDINGRENEWALDELETION.COM
> DNSSEC: unsigned
> URL of the ICANN Whois Inaccuracy Complaint Form
> https://www.icann.org/wicf/ )
>
> >>> Last update of WHOIS database: 2018-12-17T12:28:37Z <<<
>
> routeviews.org. 86400 IN NS ns2.pendingrenewaldeletion.com.
> routeviews.org. 86400 IN NS ns1.pendingrenewaldeletion.com.
>
> I was wondering if there is anyone here can contact them to renew it if
> this project is still alive.
>
> Regards,
> Siyuan

Real-time BGP hijacking detection: ARTEMIS-1.0.0 just released

[Vasileios Kotronis]

Dear operators,

FORTH's INSPIRE group and CAIDA are delighted to announce the public 
release of the ARTEMIS BGP prefix hijacking detection tool, available as 
open-source software at https://github.com/FORTH-ICS-INSPIRE/artemis


ARTEMIS is designed to be operated by an AS in order to monitor BGP for 
potential hijacking attempts against its own prefixes. The system 
detects such attacks within seconds, enabling immediate mitigation. The 
current release has been tested at a major greek ISP, a dual-homed edge 
academic network, and a major US R backbone network.


We would be happy if you'd give it a try and provide feedback. Feel free 
to make pull requests on GitHub and help us make this a true community 
project.


ARTEMIS is funded by European Research Council (ERC) grant agreement no. 
338402 (NetVolution Project), the RIPE NCC Community Projects 2017, the 
Comcast Innovation Fund, US NSF grants OAC-1848641 and CNS-1423659 and 
US DHS S contract HHSP233201600012C.


Best regards,
Vasileios

--
===
Vasileios Kotronis
Postdoctoral Researcher, member of the INSPIRE Group
INSPIRE = INternet Security, Privacy, and Intelligence REsearch
Telecommunications and Networks Lab (TNL)
Foundation for Research and Technology - Hellas (FORTH)
Leoforos Plastira 100, Heraklion 70013, Greece
e-mail : vkotro...@ics.forth.gr
url: http://inspire.edu.gr
===

RE: routeviews.org pending delete

[David Guo via NANOG]

It’s your cache resule

root@server ~ # whois routeviews.org
Domain Name: ROUTEVIEWS.ORG
Registry Domain ID: D48496876-LROR
Registrar WHOIS Server: whois.networksolutions.com
Registrar URL: http://www.networksolutions.com
Updated Date: 2018-12-17T18:54:32Z
Creation Date: 2000-12-14T23:05:47Z
Registry Expiry Date: 2019-12-14T23:05:47Z
Registrar Registration Expiration Date:
Registrar: Network Solutions, LLC
Registrar IANA ID: 2
Registrar Abuse Contact Email: ab...@web.com
Registrar Abuse Contact Phone: +1.8003337680
Reseller:
Domain Status: clientTransferProhibited 
https://icann.org/epp#clientTransferProhibited
Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod
Registrant Organization:
Registrant State/Province: OR
Registrant Country: US
Name Server: GUELAH.SHRUBBERY.NET
Name Server: PHLOEM.UOREGON.EDU
DNSSEC: unsigned

From: NANOG  On Behalf Of Siyuan Miao
Sent: Monday, December 17, 2018 8:34 PM
To: nanog@nanog.org
Subject: routeviews.org pending delete

All,

routeviews.org is pending delete now.

Domain Name: ROUTEVIEWS.ORG
Registry Domain ID: D48496876-LROR
Registrar WHOIS Server: 
whois.networksolutions.com
Registrar URL: http://www.networksolutions.com
Updated Date: 2018-12-17T09:33:18Z
Creation Date: 2000-12-14T23:05:47Z
Registry Expiry Date: 2019-12-14T23:05:47Z
Registrar Registration Expiration Date:
Registrar: Network Solutions, LLC
Registrar IANA ID: 2
Registrar Abuse Contact Email: ab...@web.com
Registrar Abuse Contact Phone: +1.8003337680
Reseller:
Domain Status: clientTransferProhibited 
https://icann.org/epp#clientTransferProhibited
Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod
Registrant Organization: Network Solutions LLC
Registrant State/Province: FL
Registrant Country: US
Name Server: 
NS1.PENDINGRENEWALDELETION.COM
Name Server: 
NS2.PENDINGRENEWALDELETION.COM
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form https://www.icann.org/wicf/)
>>> Last update of WHOIS database: 2018-12-17T12:28:37Z <<<


routeviews.org.   86400 IN   NS   
ns2.pendingrenewaldeletion.com.
routeviews.org.   86400 IN   NS   
ns1.pendingrenewaldeletion.com.

I was wondering if there is anyone here can contact them to renew it if this 
project is still alive.

Regards,
Siyuan

Re: Auto-reply from Yahoo...

[William Allen Simpson]

On 12/20/18 11:46 AM, Grant Taylor via NANOG wrote:

On 12/14/2018 11:48 AM, Grant Taylor wrote:

I've been seeing them for three or four days now.


BUMP

This has been going on for more than a week now.  I'm quite confident that 
there have been hundreds of auto-replies.  (I'm seeing 285 incoming message 
from the NANOG mailing list since I became aware of the auto-reply.)

I'm really surprised that there has not been any reply or action by the NANOG 
list owner(s).  I would have hoped, if not expected, better, or any, response 
by now.


Well, somebody who seemed to be from Yahoo claimed they were fixing
their auto-responder.  Obviously, that hasn't been deployed yet.

Re: Stupid Question maybe?

[William Allen Simpson]

On 12/19/18 2:47 PM, valdis.kletni...@vt.edu wrote:

So at one show, the Interop show network went to a 255.255.252.0 netmask, and
of course a lot of vendors had issues and complained.  The stock response was
"Quit whining, or next show it's going to be 255.255.250.0".


Ha, I remember!

Let us not forget Interop 91, where one vendor accidentally sent all its
packets with an IP version field of 0.  Nearly every router was shown to
never check the IP version number!

Moreover, it turned out later that major printer vendors weren't checking
either  No good way to update them in the field, ever.

That was a serious worry as we designed PIPE/SIP/SIPP/IPv6, and the main
reason that we had to get new link layer protocol numbers.

Then there were the fine vendors that conflated the link and IP headers.
That fell apart when IEEE started assigning OUIs that began with 0x4xxx.

Interop really used to be a blessing, before it became just another show.

Re: Stupid Question maybe?

[Christian Meutes]

On Wed, Dec 19, 2018 at 8:32 AM Saku Ytti  wrote:

> On Wed, 19 Dec 2018 at 02:55, Philip Loenneker
>  wrote:
>
> > I had a heck of a time a few years back trying to troubleshoot an issue
> where an upstream provider had an ACL with an incorrect mask along the
> lines of 255.252.255.0. That was really interesting to talk about once we
> discovered it, though it caused some loss of hair beforehand...
>
> Juniper originally didn't support them even in ACL use-case but were
> forced to add later due to customer demand, so people do have
> use-cases for them. If we'd still support them in forwarding, I'm sure
> someone would come up with solution which depends on it. I am not
> advocating we should, I'll rather take my extra PPS out of the HW.
>
> However there is one quite interesting use-case for discontinuous mask
> in ACL. If you have, like you should have, specific block for customer
> linknetworks, you can in iACL drop all packets to your side of the
> links while still allowing packets to customer side of the links,
> making attack surface against your network minimal.


And unfortunately is still not supported by IOS-XR for IPv6, which could
mean not having a scaleable way on your edge to protect your internal
network.

-- 
Christian

e-mail/xmpp: christ...@errxtx.net
PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318

godaddy contacts

[DurgaPrasad - DatasoftComnet]

Hi,

Is anyone from godaddy in this list? We believe they are announcing our BGP
pool. The IP in 17th hop IP pool is ours as a result some of our customers
are not able to login to godaddy.

 

C:\Users\DP>tracert sso.godaddy.com

 

Tracing route to sso.godaddy.com [104.238.65.153]

over a maximum of 30 hops:

 

  1 2 ms 1 ms 3 ms  192.168.225.1

  2 4 ms 2 ms 2 ms  10.24.0.1

  3 4 ms 2 ms 3 ms  103.40.48.13

  4 4 ms 2 ms 2 ms  vbc-10g-ccr.vbctv.in [123.108.200.5]

  5 4 ms 2 ms 2 ms  vbc-10g-asr.vbctv.in [123.108.200.42]

  6 5 ms 2 ms 2 ms  14.142.71.141.static-hydrabad.vsnl.net.in
[14.142.71.141]

  726 ms32 ms27 ms  172.25.81.134

  846 ms33 ms35 ms  ix-ae-0-4.tcore1.mlv-mumbai.as6453.net
[180.87.38.5]

  9   150 ms   148 ms   147 ms  if-ae-5-2.tcore1.wyn-marseille.as6453.net
[180.87.38.126]

10   147 ms   147 ms   146 ms  if-ae-8-1600.tcore1.pye-paris.as6453.net
[80.231.217.6]

11   147 ms   145 ms   145 ms  if-ae-11-2.tcore1.pvu-paris.as6453.net
[80.231.153.49]

12 **  143 ms  80.231.153.66

13 *  318 ms * ae-1-11.bear1.Phoenix1.Level3.net
[4.69.210.157]

14   274 ms   337 ms   305 ms  THE-GO-DADD.bear1.Phoenix1.Level3.net
[4.16.142.186]

15   329 ms   278 ms   340 ms  ip-148-72-32-9.ip.secureserver.net
[148.72.32.9]

16   269 ms   282 ms   315 ms  ip-184-168-0-117.ip.secureserver.net
[184.168.0.117]

17   333 ms   289 ms   288 ms  125.62.192.197

18 *** Request timed out.

19 *** Request timed out.

20 *** Request timed out.

21 *** Request timed out.

22 *** Request timed out.

23 *** Request timed out.

24   291 ms   275 ms   273 ms  ip-104-238-65-153.ip.secureserver.net
[104.238.65.153]

 

Trace complete.

 

Regards

Durga Prasad



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Stupid Question maybe?

[Adam Atkinson]

On 19/12/2018 16:24, Naslund, Steve wrote:


It has ALWAYS been the only correct way to configure equipment and is
a requirement under CIDR.  Here were your commonly used netmasks
before CIDR/VLSM :

255.0.0.0 255.255.0.0 255.255.255.0

Which one is not contiguous?


There is an example in RFC950 on page 15.

   3.  A Class C Network Case (illustrating non-contiguous subnet bits)

  For this case, assume that the requesting host is on class C
  network 192.1.127.0, has address 192.1.127.19, that there is a
  gateway at 192.1.127.50, and that on network an 3-bit subnet field
  is in use (01011000), that is, the address mask is 255.255.255.88.

Admittedly, page 6 contains:

  Since the bits that identify the subnet are specified by a
  bitmask, they need not be adjacent in the address.  However, we
  recommend that the subnet bits be contiguous and located as the
  most significant bits of the local address.

I have never seen noncontiguous network masks used in real life, but I 
may not be old enough.


--
Adam Atkinson

Re: Stupid Question maybe?

[Smoot Carl-Mitchell]

On Wed, 2018-12-19 at 14: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.

Before CIDR, subnets allowed further subdividing Classful addresses and
the mask bits after the network part could be non-contiguous. For a
class A network the first 8 bits covered the classful network, but the
remaining subnet bits did not have to be contiguous. Most network
admins made the subnet part contiguous, but allowing non-contiguous
subnet masks simplified the actual implementation. There was no need to
check if the bits were contiguous in the code.

Also subnet masks had to be the exactly the same on all devices.  You
could not have variable length masks.  A common practice if you could
get a Class B network (16 bit network part) was to use a 24 bit mask to
divide the network into 254 subnetworks which was adequate for most
purposes at the time.
-- 
Smoot Carl-Mitchell
System/Network Architect
voice: +1 480 922-7313
cell: +1 602 421-9005
sm...@tic.com

Announcing Peering-LAN prefixes to customers

[Dominic Schallert]

Hi all,

this might be a stupid question but today I was discussing with a colleague if 
Peering-LAN prefixes should be re-distributed/announced to direct 
customers/peers. My standpoint is that in any case, Peering-LAN prefixes should 
be filtered and not announced to peers/customers because a Peering-LAN 
represents some sort of DMZ and there is simply no need for them to be 
reachable by third-parties not being physically connected to an IXP themselves. 
Also from a security point of view, a lot of new issues might occur in this 
situation.

I’ve been seeing a few transit providers lately announcing (even reachable) 
Peering-LAN prefixes (for example DE-CIX Peering LAN) to their customers. I’m 
wondering if there is any document or RFC particularly describing this matter?

Thanks
Dominic


signature.asc
Description: Message signed with OpenPGP

Re: JunOS Fusion Provider Edge

[Vincentz Petzholtz]

Hi there,

About Juniper Fusion PE and our experience with it.

> For example, you can't get SNMP oids for light levels or even read them right 
> from the CLI.
Sure it’s possible but also with a big „meh“. Here is how:
"show interfaces diagnostics optics satellite “ (<- on the MX)
BUT at least with MX Junos 16.1R7 and aligned SAT Image aka SNOS these values 
are wrong
by a pretty big offset. Juniper promised they already fixed it but we can’t 
confirm (at least not in MX Junos 16.1).
Soon we will take a look at MX Junos 17.3 with aligned sat image.

>  I've also heard you can have them do local L2 forwarding, which can be nice 
> for latency and conserving uplink bandwidth, but we don't do any L2 that way 
> so I wouldn't know the implications
Same thing here … we don’t really need it. At least it’s on the roadmap and/or 
already implemented with higher Junos/SNOS versions.

> From what we can tell though, it does give you Trio L3 performance and 
> features with a MUCH cheaper port cost which is exactly what we were looking 
> for, the extended reach of the chassis was just a fantastic bonus.
Yep, that is really amazing and the reason we use it on many MXes. You can get 
rid of almost all ports you want (restrictions apply tho).

> We also REALLY like that we can have one pair of MX dists for a whole data 
> center with hundreds of thousands of square feet of raised floor and deploy 
> QFX5100 or EX4300 switches in every pod and haul back over just a few pairs 
> of fiber. Saves a lot of time because all that's required to turn up a new 
> connection is a cross connect in the pod. It also allows us to offer copper 
> ports very far away from the MX device, which would normally require media 
> converters.
We use Junos PE NOT as a replacement for any switch and/or ip fabrics within a 
datacenter. We use it to get rid of many customer/client ports (mainly 1G and 
10G ports)
which were directly connected to our MXes before. Atm I would not recommend 
using any closed fabrics beyond that scope. If it works for you … ok.

> We've wanted to experiment with doing this over dark fiber in the metro as 
> well, but we want to feel out any kinks locally before we add additional 
> failure modes.
At the moment? Don’t do it. If you run mpls on so called „core router/dwdm/wan 
facing ports“ you have to know that this is totally not supported on extended 
satellite ports.
It’s not even on the roadmap. I already started to „collect“ some other ISPs to 
push juniper towards this feature because technically there no
real reason why fusion should NOT be capable of pushing some mpls labels on 
already tagged 802.1br packets.

Best regards,
Vincentz
—
PS: some have received this mail multiple times because I’ve send it from the 
wrong account … time for vacation I guess.

> Am 17.12.2018 um 19:26 schrieb Matt Erculiani :
> 
> Fusion has made a lot more sense since Juniper changed the licensing model 
> from every switch AND the MX to just the MX.
> 
> We've deployed it in some of our sites. It is very cool from a forwarding 
> plane perspective, but from a control plane standpoint it's very...meh. For 
> example, you can't get SNMP oids for light levels or even read them right 
> from the CLI. You have to log into the satellite switch like you would log 
> into an FPC just to get light levels. That's probably the dumbest thing we've 
> dealt with though. I've also heard you can have them do local L2 forwarding, 
> which can be nice for latency and conserving uplink bandwidth, but we don't 
> do any L2 that way so I wouldn't know the implications. From what we can tell 
> though, it does give you Trio L3 performance and features with a MUCH cheaper 
> port cost which is exactly what we were looking for, the extended reach of 
> the chassis was just a fantastic bonus.
> 
> We also REALLY like that we can have one pair of MX dists for a whole data 
> center with hundreds of thousands of square feet of raised floor and deploy 
> QFX5100 or EX4300 switches in every pod and haul back over just a few pairs 
> of fiber. Saves a lot of time because all that's required to turn up a new 
> connection is a cross connect in the pod. It also allows us to offer copper 
> ports very far away from the MX device, which would normally require media 
> converters.
> 
> We've wanted to experiment with doing this over dark fiber in the metro as 
> well, but we want to feel out any kinks locally before we add additional 
> failure modes.
> 
> Very interested in hearing about other's experiences with Fusion, good, bad, 
> and ugly.
> 
> -Matt
> 
> On Mon, Dec 17, 2018 at 12:08 PM Mehmet Akcin  > wrote:
> Hey there
> 
> Any ISP using Juniper Fusion Provider Edge?
> 
> https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-fusion/junos-fusion.html
>  
> 
> 
> I am trying to 

Re: Stupid Question maybe?

[Joel Halpern]

History of non-contiguous network masks, as I observed it.

The rules did not prohibit discontiguous network masks.  But no one was 
sure how to make them work.  In particular, how to allocate subnets from 
discontiguous networks in a sensible fashion.


In the early 90s, during the efforts to solve the swamp and classful 
exhaustion problems, Paul Francis (then Tsuchia) and I each worked out 
table structures that would allow for discontiguous masks with 
well-defined "prefixes" / "parents".  Both approaches were based on 
extensions of Knuth's Patricia trees.  (It took some interesting 
analysis and extensions.)


When we were done, other folks looked at the work (I don't know if the 
Internet Drafts are still in repositories, but they shoudl be.)  And 
concluded that while this would work, no network operations staff would 
ever be able to do it correctly.  So as a community we decided not to go 
down that path.


Yours,
Joel

On 12/18/18 5:12 PM, David Edelman wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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)

Dave

- -Original Message-
From: NANOG  On Behalf Of Naslund, Steve
Sent: Tuesday, December 18, 2018 3:37 PM
To: nanog@nanog.org
Subject: RE: Stupid Question maybe?

It is a matter of machine readability vs human readability.  Remember the IP 
was around when routers did not have a lot of horsepower.  The dotted decimal 
notation was a compromise between pure binary (which the equipment used) and 
human readability.  VLSM seems obvious now but in the beginning organizing 
various length routes into very expensive memory and low horsepower processors 
meant that it was much easier to break routes down along byte boundaries.  This 
meant you only had four different lengths of route to deal with.  It was 
intended to eliminate multiple passes sorting the tables.  I am not quite sure 
what you mean about interspersing zeros, that would be meaningless.  Remember 
that it is a mask.  The address bits which are masked as 1s are significant to 
routing.  The bits that are masked with 0s are the host portion and don't 
matter to the network routing table.

Steven Naslund
Chicago IL



/24 is certainly cleaner than 255.255.255.0.

I seem to remember it was Phil Karn who in the early 80's suggested that 
expressing subnet masks as the number of bits from the top end of the address word 
was efficient, since subnet masks were always a series of ones followd >by 
zeros with no interspersing, which was incorporated (or independently invented) 
about a decade later as CIDR a.b.c.d/n notation in RFC1519.
- Brian

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQQP+UHquEepll566aqXCCyZOY1FIQUCXBlw1AAKCRCXCCyZOY1F
IYkTAJ98Gh+IGhDcyIB92H9JyWtbCVDhugCfZXq60pnHCqttKfw2fpUCBagTxYo=
=RimM
-END PGP SIGNATURE-

BGP Experiment

[Italo Cunha]

NANOG,

We would like to inform you of an experiment to evaluate alternatives
for speeding up adoption of BGP route origin validation (research
paper with details [A]).

Our plan is to announce prefix 184.164.224.0/24 with a valid
standards-compliant unassigned BGP attribute from routers operated by
the PEERING testbed [B, C]. The attribute will have flags 0xe0
(optional transitive [rfc4271, S4.3]), type 0xff (reserved for
development), and size 0x20 (256bits).

Our collaborators recently ran an equivalent experiment with no
complaints or known issues [A], and so we do not anticipate any
arising. Back in 2010, an experiment using unassigned attributes by
RIPE and Duke University caused disruption in Internet routing due to
a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other
similar bugs have been patched [e.g., CVE-2013-6051], and new BGP
attributes have been assigned (BGPsec-path) and adopted (large
communities). We have successfully tested propagation of the
announcements on Cisco IOS-based routers running versions 12.2(33)SRA
and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and
1.6.3.

We plan to announce 184.164.224.0/24 from 8 PEERING locations for a
predefined period of 15 minutes starting 14:30 GMT, from Monday to
Thursday, between the 7th and 22nd of January, 2019 (full schedule and
locations [E]). We will stop the experiment immediately in case any
issues arise.

Although we do not expect the experiment to cause disruption, we
welcome feedback on its safety and especially on how to make it safer.
We can be reached at disco-experim...@googlegroups.com.

Amir Herzberg, University of Connecticut
Ethan Katz-Bassett, Columbia University
Haya Shulman, Fraunhofer SIT
Ítalo Cunha, Universidade Federal de Minas Gerais
Michael Schapira, Hebrew University of Jerusalem
Tomas Hlavacek, Fraunhofer SIT
Yossi Gilad, MIT

[A] https://conferences.sigcomm.org/hotnets/2018/program.html
[B] http://peering.usc.edu
[C] https://goo.gl/AFR1Cn
[D] 
https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment
[E] https://goo.gl/nJhmx1

Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Brian J. Murrell]

I've been trying to figure out why I can reach an IPv6 address at
Facebook (2a03:2880:f012:3:face:b00c:0:1) through (only) one of my two
Internet connections as well as via an HE IPv6 tunnel but not the other
of my two ISP connections

At one point in time a traceroute was dying inside of he.net:

 Host  Loss%   Snt   Last   Avg  Best  Wrst 
StDev
 1. 2001:1970:5261:d600::1  0.0% 72.1   1.3   0.7   2.9 
  0.8
 2. 2001:1970:4000:82::10.0% 7   10.0  14.0   8.3  37.9 
 10.6
 3. 2001:1970:0:1a6::1 16.7% 7   13.2 215.5  10.8 1031. 
455.9
 4. he.ip6.torontointernetxchange.net   0.0% 7   12.3  12.9  11.2  15.3 
  1.6
 5. 100ge9-2.core2.chi1.he.net  0.0% 7   23.6  23.0  21.3  27.6 
  2.2
 6. 100ge15-2.core1.chi1.he.net 0.0% 7   21.7  22.5  21.6  24.9 
  1.2
 7. 100ge12-1.core1.atl1.he.net 0.0% 7   34.2  35.1  34.1  36.1 
  0.7
 8. 100ge5-1.core1.tpa1.he.net  0.0% 7   49.1  46.6  44.8  49.1 
  1.5
 9. 100ge12-1.core1.mia1.he.net 0.0% 7   51.6  54.5  50.5  73.3 
  8.3
10. ???

But I think it getting that far time was an anomaly and frankly it
usually dies even before exiting my ISP's (Cogeco) network like this:

 Host   Loss%   Snt   Last   Avg  Best  
Wrst StDev
 1. 2001:1970:5261:d600::1   0.0%330.6   0.7   0.6   
1.0   0.1
 2. 2001:1970:4000:82::1 0.0%338.2  10.8   8.1  
40.5   5.6
 3. 2001:1970:0:1a7::1  15.2%33   23.4  20.1  16.5  
23.4   1.5
 4. 2001:1970:0:61::1   33.3%33   16.8  17.6  14.5  
25.9   2.5
 5. 2001:1978:1300::10.0%33   16.0  17.5  14.2  
29.6   3.1
 6. 2001:1978:203::450.0%33   30.7  30.7  28.4  
35.1   1.7
 7. ???

When I asked the kind folks at he.net for some advice about the problem
(i.e. in the first traceroute above) their diagnosis was that
Facebook's IPv6 router(s) likely didn't have a route back to my Cogeco
IPv6 address.

Trying to talk to my ISP (again, Cogeco) has been impossible.  One
simply cannot reach the people who know more than how to reset your
router and configure your e-mail.

I wonder how I could go any further with this to confirm the diagnosis
that Facebook doesn't have a route to the Cogeco network's IPv6 address
space given that I only have access to my end of the path.

Cheers,
b.



signature.asc
Description: This is a digitally signed message part

Re: JunOS Fusion Provider Edge

[Vincentz Petzholtz]

Hi there,

About Juniper Fusion PE and our experience with it.

> For example, you can't get SNMP oids for light levels or even read them right 
> from the CLI.
Sure it’s possible but also with a big „meh“. Here is how:
"show interfaces diagnostics optics satellite “ (<- on the MX)
BUT at least with MX Junos 16.1R7 and aligned SAT Image aka SNOS these values 
are wrong
by a pretty big offset. Juniper promised they already fixed it but we can’t 
confirm (at least not in MX Junos 16.1).
Soon we will take a look at MX Junos 17.3 with aligned sat image.

>  I've also heard you can have them do local L2 forwarding, which can be nice 
> for latency and conserving uplink bandwidth, but we don't do any L2 that way 
> so I wouldn't know the implications
Same thing here … we don’t really need it. At least it’s on the roadmap and/or 
already implemented with higher Junos/SNOS versions.

> From what we can tell though, it does give you Trio L3 performance and 
> features with a MUCH cheaper port cost which is exactly what we were looking 
> for, the extended reach of the chassis was just a fantastic bonus.
Yep, that is really amazing and the reason we use it on many MXes. You can get 
rid of almost all ports you want (restrictions apply tho).

> We also REALLY like that we can have one pair of MX dists for a whole data 
> center with hundreds of thousands of square feet of raised floor and deploy 
> QFX5100 or EX4300 switches in every pod and haul back over just a few pairs 
> of fiber. Saves a lot of time because all that's required to turn up a new 
> connection is a cross connect in the pod. It also allows us to offer copper 
> ports very far away from the MX device, which would normally require media 
> converters.
We use Junos PE NOT as a replacement for any switch and/or ip fabrics within a 
datacenter. We use it to get rid of many customer/client ports (mainly 1G and 
10G ports)
which were directly connected to our MXes before. Atm I would not recommend 
using any closed fabrics beyond that scope. If it works for you … ok.

> We've wanted to experiment with doing this over dark fiber in the metro as 
> well, but we want to feel out any kinks locally before we add additional 
> failure modes.
At the moment? Don’t do it. If you run mpls on so called „core router/dwdm/wan 
facing ports“ you have to know that this is totally not supported on extended 
satellite ports.
It’s not even on the roadmap. I already started to „collect“ some other ISPs to 
push juniper towards this feature because technically there no
real reason why fusion should NOT be capable of pushing some mpls labels on 
already tagged 802.1br packets.

Best regards,
Vincentz

> Am 17.12.2018 um 19:26 schrieb Matt Erculiani  >:
> 
> Fusion has made a lot more sense since Juniper changed the licensing model 
> from every switch AND the MX to just the MX.
> 
> We've deployed it in some of our sites. It is very cool from a forwarding 
> plane perspective, but from a control plane standpoint it's very...meh. For 
> example, you can't get SNMP oids for light levels or even read them right 
> from the CLI. You have to log into the satellite switch like you would log 
> into an FPC just to get light levels. That's probably the dumbest thing we've 
> dealt with though. I've also heard you can have them do local L2 forwarding, 
> which can be nice for latency and conserving uplink bandwidth, but we don't 
> do any L2 that way so I wouldn't know the implications. From what we can tell 
> though, it does give you Trio L3 performance and features with a MUCH cheaper 
> port cost which is exactly what we were looking for, the extended reach of 
> the chassis was just a fantastic bonus.
> 
> We also REALLY like that we can have one pair of MX dists for a whole data 
> center with hundreds of thousands of square feet of raised floor and deploy 
> QFX5100 or EX4300 switches in every pod and haul back over just a few pairs 
> of fiber. Saves a lot of time because all that's required to turn up a new 
> connection is a cross connect in the pod. It also allows us to offer copper 
> ports very far away from the MX device, which would normally require media 
> converters.
> 
> We've wanted to experiment with doing this over dark fiber in the metro as 
> well, but we want to feel out any kinks locally before we add additional 
> failure modes.
> 
> Very interested in hearing about other's experiences with Fusion, good, bad, 
> and ugly.
> 
> -Matt
> 
> On Mon, Dec 17, 2018 at 12:08 PM Mehmet Akcin  > wrote:
> Hey there
> 
> Any ISP using Juniper Fusion Provider Edge?
> 
> https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-fusion/junos-fusion.html
>  
> 
> 
> I am trying to chat with an engineer besides Juniper engineers to understand 
> how buggy (or not) this is 

[Request] Contact information for CenturyLink network operations

[Don Fanning]

Hi all,

Got a network issue with a DoS'er originating from Comcast into
CenturyLink but unable to find the right people to work on this from
the CenturyLink side.  Looking for a contact to reach me off-list to
help solve this or insert a block in a upstream router.

Thanks!
-Don

routeviews.org pending delete

[Siyuan Miao]

All,

routeviews.org is pending delete now.

Domain Name: ROUTEVIEWS.ORG
Registry Domain ID: D48496876-LROR
Registrar WHOIS Server: whois.networksolutions.com
Registrar URL: http://www.networksolutions.com
Updated Date: 2018-12-17T09:33:18Z
Creation Date: 2000-12-14T23:05:47Z
Registry Expiry Date: 2019-12-14T23:05:47Z
Registrar Registration Expiration Date:
Registrar: Network Solutions, LLC
Registrar IANA ID: 2
Registrar Abuse Contact Email: ab...@web.com
Registrar Abuse Contact Phone: +1.8003337680
Reseller:
Domain Status: clientTransferProhibited
https://icann.org/epp#clientTransferProhibited
Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod
Registrant Organization: Network Solutions LLC
Registrant State/Province: FL
Registrant Country: US
Name Server: NS1.PENDINGRENEWALDELETION.COM
Name Server: NS2.PENDINGRENEWALDELETION.COM
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form https://www.icann.org/wicf/
)
>>> Last update of WHOIS database: 2018-12-17T12:28:37Z <<<


routeviews.org. 86400 IN NS ns2.pendingrenewaldeletion.com.
routeviews.org. 86400 IN NS ns1.pendingrenewaldeletion.com.

I was wondering if there is anyone here can contact them to renew it if
this project is still alive.

Regards,
Siyuan

Re: Pinging a Device Every Second

[Olav Kvittem]

Hi,

The link is not the only component to fail - routers and routing protocols all 
contribute at least as much.
If your customers would have redundant connections,
you also would like to look at convergence times.
So a measurement end to end by a probe in the customers network could give
you a more true picture.
Facing that even sub second outages can annoy a video meeting,
it might be that you want to  poll more often than a second.

Realizing that your "internet service" depends on the behaviour of all all the 
other
service providers quality and if you even start monitoring that - you 
understand that
you are "in deep shit" ;-)


I did a small scale global inter domain measurement and discovered that the 
sheer number of small outages is way too high.

Many of them  might be routing changeovers in  multi-redundant networks.

cheers
Olav

On 15.12.2018 18:55, Tim Pozar wrote:
> In one of my client's company, we use LibreNMS. It is normally used > to get 
> SNMP data but we also have it configured to ping our more > "high touch" 
> cients routers. In that case we can record performance > such as latency and 
> packet loss. It will generate graphs that we can > pass on to the client. It 
> also can be set to alert us if a client's > router is not pingable. > > 
> LibreNMS can also integrate Smokeping if you want Smokeping-style > graphs 
> showing standard deviation, etc. > > Currently I am running LibreNMS on a VM 
> on a Proxmox cluser with a > couple of cores. It is probing 385 devices every 
> 5 minutes and > keeping up with that. In polling, SNMP is the real time and 
> CPU hog > where ping is pretty low impact. > > Tim > > On 12/15/18 9:37 AM, 
> Baldur Norddahl wrote: >> You could configure BFD to send out a SNMP alert 
> when three packets >> have been missed on a 50 ms cycle. Or instantly if the 
> interface >> charges state to down. This way you would know that they are 
> down >> within 150 ms. >> >> BFD is the hardware solution. A Linux box that 
> has to ping 1000 >> addresses per second will be very taxed and likely unable 
> to do >> that in a stable way. You will have seconds where it fails to do >> 
> them all followed by seconds where it attempts to do them more than >> once. 
> The result is that the statistics gathered is worthless. If >> you do 
> something like this, it is much better to have a less >> ambitious 1 minute 
> cycle. >> >> Take a look at Smokeping. If you want a graph to show the 
> quality >> of the line, Smokeping makes some very good graphs for that. >> >> 
> Regards Baldur >> >> 15. dec. 2018 16.49 skrev "Colton Conor" 
> > 
> >: >> >> How 
> much compute and network resources does it take for a NMS to: >> >> 1. ICMP 
> ping a device every second 2. Record these results. 3. >> Report an alarm 
> after so many seconds of missed pings. >> >> We are looking for a system to 
> in near real-time monitor if an end >> customers router is up or down. SNMP I 
> assume would be too >> resource intensive, so ICMP pings seem like the only 
> logical >> solution. >> >> The question is once a second pings too polling on 
> an NMS and a >> consumer grade router? Does it take much network bandwidth 
> and CPU >> resources from both the NMS and CPE side? >> >> Lets say this is 
> for a 1,000 customer ISP. >> >> >>

Re: Auto-reply from Yahoo...

[M . Ömer GÖLGELİ]

This can happen for many reasons. Quitting employees, dropping domains, death whatever. They should be *somehow* auto removed after a certain number of bounces. M. ---On 20 Dec 2018 19:46, Grant Taylor via NANOG  wrote:On 12/14/2018 11:48 AM, Grant Taylor wrote:

> I've been seeing them for three or four days now.



BUMP



This has been going on for more than a week now.  I'm quite confident 

that there have been hundreds of auto-replies.  (I'm seeing 285 incoming 

message from the NANOG mailing list since I became aware of the auto-reply.)



I'm really surprised that there has not been any reply or action by the 

NANOG list owner(s).  I would have hoped, if not expected, better, or 

any, response by now.







-- 

Grant. . . .

unix || die

Re: historical Bogon lists

[John McCormac]

On 15/12/2018 08:31, Lars Prehn wrote:

Hi everyone,

In order to sanitize historical BGP data I would like to use historical 
Bogon lists. The CIDR report generates those lists on a daily basis 
(e.g. https://www.cidr-report.org/bogons/freespace-dec.txt for prefixes) 
but, as far as I know, it does not keep a history of those files - it 
only holds the most up-to-date file. Does anybody know of a repository 
that contains such bogon lists for historical data, or, did anybody 
continiously fecthed and saved CIDR report's bogon lists?




There does seem to be some historical data from the CIDR report here:
http://thyme.rand.apnic.net/

Might have a few historical freespace-dec.txt files around from building 
periodic IP/country maps of all gTLD websites.


Regards...jmcc

Re: email scannering / filtering

[John Capo via NANOG]

On Fri, December 14, 2018 13:49, Chris Adams wrote:
> Once upon a time, Grant Taylor via NANOG  said:
>
>> - ClamAV
>>
>
> In my recent experience, ClamAV is basically useless against email
> viruses.  On one setup I run that handles around half a million messages a 
> day, ClamAV might flag
> 3-5 as viruses.  I'm dubious that that's all
> the virus messages that came through.
>
> I'd be interested in hearing of other Linux software (free or paid) that
> can catch modern email viruses.

ClamAV addons.

  
https://www.securiteinfo.com/services/anti-spam-anti-virus/improve-detection-rate-of-zero-day-malwares-for-clamav.shtml

  https://sanesecurity.com/

Re: IRR Cleanliness

[Mick O'Donovan]

On Sat 15 Dec 2018 at 09:17, Joe Provo  wrote:

> Being listed in an as-macro doesn't affect your use of the AS
> or use of it in any IRR.
>
> Many providers will list customers (for filter generation) without
> express consent. Some folks will lump peers in categories through
> IRR data. There's certainly nothing amiss in using as-macros even
> for non-neighbors in a number of cases, enumerting ASNs one will
> [de]preference from a certain set of peers or will drop entirely
> for example.
>
> Often such policies exist but aren't published. ;-)
>
> Cheers!
>
> Joe
>
> --
> Posted from my personal account - see X-Disclaimer header.
> Joe Provo / Gweep / Earthling


+1

I wouldn’t see this as odd behaviour either.

Mick


>

Re: Auto-reply from Yahoo...

[Grant Taylor via NANOG]

On 12/14/2018 11:48 AM, Grant Taylor wrote:

I've been seeing them for three or four days now.


BUMP

This has been going on for more than a week now.  I'm quite confident 
that there have been hundreds of auto-replies.  (I'm seeing 285 incoming 
message from the NANOG mailing list since I became aware of the auto-reply.)


I'm really surprised that there has not been any reply or action by the 
NANOG list owner(s).  I would have hoped, if not expected, better, or 
any, response by now.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Stupid Question maybe?

[Grant Taylor via NANOG]

On 12/20/2018 02:47 AM, Saku Ytti wrote:
Aye. I'd recommend not advertise your linknetworks at all, and let 
customers either opt-in or out-out from creating /128 and /32 static 
route towards interface. Achieving mostly same result, except for in 
local device where edge interfaces can reach customer and your side.


Are you advocating not advertising customer linknetworks within your own 
organization?


I know of a use cases where linknetworks must be globally accessible. 
At least the customer's linknetwork IP address.  So, not advertising 
them (or at least an aggregate for them) would be problematic.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Stupid Question maybe?

[Saku Ytti]

On Thu, 20 Dec 2018 at 10:32, Christian Meutes  wrote:

> And unfortunately is still not supported by IOS-XR for IPv6, which could mean 
> not having a scaleable way on your edge to protect your internal network.

Aye. I'd recommend not advertise your linknetworks at all, and let
customers either opt-in or out-out from creating /128 and /32 static
route towards interface. Achieving mostly same result, except for in
local device where edge interfaces can reach customer and your side.

-- 
  ++ytti